On Sat, Aug 4, 2012 at 3:28 AM, Larry Gritz <[email protected]> wrote: > I hope you don't mind that I'm CCing oiio-dev with my reply. > > This is an interesting question. Currently, if you try to open a file for > output and request a number of channels that it can't support, the open() > call will fail. That said, it does seem an entirely reasonable operation to > want to convert, say, an RGBA file to a format that does not support alpha, > by copying the RGB only. > > I'm curious to hear people's opinions on how to address this problem. I can > think of several possible strategies: > > 1. (Logic in the plugins) Change the JPEG (and/or others) output to silently > and automatically truncate channels if asked to write more channels than the > format supports, much like how it will force uint8 data (because that's all > JPEG supports) even if you ask for something else. Or, we could keep the > default as it is (fail), but have JPEG support a request by the app to > truncate channels (via the "open with config" call) and have iconvert and > certain other apps make that request. > > 2. (Logic in the app) Leave the drivers alone, but make iconvert and oiiotool > check the failure messages and, if an open() fails and nchannels > 3, make an > intelligent guess by trying to open the file a second time with fewer > channels, and if that succeeds, output that way. > > 3. (Logic in the user's head) Add a --channels option to oiiotool that lets > you explicitly prune or shuffle channels, so you could > > oiiotool my5channelfile.exr --channels R,G,B -o besticando.jpg > > > Opinions? None are very hard, I can fix right away, but first I'd like to > get consensus on which level of the onion ought to have the control of this > behavior.
I don't like option 1. IMHO it would be nasty for the output plugins to be too opinionated about what channels they care to save. If I'm using the C++ API I don't want my hand held, I just want it to do what I say and if that's impossible then fail with a useful error :) Furthermore, if all we really want is some uniform logic like in option 2, there's no point putting it in each and every output plugin. Either of options 2 or 3 seem reasonable though personally I like option 3 because it gives the most flexibility and seems the most well defined. ~Chris _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
