Legacy ImageMagick Discussions Archive

Hello, All,
I work for a cultural heritage institution that is converting a large number of TIFF files to JP2 to reduce our storage footprint. In order to ensure the validity of the conversion, I am using the "compare" function ('compare -metric AE [original.tif] [converted.jp2] null:'). I am looking for a result of 0, meaning presumably that there are no different pixels between the original and the derivative.

I have noticed that a number of our TIFF's have thumbnails embedded in IFD1. For those images, if I run the comparison using the TIFF as the first argument, the result is that none of the pixels match. However, if I use the JP2 as the first argument, the comparison shows that all the pixels match.

I also ran the comparison after stripping out the IDF1 thumbnail using ExifTool ('exiftool -IFD1:all= -m [original.tif]'). Again, the comparison fails if I run it with the original first, but succeeds if I run it with the stripped file first.

Obviously, the presence of the thumbnail affects the comparison, but so does the order of the input images on the command line - I'd like to know more about why, and why switching the order of input images changes the result. I need to know whether the check is valid.

Can anyone explain how the compare function determines what to compare and why it seems to include or omit IFD1 depending on whether that image is the first or second argument position?

Thanks for any insight you can provide.

–Dean Smith

What version of IM on what platform?

Try: Does that show one image, or more than one? If more than one, then that's the problem because both images will be read. "compare" will compare only the first two images in the list. The suffix [0] will load only the first image from the tiff.

deanforsmith wrote:... a cultural heritage institution that is converting a large number of TIFF files to JP2 to reduce our storage footprint.

My advice: don't do it. JPG is lossy. You will lose data by doing this. This will prevent future users of the images doing what they want to do in 5 or 10 years from now.

Hi, thanks for your response.

I'm running version 7.0.8-28 on Mac OSX Mojave.

And just to clarify - we're converting TIFF's to lossless JPEG-2000, part 1, not jpg. NARA just released guidance that JP2 is an acceptable archival format.

Could you clarify what you mean in your central paragraph? When you say compare will only compare the first 2 images in the list, which list do you mean? Do you mean the 2 image files I'm passing as arguments, or do you mean the 2 bitstreams in IFD's in the original TIFF? Are you saying if I include a suffix [0], it will skip the thumbnail in IFD1? Where would I include that suffix on the command line?

I could take this to mean that compare looks at the first image file, then looks for matching components in the second - by passing the thumbnail-less version first, compare doesn't need to account for the embedded thumbnail in the second. Is this what you're getting at?

Best,

–Dean

"compare" doesn't simply compare two image files. It actually takes one or more filenames and reads all the images it finds. So it has a list of images: all the images from the first file, then all the images from the second file. Then it compares the first two images in that list, ignoring all other images. Hence, if your first file contains two or more images, only the first two of its images will be compared, and images in the second file will be ignored.

Got it - that readily explains what I am seeing.

It does seem like a behavior that could undermine the feature's usefulness, depending on the types of files one hopes to compare...

Thanks!

If you only want the first image from the TIFF file, you can do this: For confirmation of what images have been read, insert "+write info:" before the "NULL:", eg: