The other thing that was bugging me last week was the way that, if oiiotool was given an EXR and told to write out a DPX, it would write out an invalid 32-bit float DPX.
As such, I've added support for each of the ImageOutput classes to be able to specify which data formats they support, plus what they would consider their default image format. This is all in the pull request linked to Issue #180 There are two new functions in each ImageOutput class: * bool supports_data_format(string format) * string get_default_data_format() In these, I am dealing with the data format as a string rather than a TypeDesc enum. This is because of data formats like uint10 and uint12, which are actually classified as TypeDesc::UINT16, but with an attribute of oiio:BitsPerSample set. Currently, oiiotool is the only thing that actually deals with these new function. It uses the following logic: * If -d <format> is an argument, check if this data format is supported. If not, print an error and exit * Check if the input data format is supported by the image output class. --> If it is supported, keep the same data type --> If it is not supported, ask the image output class for its default data format, and use that This allows for things like: $ oiiotool foo.exr -o bar.dpx Which will actually write 10-bit DPX files, rather than the 32-bit float DPXs. I've done my best to ensure that each ImageOutput subclass actually defines the correct data formats (doing this was where I came across the typos in icooutput.cpp and tgaoutput.cpp), but please do double check this for me. Also, I wasn't sure what would be considered the default data type for some formats. I guessed for a few. Please do confirm this. Thanks Hugh Macdonald nvizible – VISUAL EFFECTS [email protected] +44(0) 20 3167 3860 +44(0) 7773 764 708 www.nvizible.com
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
