2019.01.13 17:04 "Re: [Tiff] tiffcp altering image contents (in contrast to what the manual says)?", by Binarus
thank you very much for your answer.
> It's been quite a while since I've looked at the source code to tiffcp,
> but I seem to remember that OLD JPEG encoding is no longer supported in
> the output stage so most likely what is happening is that the data is
> being re-encoded in new JPEG format. Here is a note from the tiffcrop
> man page that makes this explicit:
> compression is only usable on 8 bit per sample data (or 12
> bit if LibTIFF was compiled with 12 bit JPEG support). Support for
> OJPEG compressed images is problematic at best. Since OJPEG
> compression is no longer supported for writing images with LibTIFF,
> these images will be updated to the newer JPEG compression when
> they are copied or processed. This may cause the image to appear
> color shifted or distorted after conversion. In some cases, it
> is possible to remove the original compression from image data
> using the option -cnone.
> When I wrote tiffcrop, I was aware of this issue and added the paragraph
> above to the man page for tiffcrop.
This is a problem we regularly will have to deal with in the future. My feeling is that you are right, so we will have to change how the source files are created in the first place. Basically, they are the outcome from the following steps (I am concentrating on the JPEG-compressed ones, because the others don't seem to be a problem):
- We get uncompressed TIFF files from elsewhere (24 BPP, JPEG-compressed), each of them containing one image (page) per file; as an example, there may be two of them with names a.tif and b.tif.
- Then we JPEG-compress each of these and merge them, using GraphicsMagick under Windows, to create the source files (like 1.tif as mentioned in my first message). The respective command line reads like that:
"C:\Program Files\GraphicsMagick-1.3.25-Q16\gm.exe" convert a.tif b.tif -compress jpeg -quality 90 1.tif
If I got you right, GraphicsMagick probably applies the problematic OJPEG compression when executing the command above. We will investigate if we can change that. In the meantime, if our investigations don't lead to anything, could you eventually give a hint regarding an alternative procedure for that first step?
Thank you very much again,