The line

>         m_cinfo.in_color_space = JCS_RGB;


just indicates that the INPUT we are feeding it is 3 channel RGB, but the 
storage of it once converted to a JFIF file is YCbCr subsampled (as shown in 
the second code snippet you cite).

OIIO's jpeg writer doesn't get too much in the details of the jpegs, just use 
the defaults except for requesting an overall compression level. It's possible 
that the jpeg library has API calls to force certain non-default choices such 
as no subsampling. If this is true, we could expose the choice in case you want 
to request it.

Either way, the data passed in and out of the OIIO APIs are always RGB and 
never subsampled. Subsampling or other color spaces for storage always happen 
within a particular format reader/writer, NEVER on the application side of the 
OIIO APIs (by design).



On Oct 6, 2014, at 7:35 PM, Justin Israel <[email protected]> wrote:

> Hi all,
> 
> I'm trying to confirm some behavior for a co-worker that is comparing jpeg 
> conversions from oiiotool with a previous conversion approach. 
> 
> His concern is the chroma sub-sampling that is applied to the jpegs, as being 
> identified using the "identify" tool provided by ImageMagick, indicate a 
> 4:2:0 sampling. My thoughts are that this reported information may just be 
> metadata and not really applicable to the image necessarily. Anyways, the 
> details...
> 
> Input jpeg, via identify, reports 4:4:4:
> jpeg:sampling-factor: 1x1,1x1,1x1
> 
> Output Jpeg from oiiotool, via identify, reports 4:2:0:
> jpeg:sampling-factor: 2x2,1x1,1x1
> 
> The jpeg output plugin uses some fixed logic for 3 or 4 channel
> 
> // oiio:jpegoutput.cpp#L447
>     if (m_spec.nchannels == 3 || m_spec.nchannels == 4) {
>         m_cinfo.input_components = 3;
>         m_cinfo.in_color_space = JCS_RGB;
> 
> When using this color space constant, the defaults for libjpeg
> are to apply a 4:4:4 (no sub sampling)
> 
> // libjpeg:jcparam.c#L152
>   case JCS_RGB:
>     cinfo->write_Adobe_marker = TRUE; /* write Adobe marker to flag RGB */
>     cinfo->num_components = 3;
>     SET_COMP(0, 0x52 /* 'R' */, 1,1, 0, 0,0);
>     SET_COMP(1, 0x47 /* 'G' */, 1,1, 0, 0,0);
>     SET_COMP(2, 0x42 /* 'B' */, 1,1, 0, 0,0);
>     break;
>   case JCS_YCbCr:
>     cinfo->write_JFIF_header = TRUE; /* Write a JFIF marker */
>     cinfo->num_components = 3;
>     /* JFIF specifies component IDs 1,2,3 */
>     /* We default to 2x2 subsamples of chrominance */
>     SET_COMP(0, 1, 2,2, 0, 0,0);
>     SET_COMP(1, 2, 1,1, 1, 1,1);
>     SET_COMP(2, 3, 1,1, 1, 1,1);
>     break;
> 
> Can someone more versed than I in these RGB vs YCbCr spaces and sub-sampling 
> help clarify the actual end result on the converted jpeg through oiio? Is 
> this sub-sampling value reported by identify irrelevant because of the color 
> space being RGB?
> 
> Thanks!
> -- justin
> 
> 
> _______________________________________________
> Oiio-dev mailing list
> [email protected]
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
[email protected]



_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Reply via email to