Well in my case, one specific example of an input image is a non-subimage style stereo, with [RGB] and right.[RGB] labels. But oiiotool obviously should not have any knowledge of special labels, and the goal was to not have to pre-inspect the source images before converting to jpeg.
Thanks Larry for breaking down the categories of when oiio wants to make best default choices, vs erroring out. It does sound like a really similar situation to the fact that it does automatically throw away the alpha channel. If I have a source image with extra channels, and no channels have specifically been selected, it would seem that choosing RGB by default would be what the user most likely wants. If I knew I wanted specialized channels, I would definitely select them. Otherwise, it should probably complain about the alpha channel just as it does complain about 6 channels passing through. On Sun Feb 08 2015 at 2:11:06 PM Jono Gibbs <[email protected]> wrote: > If the input file format had 3 obvious r g b channels and then 3 which > were not related to color (z, alpha, obj-id) then it seems like keeping the > r g b channels when going to JPEG is in the spirit of "do the obvious > thing". > > If it's a 6-channel color thing then it's unlikely any 3 channels make > sense. > > Does the input format have no information like channel names? > > --jono --mobile-- > > > On Feb 7, 2015, at 4:35 PM, Larry Gritz <[email protected]> wrote: > > > > On one hand, we don't want to do operations that are not supported in > the output format, thereby resulting in significant loss of data. On the > other hand, we can't be too trigger-happy with the errors, or it would be > impossible to get anything done. So when we encounter a request to do > something not possible with a given format, we try to ask "is there a > particular thing that the human almost certainly meant when they made this > impossible request?" > > > > For example OpenEXR's least accurate pixel data type ('half') has more > precision and range than JPEG's most accurate type, so there will be data > loss, but we don't want to make every operation that starts with exr and > ends with jpg to be an error. So we just convert any input pixel data type > to UINT8 when outputting a JPEG. For most ordinary images, the data is LDR > and our eyes are mostly satisfied with 8 bits in an sRGB-mapped intensity > response, so this conversion will probably be fine. ("If you wanted to > preserve the HDR data, you should not have output to JPEG, dummy.") > > > > But what if we are asked to save more channels than a file format can > accommodate? If you just drop the channels, you're not just reducing > precision, you are losing whole sections of the original data. So at > present, we make it a hard error. > > > > As a special case (and maybe precedent?), we do just silently drop an > alpha channel when saving JPEG. JPEG cannot accommodate alpha, but it's so > common for an input to have alpha, it was painful for it to be an error > when saving to JPEG. It seemed that the obvious human interpretation was > "I'm using JPEG because this is final output for the web or for my mom to > view, the alpha that was valuable for intermediate computations won't be > needed for those purposes, so drop it." > > > > I think that at the low level of ImageInput, open() should fail if you > ask for more channels than can be supported in any obvious way. But for > oiiotool in particular, I think we can make more "best guess" heuristics. > > > > I'm certainly open to this being debated! > > > > When oiiotool is outputting to a format that doesn't support as many > channels as the image appears to have, do you think we should just silently > output the first 3 channels and drop the rest? Should this be the one and > only behavior? Or should there be a "strict/lax" option that determines > whether this (and potentially other conversions) are an error or silently > do whatever is necessary to complete the action somehow? If so, should the > default be strict or lax? > > > > -- lg > > > > > > (Note for the pedants in the crowd: most of the places I wrote "JPEG", > I'm not really talking about the JPEG compression, but rather the JFIF file > format.) > > > > > >> On Feb 5, 2015, at 3:56 PM, Justin Israel <[email protected]> > wrote: > >> > >> I was curious about some behavior in oiiotool v1.4.14, when dealing > with a source image that has 6 channels, and converting it to a jpeg. > >> > >> oiiotool source.exr -o out.jpg > >> # oiiotool ERROR: jpeg does not support 6-channel images > >> > >> I presume this bubbles up from libjpeg. Fair enough. But I know that > the mantra of OpenImageIO has usually been to try and do the right default > action, and attempt to avoid failures if possible. That being said, do you > think it would be more in line with that philosophy if the jpeg plugin > ensured it would only use 1, 3, or 4 of the first available channels, if > not using an explicit list already? That way you would still get a jpg > output, even if you passed it a 6 channel image, but could still explicitly > give is a channel list if you knew them up front. > >> > >> Currently I have to inspect the source image first before calling > oiiotool, and ensure that I pass it a reduced channel list if needed. > >> > >> Justin > > > > -- > > 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 >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
