Hi,

A quick check tells me tiffcp does suffer from this bug:

> ~/Documents 
> ❯ tiffcp -c jpeg -r 16 ./libtiff/test/images/quad-lzw-compat.tiff 
> /tmp/test.tif
> LZWPreDecode: Warning, Old-style LZW codes, convert file.
> 
> ~/Documents 
> ❯ tiffinfo /tmp/test.tif
> === TIFF directory 0 ===
> TIFF Directory at offset 0x5b6e (23406)
>   Image Width: 512 Image Length: 384
>   Position: 0, 0
>   Bits/Sample: 8
>   Compression Scheme: JPEG
>   Photometric Interpretation: YCbCr
>   Orientation: row 0 top, col 0 lhs
>   Samples/Pixel: 3
>   Rows/Strip: 16
>   Planar Configuration: single image plane
>   Reference Black/White:
>      0:     0   255
>      1:   128   255
>      2:   128   255
>   JPEG Tables: (574 bytes)
> 
> ~/Documents 
> ❯ tiffcp -c jpeg:r -r 16 ./libtiff/test/images/quad-lzw-compat.tiff 
> /tmp/test.tif
> LZWPreDecode: Warning, Old-style LZW codes, convert file.
> 
> ~/Documents 
> ❯ tiffinfo /tmp/test.tif
> === TIFF directory 0 ===
> TIFF Directory at offset 0xb8ce (47310)
>   Image Width: 512 Image Length: 384
>   Position: 0, 0
>   Bits/Sample: 8
>   Compression Scheme: JPEG
>   Photometric Interpretation: RGB color
>   Orientation: row 0 top, col 0 lhs
>   Samples/Pixel: 3
>   Rows/Strip: 16
>   Planar Configuration: single image plane
>   JPEG Tables: (289 bytes)
> 
> ~/Documents 
> ❯ tiffcp --version
> tiffcp: illegal option -- -
> LIBTIFF, Version 4.4.0
> Copyright (c) 1988-1996 Sam Leffler
> Copyright (c) 1991-1996 Silicon Graphics, Inc.

Looks like it's really really /really/ old, the interpretation was set
here:
https://gitlab.com/libtiff/libtiff/-/commit/cbc821458661bed9ab092568a556ffeaa065ab8d

Also, using `tiffcrop` here errors out consistently with:

> libtiff on  master [!] via C v13.0.0-clang via △ v3.25.2 
> ❯ ./build/tools/tiffcrop -c jpeg:raw -r 16  
> ./test/images/quad-lzw-compat.tiff  /tmp/test.tif
> LZWPreDecode: Warning, Old-style LZW codes, convert file.
> JPEGSetupEncode: RowsPerStrip must be multiple of 8 for JPEG.
> /tmp/test.tif: Error, can't write strip 0.
> : Unable to write contiguous strip data for page 0.

Tiffcrop overrides whatever the user sets with the -r flag, so there's
no way to tell it to use a more appropriate strip size:
https://gitlab.com/libtiff/libtiff/-/blob/master/tools/tiffcrop.c#L7020

Best,

amyspark

On 06/02/2023 21:34, miguel medalha wrote:
> The tiffcrop  is inverting RGB and YCbCr output when using jpeg compression.
> 
> The stated YCbCr default (no format specified) works correctly:
> 
> 'tiffcrop -c jpeg infile.tiff outfile.tif'              the output is a YCbCr 
> file (default behavior)
> 'tiffinfo outfile.tif'                               'Photometric 
> Interpretation: YCbCr'
> 
> But if we request a specific mode using the proposed 'rgb' and 'raw' jpeg 
> options:
> 
> 'tiffcrop -c jpeg:raw infile.tiff outfile.tif'        the output is a RGB file
> 'tiffinfo outfile.tif'                            'Photometric 
> Interpretation: RGB color'
> 
> 'tiffcrop -c jpeg:rgb infile.tiff outfile.tif'          the output is a YCbCr 
> file
> 'tiffinfo outfile.tif'                          'Photometric Interpretation: 
> YCbCr'
> 
> When we request RGB a YCbCr file is produced, when YCbCr is requested a RGB 
> file is produced.
> 
> This has been reported 2 years ago as Issue #228, but still not addressed. Is 
> this considered of lesser importance? I would certainly fix it if I knew how 
> to do it...
> 
> I know that the work on libtiff is voluntary, which I very much appreciate 
> and am grateful for. I just thought I would leave a reminder here, in case 
> the issue had just been inadvertently buried in time.
> 
> tiffcp does not suffer from this drawback.
> 
> _______________________________________________
> Tiff mailing list
> Tiff@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/tiff

-- 
amyspark 🌸 https://www.amyspark.me
_______________________________________________
Tiff mailing list
Tiff@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/tiff

Reply via email to