Hmmm... sometimes it will fail outright, sometimes it will save only certain
channels, and it will depend on how they are named? That sounds awfully
confusing to me.
-- lg
On Aug 4, 2012, at 4:35 AM, Hugh Macdonald wrote:
> I would suggest that the writer should automatically truncate channels that
> it doesn't know how to deal with. If this leaves fewer channels than it is
> expecting (e.g. an EXR with no RGBA, but beauty.r, beauty.g, beauty.b), then
> it should gracefully error (or maybe it could try to intelligently pick other
> channels to show? This sounds dangerous to me, unless there are only R, G, B
> channels but named differently, as in the example above).
>
> The user would then also be able to specify channel shuffling if they want to
> use different channels, or if there is, as in the example above, no
> definitive channel group.
>
> Hugh Macdonald
> nvizible – VISUAL EFFECTS
>
> +44(0) 20 3167 3860
> +44(0) 7773 764 708
>
> www.nvizible.com
>
>
>
> On 3 Aug 2012, at 18:28, Larry Gritz 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.
>>
>>
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
