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
