Found this old email that I think I never replied to.

You probably already figured this out long ago, but just in case (or maybe so 
somebody else reading can learn):

If you want to write a file with differing per-channel data types, then after 
creating the ImageOutput (but before opening it), you're supposed to call 
out->supports("channelformats") and if it returns false, that file format does 
not support writing per-channel formats, and so you should not open it with an 
ImageSpec that has channelformats filled in. (That said, if it's filled in, and 
all the channelformats are the same as spec.format, you might expect that to 
work, and it doesn't; I will fix that.)

Technically, the TIFF spec does allow for TIFF files with per-channel formats. 
But libtiff (which we use, and pretty much everybody else) doesn't support that 
feature. A feature that libtiff doesn't support should not be used, since even 
if we rolled out own writer and produced these files, almost nothing else would 
read them properly, since libtiff is ubiquitous.

        -- lg


> On Oct 23, 2014, at 12:04 AM, Michel Lerenard <[email protected]> 
> wrote:
> 
> Hi,
> 
> I've noticed that I get a crash when calling write_scanlines on a TIFF file 
> if the spec.channelformat array has been filled before. (whatever data is 
> inside. I could leave the array uninitialised, or write the same value i 
> write in spec.format, it crashes)
> I have issue when writing OpenExr files, the format I specify are correctly 
> applied.
> 
> I was hoping that even if Tiff does not support per channel format, it would 
> simply ignore the channelformat array, and use the "main" format of the 
> header.
> Is it a bug, or have I done something wrong ? Should I fill the array only 
> when using openexr ?
> 
> Thanks
> 
> Michel

--
Larry Gritz
[email protected]




_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Reply via email to