AWARE [SYSTEMS]
AWare Systems, , Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
January 2019

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
Archive maintained by AWare Systems



New Datamatrix section



Valid HTML 4.01!



Thread

2019.01.12 17:25 "tiffcp altering image contents (in contrast to what the manual says)?", by <lists@binarus.de>
2019.01.12 19:09 "Re: tiffcp altering image contents (in contrast to what the manual says)?", by Bob Friesenhahn
2019.01.12 21:07 "Re: Tiff Digest, Vol 3, Issue 3", by Richard Nolde
2019.01.13 15:41 "Re: tiffcp altering image contents (in contrast to what the manual says)?", by <lists@binarus.de>
2019.01.13 19:24 "Re: tiffcp altering image contents (in contrast to what the manual says)?", by Bob Friesenhahn
2019.01.13 17:04 "Re: tiffcp altering image contents (in contrast to what the manual says)?", by <lists@binarus.de>
2019.01.13 18:31 "Re: tiffcp altering image contents (in contrast to what the manual says)?", by <lists@binarus.de>
2019.01.13 19:17 "Re: tiffcp altering image contents (in contrast to what the manual says)?", by Bob Friesenhahn
2019.01.13 21:58 "Re: tiffcp altering image contents (in contrast to what the manual says)?", by <lists@binarus.de>

2019.01.13 21:58 "Re: tiffcp altering image contents (in contrast to what the manual says)?", by <lists@binarus.de>

Dear Bob,

thanks again for taking the time.

On 13.01.2019 20:17, Bob Friesenhahn wrote:
> On Sun, 13 Jan 2019, Binarus 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

_______________________________________________
Tiff mailing list
Tiff@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/tiff