As the title states: Both the jpeg_compress_struct and the jpeg_decompress_struct in libjpeg have a field defined like this:
boolean CCIR601_sampling; /* TRUE=first samples are cosited */
I am having a hard time figuring out what this means, or how it's supposed to be used. If you try to set this flag to true, either for compression or decompression, libjpeg will simply trigger a fatal error with this message:
JMESSAGE(JERR_CCIR601_NOTIMPL, "CCIR601 sampling not implemented yet")
The "yet" is amusing because it's been this way for 20+ years now, at least back to libjpeg62.
So, what is CCIR601_sampling supposed to do? Is it meant as a user-settable parameter for compression, decompression, or both? Is it stored as part of the file format? And why has it never actually been implemented?
I have asked the libjpeg-turbo maintainer about this on the mailing list (https://groups.google.com/g/libjpeg-turbo-users/c/Aeacg_cq5ms). Here is part of the response:
To the best of my understanding, the libjpeg API and algorithms adhere to the RGB-to-YCbCr conversion formulae specified in CCIR 601 (now ITU-R Recommendation BT.601). The "CCIR601_sampling" field in the libjpeg API is meant to allow for future support of co-sited Cb and Cr samples-- that is, to allow for the sample arrangement used in MPEG-2. That sample arrangement is non-planar and specifies a row of Y samples, then a row of packed Cb/Cr samples, then another row of Y samples, etc.
... Thus, the fact that Rec. 601 sampling isn't implemented in libjpeg v6b means that JPEG files with that sampling arrangement are basically non-existent "in the wild." The JPEG specification supports other features, including a lossless mode, but ultimately, the de facto definition of the "JPEG format" converged to the subset of features implemented by libjpeg v6b (per Tom Lane's original goal.) To this day, that same chicken-and-egg phenomenon means that web browsers don't support arithmetic-coded JPEG files, even though the patent on arithmetic coding expired long ago and libjpeg-turbo supports those files.
... The "CCIR601_sampling" field remains in the API because the API structures are exposed. Thus, removing the field would break backward ABI compatibility, and backward ABI compatibility is one of the primary reasons (performance is the other) why libjpeg-turbo became the preferred open source JPEG library.
In conclusion: CCIR601_sampling was intended as a user-settable parameter to JPEG compression, which would have produced a JPEG file containing "co-sited" CbCr components (both components stored packed together as one "component", instead of remaining two separate Cb and Cr planes). On decompression, jpeg_read_header() should set the field in the structure to indicate that this JPEG is CCIR601 formatted (it is not a user-settable decompression parameter, rather an indicator)
Of course libjpeg did not support this mode, thus no JPEGs exist that use it, so there is no need to support this mode.