[GEM-dev] [ pd-gem-Bugs-3222807 ] pix_image support for TIFF incomplete (linux)

[SourceForge.net]

Bugs item #3222807, was opened at 2011-03-18 14:28
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3222807&group_id=64325

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pixes (pix_ objects)
Group: linux
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: pix_image support for TIFF incomplete (linux)

Initial Comment:
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.

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2011-04-20 19:20

Message:
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).

----------------------------------------------------------------------

Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2011-04-07 09:39

Message:
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)

----------------------------------------------------------------------

Comment By: Matteo Sisti Sette (sistisette)
Date: 2011-04-07 08:46

Message:
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

----------------------------------------------------------------------

Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2011-04-07 08:11

Message:
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 :-))

----------------------------------------------------------------------

Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2011-04-07 07:54

Message:
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.




----------------------------------------------------------------------

Comment By: Matteo Sisti Sette (sistisette)
Date: 2011-04-06 19:32

Message:
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.



----------------------------------------------------------------------

Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2011-04-06 19:19

Message:
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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=507079&aid=3222807&group_id=64325