2005.05.05 19:26 "[Tiff] TiffScanlineSize", by Jean Yves Le Ridant
I'm working to 12 bits jpegs in tiff files.
For now, for jpeglib side, most is done, for runtime selection of 12 bits or 8 bits data ( in one or two bytes samples ). In libtiff, all that is processed by Decode/Encode ( not raw ) is ok: 8 bits, 12 bits packed, and 16 bits.
Yes 16 bits Jpeg, a 16 bits jpeg compression begin by a bandwitdh reduction to 12 bits, everybody know that... :-)
Work with most of the tools coming with libtiff. So linked with ImageMagik for sample, loading 12/8 bits jpegs, 8/16 bits tiffs. Not 12 at this time, cause Readrgba to make aware.
Problems come with DecodeRaw/EncodeRaw process. This concern in turn, case ContigDownsampled <--> ContigDownsampled compress/decompress. Thing independant of data precision and is the same for native libs 8 bits.
TiffScanlineSize do not take account of downsamplings for contig downsampled YCC. I don't find in specs or docs if this is "by definition" or buggy.
This cause a lot of problems in the "raw" scheme. "bytesperline" member do not match the real count byte input/output to/from jpegcodec, and cause "too much, too few, fractionnal... scanlines" errors.
Have made a correction, limited to tiffjpeg ( if in tif_strip... ;-((( ), and intensively test the things with rgbtoycbcr, tiffcp, tiff2rgba, ---> files 571x379, stripped or not, with downsamplings 2 2, 1 2, 2 1, jpeg compressed or not.
Except 2 1 ( tiffrgba don't want ) all files are correct and well displayed by imagemagick, the gimp, psp. Photoshop want only jpegs.
The question about scanlinesize, is because I need to be sure of the exact meaning of returned value, before doing some job for 12 bits support.
Another point, is about "tif->tif_row" member. For stripped files, it's value is relative to the beginning of the strip, not the file. Is this correct?