2019.01.13 21:58 "Re: [Tiff] tiffcp altering image contents (in contrast to what the manual says)?", by Binarus

Dear Bob,

thanks again for taking the time.

On 13.01.2019 20:17, Bob Friesenhahn wrote:

"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?

> GraphicsMagick uses libtiff to write TIFF so it will never output OJPEG compression.  However, since February 7, 2015, GraphicsMagick uses YCbCr encoding when JPEG compression is requested for an RGB image because the resulting file is much smaller.  This might be a factor.

The relationship between GraphicsMagick and libtiff is very interesting. Thanks for bringing it to my attention.

However, I think I have missed something here, or I don't understand this completely.

Our problem is that

tiffcp 1.tif 2.tif out.tif

produces out.tif which is substantially smaller than the sum of 1.tif and 2.tif. This behavior is unexpected at the first sight regardless of how 1.tif and 2.tif have been created themselves.

Even when we assume that it is important how 1.tif and 2.tif have been created: We are using GraphicsMagick 1.3.25 from Sep 2016 to create the source files for the tiffcp operation, so they should be already encoded with the "new" YCbCr method, i.e. their sizes should be "as small as possible". How could tiffcp then make them even smaller (letting apart that it shouldn't touch the image data at all according to the manual (perhaps with the exception Richard Nolde mentioned))?

Thank you very much for your time and expertise,

Binarus