> The OIIO docs dont' seem to suggest a simple strategy that works well
> for all formats.
Right, because we couldn't quite agree on one.
Last time we discussed this, for reading, we were all agreed that no color
transformation should occur automatically -- the reader sets the
"oiio:ColorSpace" attribute as best as it can, but does not convert, and the
app is free to check the "oiio:ColorSpace" attribute and linearize based on
that if it wants to. (Converting between color spaces using OCIO underneath is
not hard, just look in oiiotool.cpp for the action_colorconvert function to
see how it's done -- though note that we only support color conversion on float
buffers.)
Where we couldn't quite agree is what should happen upon writing. There are
several moving parts: Some file formats dictate one particular color space;
others give you a choice or let you specify it; some are blissfully unaware of
the issue. Is it safe for OIIO to assume that the app will always pass it
linear data? This contradicts what most users/apps will expect when passing 8
bit buffers around. What about something simple, like 'iconvert' which would
really like to just do a straightforward read into a buffer, then write out the
same buffer again. That should probably not change color space without it
intending to happen.
Now, what we have is admittedly not optimal either. We haven't exposed all the
color conversion tools to make it as simple as it should be. And the "write"
issue is unsatisfying.
I'm very much willing to re-open the discussion.
I don't remember all the details from the last time Jeremy and I discussed
this, but IIRC, one proposal I had was along these lines:
* Readers do not auto-converst; just set the attribute giving the color space
name and leave conversion it up to the app.
* Expose a simple one-call "linearize" utility.
* Writers assume the "oiio:ColorSpace" of the spec passed to open() describes
the color space of the data in the buffers that will be passed. For an output
format that requires a specific color space (like JPEG must be sRGB), if the
spec does not match it, the writer is expected to do the conversion.
* oiiotool should probably have an option to linearize all its inputs.
I'm not sure about an of this. Opinions desired.
-- lg
On Jan 30, 2013, at 8:33 PM, Miles Bader wrote:
> Given that my internal format is linear light, I'd like to just ignore
> gamma issues, and was hoping a generic image library like OIIO would
> handle everything behind my back.
>
> I was vaguely assuming that if I used floating-point values with
> {read,write}_scanline, that they would represent linear values (in the
> appropriate color space, e.g. for jpeg, it would be sRGB without gamma
> correction).
>
> However after some experimentation, it seems this isn't the case, and
> I suppose that makes some sense for consistency reasons -- UINT8
> values really need to be gamma corrected, and it might be confusing if
> {read,write}_scanline used a different interpretation for FLOAT
> values.
>
> So I guess I need to do gamma correction myself. [Ok, not so hard, I
> do that already when not using OIIO.]
>
> But as I obviously want to keep things as generic as possible, and
> avoid special handling of specific image types, how should I find the
> gamma value to use for gamma correction? I certainly want to use
> gamma correction for most 8-bit formats, because not doing so (even
> when the format makes it possible) often results in worse image
> quality.
>
> The OIIO docs dont' seem to suggest a simple strategy that works well
> for all formats.
>
> Idea:
>
> 1) Set the "oiio:ColorSpace" attribute to "Linear".
>
> This seems simple to use, and it sounds like it will work OK for
> formats like JPEG with a fixed gamma correction, because OIIO
> will then do the proper gamma correction itself.
>
> But it also appears that it will do the wrong thing for formats
> like PNG which have a user-definable gamma correction, but are
> still only 8-bit formats -- then I'll get quality impacts from
> using linear values.
>
> 2) Retrieve the format's gamma correction value by getting the
> "oiio:Gamma" attribute and doing the gamma correction myself.
>
> Not too difficult, but if I'm interpreting the docs correctly,
> this attribute is only valid when oiio:ColorSpace is
> "GammaCorrected."
>
> Thus it seems I'd have to look at oiio:ColorSpace and do specific
> handling for every value of that. However, maybe it's necessary
> to do this anyway, for color-space conversion correctly.
>
> In practice, it looks like I could get it "mostly" right by
> doing something like
> "if (oiio:ColorSpace == "Linear") gamma = 1; else gamma = 2.2;"
> ... ><
>
> Any suggestions for how one is _supposed_ to do this stuff?
>
> Thanks,
>
> -Miles
>
> --
> 「寒いね」と話しかければ「寒いね」と答える人のいるあったかさ [俵万智]
>
> _______________________________________________
> 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
