Only first page of multi-page TIFF readable after manipulation with exiftool

Started by mtg, February 09, 2012, 11:09:15 AM

Previous topic - Next topic

mtg

Hello all,

to add some tags to dynamically produced multi-page TIFF files I use exiftool.  The images are created with GraphicsMagick and all slices/pages are readable by e.g. ImageJ (in this application the images should be used in my case). Now when I apply a small tag modification with exiftool, ImageJ only sees the first slice and the message "Unexpected image offset" appears. A different importer (Bio-Formats) crashes when trying to load the file. A modification that yields that effect (and even does relate only to the first slice) is e.g.:

exiftool -EXIF:ImageDescription="Test" exiftool_test.tiff

Because of the importing errors I got, I thought this might be a problem with exiftool (please correct me if I'm wrong). I attached a working, not modified TIFF file (exiftool_test.tiff) as well as the same file modified like in the example above (exiftool_test_mod.tiff). Do you have any idea what is going on here?

Thanks in advance,
Tom

Phil Harvey

Thanks for this report, however I can't see a problem with the modified file you sent.

I can open it successfully in GraphicConverter, Gimp and Photoshop CS4.  In GraphicConverter and Gimp I can see all of the TIFF pages fine (but I don't know how to view other pages in Photoshop, so I can't check with this).

Could it be that ImageJ and Bio-Formats aren't very TIFF compliant?

Does GraphicsMagick have any problems with the edited image?

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

MOL

Same here - no problem reading the modified file. The only thing I've noticed is a strange X and Y resolution value of 2148586752.

Uwe

mtg

Thanks for giving it a try. Interesting that these applications could read it. Actually, I found an alternative reader in ImageJ that was able to import the images. Still, I actually want to be able to use the default import routine or Bio-Formats. After all, it is working with them before modification with exiftool. Though, I am just investigating and not blaming anyone for anything :-).

Quote from: Phil Harvey on February 09, 2012, 01:00:26 PM
Could it be that ImageJ and Bio-Formats aren't very TIFF compliant?

Well, sure it could be. I will try to find out what the people from Bio-Formats and ImageJ say about my problem.

Quote from: Phil Harvey on February 09, 2012, 01:00:26 PM
Does GraphicsMagick have any problems with the edited image?

A good question. I checked this and it is able to read in the images, but after writing some artifacts have appeared in the image (I guess they are already there after importing). There seems to be some offset problem as parts of the image get shifted and some strange colored pixels appear. To demonstrate I created three TIFF stacks (each has 6 slices/pages). Attached are a file without exiftool manipulation, written with GraphicsMagick (test_noexiftool.tiff), then that same image, but additionally manipulated with exiftool (test_exiftool.tiff) and finally there is the image produced by loading and re-saving the manipulated image again with GraphicsMagick (test_exiftool+rewrite.tiff). Although I did not add an image that was rewritten by GraphicsMagick without exiftool manipulation, I tried it: no artifacts appear when read in and wrote out again after creation with no exiftool manipulation.

So it seems if there is a problem on the reader side, GraphicsMagick (this means actually libtiff) has this bug, too.

Quote from: MOL on February 09, 2012, 08:19:09 PM
Same here - no problem reading the modified file. The only thing I've noticed is a strange X and Y resolution value of 2148586752.

That value range should be alright in general and it refers to px/cm (though, this one flawed, indeed, but this has been fixed already). These images are microscopy images and have a pretty high resolution :-).

Cheers,
Tom

Phil Harvey

Hi Tom,

This is curious.  I carefully compared all of the images you sent visually using Apple Preview (which shows all TIFF pages), and could see no differences.

Also, comparing the "test_exiftool.tiff" to "test_noexiftool.tiff", there are a number of differences in the metadata for all 6 tiff pages (DocumentName, ImageDescription, Software, XResolution, YResolution, ResolutionUnit have all been changed).  Did you change all of these in ExifTool?

I suggest trying this controlled test:

