On 11/10/2014 7:38 AM, "Larry Gritz" <[email protected]> wrote: > > 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). > >
Exactly what I had figured. The oiio side of things is always rgb and this is solely related to the jpg writer. I guess I was just confused by the fact that even thought the plugin seems to set the correct mode Rgb which says it will use no subsampling, the metadata read by identify shows 4:2:0. Maybe it is just incorrect. But if the jpg were converted with Nuke or ImageMagick, the metadata will read 4:4:4. I don't think I need any exposed settings here since it is supposed to be doing the best thing. Guess I just need to do some debugging to try and confirm if libjpeg is really doing it or not in the oiio plugin process. > > 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 >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
