Re: parseColorSpaceFromString() issue
|
Larry Gritz <l...@...>
It's complicated. Metadata, file naming conventions, and color space dictates/restrictions in the specification of particular file formats may all be mutually contradictory. What do you do? What is the decision hierarchy?
Personally, I would prefer that filenames be arbitrary and that metadata be used to indicate colorspace. (Notwithstanding hard color space constraints of particular formats.) Jeremy and I have discussed this many times before, and (if I may put words in his mouth) he believed strongly that metadata was so frequently wrong as to be useless (image apps may not set, drop, or incorrectly set the color space metadata). It's true that the convention at SPI is to bake the color space name into the file name, and ignore everything else. This is, IMHO, largely a historical response to file formats that did not support any way to specify color space information, and a hodgepodge of image-handling applications and libraries that might botch it or simply not propagate the color space info from input to output (and more often than not, were almost completely ignorant of metadata). Perhaps with EXR gaining dominance (arbitrary metadata, yay) and OIIO being the basis of a growing majority of our image-handling software (a lot of attention to reading and propagating the metadata), relying on metadata for color space hints is more achievable than it once was. But there are still a lot of edge cases to struggle with. Jeremy and I had, at some point, discussed the possibility of a coordinated attack involving a function (in one or both of our packages) that might take as parameters the filename, format name, and metadata (if any), and given all this information would return the best guess of color space, with some set of (documented) sensible rules to adjudicate any conflicts. It's even possible that the rules could be part of an OCIO configuration (i.e., a way to say "at studio TLA, filenames take precedence over metadata, here's the regex that isolates the color space name, but override that by knowing that '.blah' files are always color space 'foo'"). But we never quite got around to fully fleshing it out. -- lg On Oct 1, 2014, at 2:23 PM, Mark Boorer <mark...@...> wrote:
--
Larry Gritz l...@...
|
|
|