OpenEXR channel naming parameters

[Paul Gregory-4]

All,

At last nights meeting the mechanism used to name channels in the new multi-layer OpenEXR support was questioned. At the moment, for robustness sake, the channels are named with individual parameters, this means that should insufficient names be provided for the number of elements in a layer, the system will provide sensible defaults. An example...

Display "name.exr" "exr" "Cs" "string layername" "Cs" "string channelname0" ["r"]

This would result in channels named...

Cs.r
Cs.G
Cs.B

with "G" and "B" being defaults, as custom names for those channels were not supplied.

An alternative suggestion was to provide a single parameter with an array of strings for the channel names. This seems like a cleaner and neater solution, an example...

Display "name.exr" "exr" "Cs" "string layername" "Cs" "string channelnames" ["r" "g" "b"]

This is a lot neater and more concise but suffers from one small problem, if the user were to issue the following request...

Display "name.exr" "exr" "Cs" "string layername" "Cs" "string channelnames" ["r" "g"]

...there is no way for Aqsis to identify that insufficient channel names have been provided, it will assign a name to the blue channel from random memory, potentially causing a segfault. While this sounds like a serious negative, the problem exists at many many other places due to the nature of the RIB interface. There is inherently no way to range check array parameters in RIB.

The question is, should we go for the neater solution, and accept that it introduces a potential weakness in the face of incorrect data (one that exists already in many other RIB requests), or go with the more verbose but safer solution?

I'll leave the question open for the rest of today, then I need to implement a final solution in order to complete this before phase 2 of 1.6.0, if no feedback is forthcoming, I'll probably go with the neater single array solution.


Paul

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Matthias Baas-3]

Paul Gregory wrote:
> Display "name.exr" "exr" "Cs" "string layername" "Cs" "string
> channelname0" ["r"]
> [...]
>
> Display "name.exr" "exr" "Cs" "string layername" "Cs" "string
> channelnames" ["r" "g" "b"]

How about passing just a single string and parsing that somewhere within
the RiDisplay() call?

  Display "name.exr" "exr" "Cs" "string layername" "Cs" "string
channelnames" "r,g,b"

But what if I want to put more than just 1 layer into the file? I
suppose I can't have the same parameter names ("layername",
"channelnames") twice in the same call.
Wouldn't it at this point make sense to implement the RiDisplayChannel()
call and move the functionality there? (do other renderers actually
support renaming the channels and if so, how do they do it?)

- Matthias -


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Paul Gregory-4]

2009/8/17 Matthias Baas <matthias.baas@...>

How about passing just a single string and parsing that somewhere within
the RiDisplay() call?

 Display "name.exr" "exr" "Cs" "string layername" "Cs" "string
channelnames" "r,g,b"

We've settled at the moment on a single parameter, with an array of names, with the parameter
ideally being specified with the correct array size, at least allowing the RIB parser to validate the
data, i.e.

Display "name.exr" "exr" "Cs" "string layername" "Cs" "string[3] channelnames" ["r" "g" "b"]
 

But what if I want to put more than just 1 layer into the file? I
suppose I can't have the same parameter names ("layername",
"channelnames") twice in the same call.

This is handled by the standard AOV mechanism, i.e.

Display "name.exr" "exr" "rgba"
Display "+name.exr" "exr" "Cs" "string layername" "Cs" "string[3] channelnames" ["r" "g" "b"]
Display "+name.exr" "exr" "N" "string layername" "Normal" "string[3] channelnames" ["X" "Y" "Z"]

Wouldn't it at this point make sense to implement the RiDisplayChannel()
call and move the functionality there? (do other renderers actually
support renaming the channels and if so, how do they do it?)

I have to admit, I've never quite understood the value of the DisplayChannel request that PRman supports.
If someone could explain to me what it does and why it's better than what we do, I'll happily consider it.
 

Cheers


Paul

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Chris Foster-5]

On Tue, Aug 18, 2009 at 7:24 AM, Paul Gregory<pgregory@...> wrote:

> 2009/8/17 Matthias Baas <matthias.baas@...>
>>
>> How about passing just a single string and parsing that somewhere within
>> the RiDisplay() call?
>>
>>  Display "name.exr" "exr" "Cs" "string layername" "Cs" "string
>> channelnames" "r,g,b"
>
> We've settled at the moment on a single parameter, with an array of names,
> with the parameter
> ideally being specified with the correct array size, at least allowing the
> RIB parser to validate the
> data, i.e.
>
> Display "name.exr" "exr" "Cs" "string layername" "Cs" "string[3]
> channelnames" ["r" "g" "b"]

Hmm, Matthias' idea is probably easier for the user.  It has the advantages:
* The user doesn't need to provide the correct array length
* The display can check whether the list of names is long enough and provide
  sensible defaults if it's not.

>> But what if I want to put more than just 1 layer into the file? I
>> suppose I can't have the same parameter names ("layername",
>> "channelnames") twice in the same call.
>
> This is handled by the standard AOV mechanism, i.e.
>
> Display "name.exr" "exr" "rgba"
> Display "+name.exr" "exr" "Cs" "string layername" "Cs" "string[3]
> channelnames" ["r" "g" "b"]
> Display "+name.exr" "exr" "N" "string layername" "Normal" "string[3]
> channelnames" ["X" "Y" "Z"]
>
>> Wouldn't it at this point make sense to implement the RiDisplayChannel()
>> call and move the functionality there? (do other renderers actually
>> support renaming the channels and if so, how do they do it?)
>
> I have to admit, I've never quite understood the value of the DisplayChannel
> request that PRman supports.
> If someone could explain to me what it does and why it's better than what we
> do, I'll happily consider it.

