#134 pix_image support for TIFF incomplete (linux)

[sistisette]

pix_image doesn't load certain images saved with Adobe Photoshop. The worst thing is that it doesn't print an error message and, sometimes (but not always), it even prints the success message: "threaded loaded image: xxx.tif" even if the image is not decoded.

I attach a tiff file saved with Adobe Photoshop that triggers this issue. Maybe the source of the problem is the existence in the file of a private tiff tag "37724" (Image Source Data) which is used by Photoshop. All images I tried that have this tag suffer from this issue. Unfortunately if you open one such image with Photoshop and save it again, there seems not to be any way to get rid of this tag (nor to know about its existance). Note that a lot of people use Photoshop under Mac or Windows to edit or create image files.
However I created other images from scratch with Photoshop myself and they didn't suffer from this problem (and they don't seem to have that tag). I don't know what determines whether Photoshop includes this tag or not in the saved image.

Anyway, as far as I understand (which is not very far) the presence of an unknown tag shouldn't be a reason for not being able to decode an image.

[sistisette]

[IOhannes m zmölnig]

i believe the problem is fixed for ImageMagick loading code (as used e.g. on linux) with rev3906

if you encounter the same problem on other platforms (esp. w32) please reopen this report

[sistisette]

With 0.92.3 the issue does exist on all platform (well on Linux, Windows and Mac OS).

I don't know if the fix you mention is supposed to fix it for Windows and Mac OS too.

[IOhannes m zmölnig]

i don't know either :-)

in theory it is like that:
Gem uses several backends for image reading, which one are available/used, depends on the platform.

- OSX: Gem uses QuickTime to read the image. if QuickTime fails, Gem fails as well; otoh it is unlikely that QuickTime is unable to read such a "problematic" TIFF file. Gem _could_ use imagemagick on OSX as well, but afaik doesn't do so.

- w32: Gem uses some rather old static code to decode image files (hence there is only a very limited number of supported formats); this code might not be able to read your TIFF file, and i have no real intent to fix this; rather, the w32 version should switch to a more common API (DirectSomething and/or QT) for reading images.

- linux: Gem uses imagemagick OR libTIFF/libJPEG for reading images; the fix in rev3906 fixed the problem with imagemagick, the direct libTIFF reading did not seem to have a problem.

[IOhannes m zmölnig]

well, i now tested on OSX with
- an uptodate Gem from svn
- a recent pd-extended buld (0.43-20110401)
- an old 0.92.1 version i found on the harddisk
- a recent build of 0.92.3 (_not_ the one included in Pd-extended)

all version of Gem on OSC were able to load your image without further ado.

this basically leaves only w32 (which i cannot test right now)
if the problem indeed exists on w32, please submit another bug-report indicating the OS (this is good for the bugs-closed statistic :-))

[sistisette]

Sorry, you're right, i had tested on Linux and Windows, NOT Mac OS.

According to what you say there's almost no chance it is fixed in Windows now, anyway I'll test it and open a separate bug report

[IOhannes m zmölnig]

i'm only saying that the fix is not as trivial as on linux.

i totally agree that it ought to be fixed (hence the requst for another bug-report)

[SourceForge Robot]

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).