On Feb 7, 2015, at 6:21 PM, Justin Israel <[email protected]> wrote:
> Personally I would be happy with selecting the first 3 or 4 channels (or the > number supported by the output format) under that given circumstance, but if > we want to go the extra mile and do some checking, maybe that would be a > plus? On one hand, it seems smarter to try to pull out the R, G, B among them, regardless of the order. But that should be weighed against the distinct possibility that the channels are not named simply, or are even mis-labeled. I'll think about this a bit. Maybe an even more convoluted approach is best: If the channel names contain is an identifiable R, G, B, use those (regardless of original order), otherwise use the first 3 channels and hope for the best? I think most of the time these should be equivalent, because the OIIO guidelines say that a format reader should reshuffle as necessary to make R,G,B,A always be the first 4 channels, regardless of their appearance in the file. > Maybe this is a dumb question, but what do you think the average image viewer > does when displaying images with arbitrary channels? Do they look for R,G,B > labeled channels, or maybe load the first N channels? Ha! I think the *average* viewer either crashes, refuses to load the image at all, or loads it but totally botches the memory layout and thus mis-draws the image, like this: image: R G B A X Y | R G B A X Y | display: | | | | (I hope that comes out right, it takes a mono font on those lines to make the spacing right.) > > > On Sun Feb 08 2015 at 2:36:26 PM Larry Gritz <[email protected]> wrote: > OK, so how about this proposed heuristic for oiiotool: > > If the output format doesn't support as many channels as the input image, > then it will perform the equivalent of "--ch R,G,B" (or "R,G,B,A", if the > format does support an alpha channel) before saving. If the input doesn't > contain (somewhere in it) channels named R, G, and B, then it's an error. > > Or should we just ignore the issue of specific channel names and write the > first 3 (or 4) channels and call it a day? > > -- lg > > > PS. WTF, Jono, don't you have someplace more important to be tonight? > > > On Feb 7, 2015, at 5:20 PM, Justin Israel <[email protected]> wrote: > >> 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 > > -- > 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 -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
