No rush, I just wanted to take care of it while it was still fresh in my mind, and yesterday was a work holiday in BC.
On Feb 10, 2015, at 2:02 PM, Justin Israel <[email protected]> wrote: > Wow you did the whole she-banga-bang already! Awesome! > > I would love to give it a test, but won't be able to until probably tomorrow. > But if it handles 5-channel case => jpeg, as well as the alpha-only > single-channel case => jpeg, as advertised...I would say it looks great to me! > > > > On Wed Feb 11 2015 at 09:37:23 Larry Gritz <[email protected]> wrote: > Justin, how about this: https://github.com/OpenImageIO/oiio/pull/1058 > > > On Feb 8, 2015, at 12:00 PM, Justin Israel <[email protected]> wrote: > >> >> >> On Sun Feb 08 2015 at 19:05:49 Larry Gritz <[email protected]> wrote: >> 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. >> >> Actually, your mixture of the two approaches would probably be best. Funny >> thing... just this morning I got bit by assuming the first 3 channels would >> be ok... Turned out it was an exr with 4 channels: >> >> B >> matte >> G >> R >> >> Go figure. >> >> >> >>> 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.) >> >> >> Hah. Well I meant viewers that can actually display the formats ;-) >> >> >> >>> >>> >>> 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 >> _______________________________________________ >> 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
