Bug 67815 - graphics/ImageMagick no longer recognizes FlashPix
Summary: graphics/ImageMagick no longer recognizes FlashPix
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Mikhail Teterin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-06-11 01:30 UTC by Jed Clear
Modified: 2007-11-07 05:50 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jed Clear 2004-06-11 01:30:29 UTC
About a week ago, after building 4.10-R from CVS, I did a portupgrade -R ImageMagick.  The ImageMagick convert utility would then core while trying to convert a 1536x1024 FlashPix image to JPEG  ( 'convert foo.fpx foo.jpg' ).  On 9 August I did another portupgrade -R ImageMagick.  Now port upgrade does not recognize FlashPix as a supported format.  I did a make clean/deinstall/reinstall on both libfpx and ImageMagick, and still it doesn't even recognize the FlashPix file.  pkg_info shows libfpx-1.2.0.9 and ImageMagick-6.0.2.1.

The MagicStudio at imagemagick.com also does not recognize the file.  The Kodak camera software has no problem with it.  And WinME can generate a Thumbnail in the file browser.

How-To-Repeat: % indentify foo.fpx
identify: ImageTypeNotSupported.
identify: missing an image filename `foo.fpx'.

% convert foo.fpx foo.jpg
convert: ImageTypeNotSupported.
convert: missing an image filename `foo.jpg'.
Comment 1 Jed Clear 2004-06-12 02:10:50 UTC
I noticed that the fpx files in question had fresh modifications dates, 
and there are diffs with archive on CD-R.  I restored them from CD-R and 
set the permission to 444.  Now identify now just cores.

Besides the core, there is a debug.tmp file generated, which contains:
File /home/ports/graphics/libfpx/work/libfpx-1.2.0.9/fpx/pres_fpx.cpp; 
line 481 # Assertion fausse
File /home/ports/graphics/libfpx/work/libfpx-1.2.0.9/fpx/pres_fpx.cpp; 
line 484 # Assertion fausse
File /home/ports/graphics/libfpx/work/libfpx-1.2.0.9/fpx/pres_fpx.cpp; 
line 245 # Assertion fausse
File /home/ports/graphics/libfpx/work/libfpx-1.2.0.9/fpx/buffdesc.cpp; 
line 838 # Assertion fausse
File /home/ports/graphics/libfpx/work/libfpx-1.2.0.9/fpx/pres_fpx.cpp; 
line 508 # Assertion fausse
File /home/ports/graphics/libfpx/work/libfpx-1.2.0.9/fpx/buffdesc.cpp; 
line 634 # Assertion fausse

FPX is not entirely dead in ImageMagick as I could do the following:
% convert logo: logo.fpx
% identify logo.fpx
logo.fpx FPX 640x480+0+0 DirectClass 8-bit 1.3mb 0.070u 0:01
% display logo.fpx

Also the Win32 version of ImageMagick 6.0.2-Q16-dll displays the files 
correctly, but it is also modifying the file!   If I mark the file 
read-only it still displays it, but doesn't modify it.  The FreeBSD 
created logo.fpx file was not viewable on the Windows box with either 
the ImageMagick or Kodak software.

