Wow, so this just sounds like a case of me not being aware of this particular
limitation of TIFF. Given its general flexibility as a format, I just assumed
it could support named channels, and I'm quite surprised that isn't the case.
I guess the expectation must be that, because the format is so malleable, you
would just implement your own method of storing and reading some custom mapping
between channel names and positions in the file if you wanted it badly enough.
Thanks for setting me straight!
-Nathan
From: Larry Gritz
Sent: Wednesday, October 15, 2014 10:54 PM
To: OpenImageIO developers
Subject: Re: [Oiio-dev] Cusotm channel names not working with make_texture
Sorry for the delay, Nathan. I've been deep in some interesting projects and
haven't been as prompt with keeping up with the email onslaught in the last
month.
OK, here's what I tried:
$ oiiotool --create 256x256 6 -d half --chnames R,G,B,A,Z,mask -o test.exr
$ iinfo -v test.exr
test.exr : 256 x 256, 6 channel, half openexr
channel list: R, G, B, A, Z, mask
...
Ok, so we can definitely write exr files with arbitrarily named channels. Let's
turn it into a texture:
$ maketx test.exr -o texture.exr
$ iinfo -v texture.exr
texture.exr : 256 x 256, 6 channel, half openexr
MIP-map levels: 256x256 128x128 64x64 32x32 16x16 8x8 4x4 2x2 1x1
channel list: R, G, B, A, Z, mask
...
Yep, maketx preserves the channel names when creating an OpenEXR texture.
But wait, I have a hypothesis. Let's not name it ".exr", and not use the
--format argument, thereby writing a TIFF-based texture by default:
$ maketx test.exr -o test.tx
$ iinfo -v test.tx
test.tx : 256 x 256, 6 channel, float tiff
MIP-map levels: 256x256 128x128 64x64 32x32 16x16 8x8 4x4 2x2 1x1
channel list: R, G, B, A, channel4, channel5
...
That's what you're talking about, right?
It comes down to this: (1) you created a TIFF texture, and (2) the TIFF format
does not support channel names. Channel names mentioned nowhere in the TIFF
spec, there's not a recognized place in the file to store this data. When OIIO
reads a TIFF file, it automatically fills in the ImageSpec channel names as R,
G, B, A, then channelN. That's just the best guess it can make.
If you want to preserve true arbitrary channel names throughout a sequence of
image operations (including turning it into a texture), you must use an image
file format that supports channel names.
To precisely answer your question, it is choice E) something else -- to wit, a
limitation of the TIFF format itself.
It also may be D/E) bug/something else -- you intended to write an EXR texture,
but were inadvertently writing TIFF.
On Oct 2, 2014, at 3:01 PM, Nathan Rusch <[email protected]> wrote:
Hey all,
I'm trying to set custom channel names when creating a .tx file, but it seems
that I'm particular feature either may not work correctly, or that I'm
overlooking something. This is using OIIO 1.5.0.
The first thing I tried was setting the "maketx:channelnames" attribute on my
output ImageSpec to a comma-separated string (e.g. "R,G,B,A,Z,mask")., but when
I inspect the file using iinfo, it lists the channels as "R, G, B, A, channel4,
channel5".
I also tried manually populating the `.channelnames` vector on the
destination ImageSpec, as well as the `spec.alpha_channel` and `spec.z_channel`
indices, but this didn't seem to work either.
Lastly, since my code is passing a filled ImageBuf to
ImageBufAlgo::make_texture, I tried the manual population process again, except
on the ImageSpec that is passed to the constructor of the ImageBuf I'm
populating to be written (since it looked like make_texture_impl could
potentially allow the source ImageBuf to be written directly).
Then, just to sanity-check myself, I wrote out an EXR with the channels I
wanted, and then converted it to a .tx file using `maketx --oiio --channelnames
"R,G,B,A,Z,mask" /path/to/file.exr`, but iinfo still showed the last two
channels as being named "channel4" and "channel5". I also wrote some code to
read the same image back in and print out the contents of its channel names as
seen by OIIO (to sanity-check iinfo), with the same results.
My question is, is this A) a limitation of libtiff, B) a limitation of the
OIIO tiffoutput plugin, C) an OIIO feature that hasn't been hooked up yet, D) a
bug, or E) something else?
Thanks for any help.
-Nathan
_______________________________________________
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
