TIFF has neither named channels nor arbitrary metadata (unless you want to go
so far as to allocate custom tags).
We could devise a convention for embedding channel names in the
ImageDescription tag (as we do to store the SHA-1 hash that lets us recognize
duplicate textures), but that would be strictly an OIIO-only convention and
would be pretty brittle -- any other software would not respect it, and might
drop or mangle the information if it re-outputs the image.
-- lg
On Oct 16, 2014, at 11:17 AM, Nathan Rusch <[email protected]> wrote:
> 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
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