Back on the FreeBSD box:
Just for grins I changed permissions back to 644 on the fpx file.  Now 
we are back to:
% identify foo.fpx
identify: ImageTypeNotSupported.
identify: missing an image filename `foo.fpx'.
And the file gets modified!

So I guess now there are two bugs:
1) Why does the FlashPix file need to be opened r/w by identify and a 
read only file cause it to core?  And if r/w, why is it modified?

2) And the original bug, why doesn't ImageMagick on FreeBSD recognize a 
FlashPix generated by a Kodak DC265 camera. But the same file displays 
in the Win32 version.

Here is one of the (restored) files I've been testing with: 
http://66.92.238.5/Photos/2002/200207%20Boston/p0002214.fpx
MD5 (p0002214.fpx) = b86a68294ed11ecd91feafa72d3f0f59
The MD5 is in case I test some more....
Comment 2 Arjan van Leeuwen 2004-06-24 13:38:35 UTC
It seems like libfpx can't discover the colorspace the image is using,  
judging by the debug messages - it reaches all kinds of strange assertions  
that 'should never happen'. This looks like a problem of the libfpx  
library, and I don't have enough knowledge about fpx to fix it. If someone  
else volunteers to take a look at this, that would be very helpful :).

Arjan

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/
Comment 3 Volker Stolz freebsd_committer 2004-06-24 16:00:39 UTC
Responsible Changed
From-To: freebsd-ports-bugs->vs

I'll track this. Arjan, please notify me when I should close the PR.
Comment 4 Volker Stolz freebsd_committer 2004-07-05 10:09:14 UTC
State Changed
From-To: open->suspended

Release and suspend until somebody comes up with a fix (mi@?) 


Comment 5 Volker Stolz freebsd_committer 2004-07-05 10:09:14 UTC
Responsible Changed
From-To: vs->freebsd-ports-bugs

Release and suspend until somebody comes up with a fix (mi@?)
Comment 6 Jed Clear 2004-10-09 19:28:28 UTC
The test file got moved, sorry.  It is now (9Oct04) back at the above
address.  I'll portupgrade -R after the 5.3 freeze ends, and see if
there is any change.
Comment 7 Jed Clear 2004-12-20 02:58:48 UTC
Slight change with FreeBSD 4.10-RELEASE-p4, ImageMagick-6.1.6.8, and 
libfpx-1.2.0.9.  Now I get "identify: ImageTypeNotSupported.", regardless of 
file permission. debug.tmp is identical.  logo.fpx still works.

However if debug.tmp is not writable, identify Seg faults.
Comment 8 Mikhail Teterin 2005-10-24 13:30:57 UTC
The FlashPix library used by ImageMagick (and by GraphicsMagick) is
unmaintained.

Once in a while ImageMagick updates the posted tar-ball just to change
the automake/autoconf glue and annoy the maintainer(s).

The r/w opening problem can, probably, be fixed by the port, but it --
and anything else wrong with FlashPix is the problem with the library
itself :-( And no updates to it are expected...

I did some searching around in the past -- there is code for handling
the format, but it, apparently, was only available via CD-ROM (one had
to pay for shipping).

If you care, you can order it and see if you can make a port. Begin at
http://i3a.org/ :

	http://www.i3a.org/pdf/resource_order_form.pdf

It may even be legal to offer the source for download -- I3A may simply
not want to pay for bandwidth, but don't otherwise mind the
redistribution.

	-mi
Comment 9 Mark Linimon freebsd_committer freebsd_triage 2006-12-24 11:57:47 UTC
Responsible Changed
From-To: freebsd-ports-bugs->shaun

Over to new maintainer.
Comment 10 Mark Linimon freebsd_committer freebsd_triage 2007-10-28 07:04:34 UTC
Responsible Changed
From-To: shaun->mi

Reassign to current maintainer.
Comment 11 Mikhail Teterin 2007-10-31 13:51:21 UTC
Hi, Jed!

I may finally have a working version of libfpx -- could you, please, provide 
me with some sample FPX files for testing? Thanks!

	-mi
Comment 12 Jed Clear 2007-11-01 03:19:29 UTC
On Oct 31, 2007, at 9:51 AM, Mikhail Teterin wrote:
> I may finally have a working version of libfpx -- could you,  
> please, provide
> me with some sample FPX files for testing? Thanks!

Wow, I'd forgotten all about that PR.  Did something change in the  
original code base?

I restored the FPX image mentioned in the PR to the URL referenced in  
the PR and rechecked the MD5 (quoted below for your convenience).

 > Here is one of the (restored) files I've been testing with:
 > http://66.92.238.5/Photos/2002/200207%20Boston/p0002214.fpx
 > MD5 (p0002214.fpx) = b86a68294ed11ecd91feafa72d3f0f59
 > The MD5 is in case I test some more....

For visual referece, a JPEG conversion of that FPX, created by the  
Kodak software, is here http://66.92.238.5/Photos/2002/200207% 
20Boston/Full/p0002124.jpg

-Jed
Comment 13 dfilter service freebsd_committer 2007-11-07 05:46:44 UTC
mi          2007-11-07 05:46:29 UTC

  FreeBSD ports repository

  Modified files:
    graphics/ImageMagick Makefile distinfo pkg-plist 
  Removed files:
    graphics/ImageMagick/files patch-leak patch-module-path 
                               patch-test-filter 
  Log:
  Update from 6.3.5-10 to 6.3.6-9. Some of our patches were accepted
  upstream. The tests should work with and without X11. Enable FPX by
  default. Resolve all related PRs.
  
  Approved by:    portmgr (linimon)
  PR:     67815
  PR:     117635
  PR:     116874
  PR:     114387
  
  Revision  Changes    Path
  1.249     +21 -14    ports/graphics/ImageMagick/Makefile
  1.111     +3 -3      ports/graphics/ImageMagick/distinfo
  1.2       +0 -12     ports/graphics/ImageMagick/files/patch-leak (dead)
  1.2       +0 -31     ports/graphics/ImageMagick/files/patch-module-path (dead)
  1.2       +0 -21     ports/graphics/ImageMagick/files/patch-test-filter (dead)
  1.108     +1 -0      ports/graphics/ImageMagick/pkg-plist
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 14 Mikhail Teterin freebsd_committer 2007-11-07 05:46:56 UTC
State Changed
From-To: suspended->closed

The current version of the IM-port should resolve this.