Date
1 - 9 of 9
parseColorSpaceFromString() issue
|
Michael Root <mi...@...>
May I suggest making parseColorSpaceFromString() optionally a little more strict? The basic problem is that as we're transitioning to using OCIO, there are still many situations where a file might have an OCIO colorspace in the filename....but it may also not have one. Even if strictparsing is true, the 'strictness' is still pretty lax. Any part of the filename that happens to line up with a colorspace suddenly becomes the colorspace. For example, parseColorSpaceFromString() returns: "dialogSync1020.0100.dpx" => "nc10" "brickKilnFront.jpg" => "lnf" "digiDoubleForeign1029.0100.dpx" => "gn10" May I suggest a config option like: delimiters: _./ Which would restrict the parser to only consider substrings delimited on both sides by one of those chars (or the beginning or end of the string). By default, delimiters is an empty string, which results in the current behavior. Attached is a patch against 1.0.9 that implements this idea. -miker |
|
|
|
Larry Gritz <l...@...>
+1 on the suggestion of recognizing OCIO color spaces in the filenames only if they are fully delimited.
This is an especially egregious failure, considering that JPEG files are by specification LDR and sRGB (so very not "lnf"). On Oct 1, 2014, at 12:46 PM, Michael Root <mi...@...> wrote: May I suggest making parseColorSpaceFromString() optionally a little more strict?
--
Larry Gritz l...@... |
|
|
|
Sean Looper <sean....@...>
I've been bitten by this as well. Ended up writing my own parsing function. On Wed, Oct 1, 2014 at 1:43 PM, Larry Gritz <l...@...> wrote:
|
|
|
|
Mark Boorer <mark...@...>
Hi, > May I suggest making parseColorSpaceFromString() optionally a little more strict? I'm certainly happy to add in this functionality if it makes your lives easier. > This is an especially egregious failure, considering that JPEG files are by specification LDR and sRGB (so very not "lnf"). As a quick aside, do many people use this functionality? I was under the impression that this was mostly an SPI thing (baking the colorspaces in to the filenames). Personally we use metadata / heuristics to determine which colorspaces our images are in. (eg, JPG files are sRGB, DPX's are in the camera's log space). If you feel like knocking up a pull request containing your patch, I'll merge it (assuming it's all good). Otherwise I'm happy to do so on your behalf. Cheers, Mark On Wed, Oct 1, 2014 at 9:49 PM, Sean Looper <sean....@...> wrote:
|
|
|
|
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...@... |
|
|
|
mike...@...
On Wednesday, October 1, 2014 2:23:56 PM UTC-7, Mark Boorer wrote:
Thanks Mark. If you wouldn't mind handling the pull request, that'd be helpful. I'm afraid I'm still not fully up to speed on git. -miker |
|
|
|
Sam Richards <sam.ri...@...>
I'm going through this right now, and have the horrible problem of trying to educate people to add the right color space to their filename, knowing full well that there is a strong likelyhood that initially things will only get worse, where they are writing files out as linear, but calling them log. Is it a horrible idea to use the ICC profile name that is in the file-header (assuming we could ever get that right?) to do the mapping? I'm sure the adobe products are at least trying to write that out correctly (its a shame Nuke isnt). Sam. On Thu, Oct 2, 2014 at 10:16 AM, <mike...@...> wrote:
|
|
|
|
Sean Looper <sean....@...>
I don't think so. I used to use the "colorspace" attribute stored on assets at my *previous* job to determine color space and only fall back to the file name if that didn't exist. Naming conventions are fragile things, as we know. On Fri, Oct 3, 2014 at 6:13 PM, Sam Richards <sam.ri...@...> wrote:
|
|
|
|
mi...@...
I needed to get git-savvy anyway, so I went ahead and made a pull request for this patch: https://github.com/imageworks/OpenColorIO/pull/381 Cheers, -Mike On Thursday, October 2, 2014 10:16:05 AM UTC-7, mik...@... wrote:
|
|
|