Looking at the PRMan docs, it appears that RiDisplayChannel is used to define
the quantization and sampling parameters on a per-AOV basis, and allow those
AOVs to be bundled together in a single call to RiDisplay.

You're right to say that this can also be done with multiple RiDisplay calls,
but it has the disadvantage that the display has to have extra logic built in:
multiple calls to RiDisplay with the same file name should result in a single
file with multiple channels.

AFAICT, RiDisplayChannel allows this logic to be built into the renderer
itself rather than living separately in each display plugin.  It presumably
means that the display won't get multiple calls to DspyImageData for the same
region of the image...

IMHO the main disadvantage of RiDisplayChannel is that it's not exactly
standardized so maybe it's not supported by all renderers (?)

~Chris.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Matthias Baas-3]

Chris Foster wrote:

>>> Wouldn't it at this point make sense to implement the RiDisplayChannel()
>>> call and move the functionality there? (do other renderers actually
>>> support renaming the channels and if so, how do they do it?)
>> I have to admit, I've never quite understood the value of the DisplayChannel
>> request that PRman supports.
>> If someone could explain to me what it does and why it's better than what we
>> do, I'll happily consider it.
>
> Looking at the PRMan docs, it appears that RiDisplayChannel is used to define
> the quantization and sampling parameters on a per-AOV basis, and allow those
> AOVs to be bundled together in a single call to RiDisplay.

Right, quantization and sampling is done on the renderer side before the
data is sent to the display, isn't it? So I can see why they introduced
a new call instead of adding these things to the parameters of the
display call.

But the primary concern for me is just compatibility. If PRMan (or
3Delight/Air/DotC) already provides a way for doing something then I
think Aqsis should only do it differently if there's a good reason for it.
(But I actually don't know if PRMan also supports several display calls
that all refer to the same file. If it does, then you can ignore this
mail anyway as compatibility would be given in that case...)

- Matthias -


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Chris Foster-5]

On Wed, Aug 19, 2009 at 6:13 AM, Matthias Baas<matthias.baas@...> wrote:

> Chris Foster wrote:
>>>> Wouldn't it at this point make sense to implement the RiDisplayChannel()
>>>> call and move the functionality there? (do other renderers actually
>>>> support renaming the channels and if so, how do they do it?)
>>> I have to admit, I've never quite understood the value of the DisplayChannel
>>> request that PRman supports.
>>> If someone could explain to me what it does and why it's better than what we
>>> do, I'll happily consider it.
>>
>> Looking at the PRMan docs, it appears that RiDisplayChannel is used to define
>> the quantization and sampling parameters on a per-AOV basis, and allow those
>> AOVs to be bundled together in a single call to RiDisplay.
>
> Right, quantization and sampling is done on the renderer side before the
> data is sent to the display, isn't it?

Yes.

> So I can see why they introduced
> a new call instead of adding these things to the parameters of the
> display call.

Actually, the display *can* take quantization and sampling parameters, but
these can be overridden by the per-AOV values which may be specified using
RiDispalyChannel.  I think the point about DisplayChannel is that it allows you
to attach quantization and sampling parameters to each AOV *independently* but
then bundle a set of AOVs into the same Display call:

Display "bundled_aovs.tif" "file" "P,Cs" ...

> But the primary concern for me is just compatibility. If PRMan (or
> 3Delight/Air/DotC) already provides a way for doing something then I
> think Aqsis should only do it differently if there's a good reason for it.

Standardization is good of course.  The 3delight docs mention DispalyChannel,
so at least PRMan & 3delight support it; the Air docs don't appear to mention
it, and no idea about RDC.

> (But I actually don't know if PRMan also supports several display calls
> that all refer to the same file.

I don't see any reason why the renderer itself would inspect the file name for
clashes before passing to the display - that's the display's business on how to
handle such stuff.  I fully expect that the way Paul has set things up should
allow the exr display to work with other renderers (except Pixie of course
which doesn't implement the Dspy interface at all.)

~Chris

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Malcolm Humphreys-2]

 
On Tuesday, 18 August, 2009, at 03:06PM, "Chris Foster" <chris42f@...> wrote:

>On Tue, Aug 18, 2009 at 7:24 AM, Paul Gregory<pgregory@...> wrote:
>> 2009/8/17 Matthias Baas <matthias.baas@...>
>>>
>>> How about passing just a single string and parsing that somewhere within
>>> the RiDisplay() call?
>>>
>>>  Display "name.exr" "exr" "Cs" "string layername" "Cs" "string
>>> channelnames" "r,g,b"
>>
>> We've settled at the moment on a single parameter, with an array of names,
>> with the parameter
>> ideally being specified with the correct array size, at least allowing the
>> RIB parser to validate the
>> data, i.e.
>>
>> Display "name.exr" "exr" "Cs" "string layername" "Cs" "string[3]
>> channelnames" ["r" "g" "b"]
>
>Hmm, Matthias' idea is probably easier for the user.  It has the advantages:
>* The user doesn't need to provide the correct array length
>* The display can check whether the list of names is long enough and provide
>  sensible defaults if it's not.

This also lines up with how 3delight deals with the PSD display driver. (which i have never used)
--snip--
Display "output_multi_layer.psd" "psd" "amb,Ci,diff,alpha,spec"
--snip--

And the displays subsets.
--snip--
Display "layer.tif" "tiff" "rgb" "string subset" ["group1,group2"]
--snip--

.malcolm


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development