On Fri, Oct 17, 2014 at 4:59 AM, Larry Gritz <[email protected]> wrote:
> On Oct 10, 2014, at 12:26 PM, Justin Israel <[email protected]> > wrote: > > 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. > > > I could be wrong, but I don't think it says that at all. OIIO is telling > the library that the *input* it is handing it is RGB and not subsampled. > That's unrelated to the color and subsampling transforms it later does in > the course of turning into a nicely compressed JPEG file. It may be > possible to have libjpeg output true RGB 4:4:4 files (I don't know, > honestly), and if so, to expose a switch to OIIO (much as we expose the > compression level). But I think what it's doing now is a sensible default > and matches most other JPEG files I've seen. > > I completely agree that the best overall approach is to do the sensible defaults. In this particular case, a colleague is attempting to replace a previous conversion approach with oiio, but finding a different in the jpeg output. So the goal would be to produce the same thing as before. > Maybe it is just incorrect. But if the jpg were converted with Nuke or > ImageMagick, the metadata will read 4:4:4. > > Does it? Hmmm. I wasn't aware that we were doing anything unusual. How > much does the compression ratio take a hit from not subsampling Cb/Cr? > In a test I was given: oiio_output.jpg Sub-sampling: 4:2:0 Size: 594K nuke_output.jpg Sub-sampling: 4:2:2 Size: 631K > > What comes out of most digital cameras (when saving as JPEG, rather than > RAW)? > I checked one of my own digial camera jpegs and it reported 4:2:2 > > I don't think I need any exposed settings here since it is supposed to be > doing the best thing. > > I'm more than happy to add a control, if you can figure out how to > instruct libjpeg to turn off the subsampling. I'm still unsure what the > default should be. For file output, we usually don't aim for "the best > thing", but rather default to "the usual thing" or "the thing most readers > expect and can handle." I would be surprised if anybody was using JPEG for > high fidelity, I usually imagine that when you save to JPEG you are aiming > for a fairly high compression ratio and are willing to tolerate some > lossiness in the process. Any way you slice it, JPEG is limited to 3 > channel, 8 bit, LDR. It's just not a good archival format for high fidelity > imagery. > Actually as I got to this point in replying to this email, and going back and forth looking things up, I think I just found the source of controlling this output! 1. oiio calls jpeg_set_defaults <https://github.com/OpenImageIO/oiio/blob/master/src/jpeg.imageio/jpegoutput.cpp#L172> () (libjpeg) 2. jpeg_set_defaults calls jpeg_default_colorspace() <https://github.com/LuaDist/libjpeg/blob/master/jcparam.c#L372> 3. Because the in_color_space was set to JCS_RGB, it then chooses the jpeg_color_space to be YCbCr <https://github.com/LuaDist/libjpeg/blob/master/jcparam.c#L387> 4. jpeg_set_colorspace() is called with JCS_YCbCr <https://github.com/LuaDist/libjpeg/blob/master/jcparam.c#L454> which defaults to 4:2:0 So maybe the solution is to offer some constants like: - "4:4:4" - Calls jpeg_set_colorspace() with JCS_RGB - "4:2:2" - does this <https://github.com/LuaDist/libjpeg/blob/master/jcparam.c#L454>, but uses SET_COMP(0, 1, 2,1, 0, 0,0); for the first component instead - "4:2:0" - Does exactly what it does now - "4:1:1" - uses 4,1 1,1 1,1 for the 3 components Does that sound reasonable? Then you get as much control as Nuke/imagemagick would offer > > > -- > 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
