Hi,
I'm coming back on the topic of custom channels. My last remark
regarding the bad ordering of channels in the file triggers another one
as there is an issue when using the Texture evaluation system, which is
limited. Maybe it's not meant to be used as I do, but it lacks
modularity as far as i'm concerned.
The evaluation function available takes a channel index, and a channel
count. Which, in most cases is enough, but there's a catch: when
channels are not stored in the correct order (as I mentionned in my last
email on the subject), or when we want to evaluate channels that are not
adjacent, we cannot use the function. The only way to get a good result
is to call n times the function, to evaluate each channel once at a
time, which, as we can imagine, is much slower.
I did a bit of digging and had a look at how the texture system is
implemented, and it triggered more questions.
The first one is that it seems that data is always stored interlaced (i
mean rgbargba). Does that mean that all channels are loaded even if we
don't use them ?
If that's the case, would it be possible to modify the "accum*"
functions to read non contiguous pixels ? Instead a giving a first
channel and a count, we would give an array of indexes and a count.
For example in "accum_sample_bilinear", texel[0][0] would be initialized
using
texel[0][0] = tile->bytedata() + offset ;
instead of
texel[0][0] = tile->bytedata() + offset + channelsize *
options.firstchannel;
and later in the function, we would not access pixel through:
for (c = 0; c < nc; ++c)
[...] texel[0][1][c] [...]
but using something like
for (c = 0; c < nc; ++c)
[...] texel[0][1][requested_channel[c]] [...]
Having quite a superficial knowledge of the library, I don't not feel
brave/confident enough to modify the code right away, that's why I'm
looking for advice/opinion from people knowing the part of the lib.
Thanks.
Michel
PS: to give you an idea on why I need to do that, here's the whole picture:
Like Nuke does, we want to be able to write and read arbitrary output
channels to files. We can write/read dozen of channels to/from a file,
which are included in layers/groups.
1 - If a group includes "r, depth.z, blinn.g", we'd like to be able to
evaluate the three channels with a single function call.
2 - with the channel order bug, channels that are adjacent in memory can
be shuffled in the file, which breaks the evaluation. Even reading the
basic r, g, b, a channels can go wrong.
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
