2012.04.28 09:28 "Re: [Tiff] YCbCr/JPEG issue in 4.0.1", by Joris Van Damme

Charles,

> Yes, I confess, I am one of those lazy JPEGCOLORMODE = 1 people.

I don't agree with the term 'lazy'. It boils down to bad library design, rather then lazy library usage.

As YCbCr can be combined with any compression mode, and subsampling can be combined with one/some/all colorspaces depending on your point of view, and any compression mode, it's actually the TIFF container codec that should be responsible for subsampling/desubsampling, and the TIFF RGBA interface part that should be responsible for converting from RGB to YCbCr and the other way around, rather then partly delegating the task to a particular subcodec and failing to support combinations with other subcodecs, and/or partly delegating the task to the TIFF library user.

Actually, encoding/decoding TIFF should be viewed as a pipeline. TIFF is not Thousands of Incompatible File Formats, because rather then providing support for all possible combinations, the codec ought to freely chain independent support for different features. Subsampling and desubsampling, as well as color conversions, are simply parts of the chained pipeline of freely combinable features, and should be supported as such, independently of other features such as a particular compression or decompression. That's how TIFF is more like 5+5+5+5+5 = a manageable number of combinable features, rather then 5*5*5*5*5 = an unfeasible number of incompatible formats. This concept should be at the heart of any TIFF codec. All required support for subsampling and desubsampling as well as any color conversions, is merely part of this.

Best regards,

Joris