1) Starting from "test_noexiftool.tiff", use exiftool to write ImageDescription only.  (I'm wondering if changing the resolutions may confuse some of the image display software, so don't change these.)  Call the output "test_exiftool2.tiff".

2) Load both "test_noexiftool.tiff" and "test_exiftool2.tiff" into GraphicsMagick, and resave each.  Call these "test_noexiftool_resave.tiff" and "test_exiftool2_resave.tiff".

3) Compare the images from step 2 to see if you can see any artifacts with your image display software.  If so, please make a screen capture showing an example of the differences.

Attach the output of steps 2) and 3) in your response, and I will look at the images closely here to see if I can reproduce this problem or figure out what is causing it.

Thanks.

- Phil

P.S.

Uwe:  Yes, I noticed this too.  Gimp actually complained about these funny resolutions, but I didn't mention this since they were the same in the original image.
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

mtg

Hi Phil,

the artifacts I mentioned before I cannot reproduce anymore. They were probably caused by a different issue I wasn't aware of before: When using GraphicsMagick as a library (as I do, in Python), the source data path must be different from the output path. There seems to be some lazy reading going on where input and output confuse each other. So there is only the issue left, that the exiftool modified images are not readable with my tools, but get readable when re-saved with GraphicsMagick.

Looking at the not-re-saved images with other tools (like the Gnome image viewer -- I'm on linux here), no problem is visible for me, too. It is just my target application: ImageJ  and tools relying on the Bio-Formats library.

So I followed your suggested test, but left out the screen capture as there are no more artifacts. The files test_noexiftool.tiff, test_noexiftool_resave.tiff and test_exiftool2_resave.tiff are readable in my tools and look as expected. Only test_exiftool2.tiff produces import problems. So the difference between test_exiftool2.tiff and test_exiftool2_resave.tiff could reveal something. That's why I also added test_exiftool2.tiff as attachment.

Sorry for adding more meta data in the last post -- this was produced by my application that actually uses exiftool. This time I only added -IFD<n>:ImageDescription="Test" to the image, where <n> goes from 0 to 5 (for each page).

Edit: The explanation I had for the artifacts above can't be true. I changed my code to ra-save to a temporary file and rename it afterwards. So I just experienced artifacts again, I'll try to reproduce that with not so much tags.

Thanks,
Tom

Phil Harvey

Hi Tom,

Thanks for running this test.  I'm glad it cleared up some confusion.

At this point it is fairly clear that ExifTool is writing the file correctly, since none of the other software tested has any problems with the exiftool-edited image.  It could be that the TIFF structure written by ExifTool is somehow causing problems for the Bio-Formats software, but I am confident that the structure conforms to the TIFF specification.  I have taken a look at the structure of both files (using the ExifTool -htmldump feature), and they are different, but both look fine.

You should ask the Bio-Formats authors why their software can't read the edited image properly.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

mtg

Hi Phil,

thanks for looking at this issue is detail. I also found out that I get the artifacts mentioned before when having newlines in meta data files and resaving them with GraphicsMagick. But again, they were only visible in ImageJ.

Quote from: Phil Harvey on February 10, 2012, 10:02:05 AM
At this point it is fairly clear that ExifTool is writing the file correctly, since none of the other software tested has any problems with the exiftool-edited image.  It could be that the TIFF structure written by ExifTool is somehow causing problems for the Bio-Formats software, but I am confident that the structure conforms to the TIFF specification.  I have taken a look at the structure of both files (using the ExifTool -htmldump feature), and they are different, but both look fine.

Alright, you convinced me that not exiftool is the problem, but the other tools I use. At least there are no obvious problems and many other programs can read the files.

Quote from: Phil Harvey on February 10, 2012, 10:02:05 AM
You should ask the Bio-Formats authors why their software can't read the edited image properly

I definitely will. Thanks again for your input on this, although your tool was not the problem in my tool chain. But, after all, there had to be a place where I start asking :-).

Cheers,
Tom