This works only for RGB mode 4:4:4 data (no subsampling). AFAICT, we don't support YCbCr subsampling directly when saving to TIFF, but the tag might be copied over from another info structure, so might be an idea to handle it?

However, there's something weird going on wrt to saving YCbCr mode instead of RGB, even if using single strip (i.e. 8.2.0):

OSError: encoder error -9 when writing image filejunk.tiff: Warning, fractional scanline discarded.JPEGLib: Application transferred too few scanlines.

Thanks, that leaves YCbCr mode TIFF saving which it seems never worked w/ JPEG compression?

I also tried settingifd[530] = (1,1) (YCbCr subsampling to 4:4:4) as the default is (2,2) which doesn't correspond to the data, but the encoder doesn't like that - I think unfortunatelyTIFFSetField interface is different for this tag (2 ints) compared to the expected count+pointer (e.g. ExtraSamples)? Settingatts[530] = 1 didn't work either.

YCbCr saving doesn't even work uncompressed (i.e. no libtiff involved), even if I add correct tags 530, 531, and 532. I guess this is a separate issue.

Uncompressed YCbCr 4:4:4 seems to work after all (if correct tags 530 and 532 are added). Just that most viewers don't seem to support it...

However, there is a clearbug w/ libtiff_encoder, as it tries to save tag 530 2-tuple with a "default" type LONG (i.e. count+offset), which doesn't fit into the expected 4 bytes value/offset sub-field as 2 SHORTs would.