2006.09.27 04:21 "[Tiff] YCbCr data in tiffcrop", by Richard Nolde

Joris / Bob/list,

The routines that I am using for reading and writing the data are exactly those used in tiffcp now and they handle strips and tiles in contiguous and separate planar configurations. I found no indication that they made any distinctions based on the color model or compression since they call low level libtiff routines to handle the codecs. They are documented as delivering the uncompressed data to the specified buffer in scanlines or tiles as requested. I deduced by experiment, that this buffer is always arranged as plannar config contiguous for all the sample formats that I have been able to handle correctly. I surmise that YCbCr data comes in differently because the resulting image is shifted half an image width and badly color shifted but vaguely recognizable when I try to mirror it horizontally. When mirrored vertically, it gets chopped up into 4 quadrants with a stripe in the center. Based on the explanation of YCbCr, which is admittedly over my head, my simple copying and/or chopping of portions of the image based on bits per sample and samples per pixel is probably not going to work here unless I can reorder the data in the read buffer to resemble a multi-byte per pixel sample with a known number of bytes to grab for each pixel. RGBA works fine, but the sequence described by Joris doesn't look too promising for pointer offset slicing and dicing. I don't need YCbCr for my project but I wanted to try to support all the options that tiffcp does since tiffcrop is a superset of tiffcp. Given an infinite amount of time, I would like to add more functions like multi-page splitting capabilities found in tiff2ps so that one image can be spread over multiple output images. Tiff2ps relies on the Postscript mask operator to do this but it is very inefficient storage wise as it keeps a copy of the entire image for each page and just masks off different regions each time. My code from tiffcrop could be ported to tiff2ps to store only the cropped portion in each image.

Richard Nolde

This applies to all forms of subsampled YCbCr, uncompressed, LZW compressed, flate compressed, whatever. Unfortunately, the LibJpeg library returns another

> > organisation, and a convertion needs to be made...

I meant, a convertion needs to be made inside tif_jpeg.c, that may not have been clear. The purpose of this conversion is to take data organisation as returned by LibJpeg, and reformat it into the compression-independent organisation that is assumed by the rest of the library, thus making all subsampled YCbCr organisation uniform.

I think there's currently a bug left in exactly this part of tif_jpeg.c, presumably, seeing the output of some image, but I've not yet had the time to investigate properly. This may additionally make it hard for Richard to add subsampled YCbCr support inside tiffcrop, unless he chooses to work from uncompressed subsampled YCbCr testimages and drops the use of JPEGCOLORMODE_RGB if he's using it right now, which I'd recommend anyway since that is the single shortest path to full compression-independent support for subsampled YCbCr.