[Tiff] Code for decoding of CFA tags

2023-02-07 Thread David C. Partridge
I've found 3 tiff tags that appear to relate to the use of CFA (Bayer)
images in tiff files:



a.  33421 (0x828D) CFARepeatPatternDim and 33422 (0x828E) CFAPattern,
and

b)   41730 (0xA302) CFAPattern

 

Assume that I have little prior experience of coding for tiff.

 

1.  Would I be correct in assuming that in any given TIFF I would find
either a) or b) but not both?  If not which should take precedence?
2.  If these tags are present could some-one please point me to code
that will correctly interpret them for de-Bayering the data.
3.  Is there anything like the FITS XBAYROFF/YBAYROFF headers to worry
about?



Cheers, David

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


Re: [Tiff] tiffcrop tool ~ JPEG compression options produce wrong output

2023-02-07 Thread miguel medalha

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

I don't think so. tiffcp's default is YCbCr  and the "r" option specifies RGB, 
which is exactly what 'tiffinfo' is showing.

-c jpeg[:opts]  compress output with JPEG encoding
#set compression quality level (0-100, default 75)
routput color image as RGB rather than YCbCr


> ❯ tiffcp -c jpeg -r 16 ./libtiff/test/images/quad-lzw-compat.tiff 
> /tmp/test.tif

> ❯ tiffinfo /tmp/test.tif
>   Compression Scheme: JPEG
>   Photometric Interpretation: YCbCr


> ❯ tiffcp -c jpeg:r -r 16 ./libtiff/test/images/quad-lzw-compat.tiff 
> /tmp/test.tif
> 
> ❯ tiffinfo /tmp/test.tif
>   Compression Scheme: JPEG
>   Photometric Interpretation: RGB color


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


Re: [Tiff] tiffcrop tool ~ JPEG compression options produce wrong output

2023-02-07 Thread L. E. Segovia via Tiff
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