Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add OCIO integration #193

Closed
jeremyselan opened this issue Nov 17, 2011 · 4 comments
Closed

Add OCIO integration #193

jeremyselan opened this issue Nov 17, 2011 · 4 comments
Assignees
Labels
enhancement Improvement of existing/working features.

Comments

@jeremyselan
Copy link
Contributor

Rough Plan...

  • Leaving the public APIs as they are (in terms of text), but merely changing the declaration of the ColorTransfer opaque type (and possibly the name) for example in convert_image.
  • Having a new utility routine that will return a ColorTransfer given two space names.
  • Auto-detect at compile time if OCIO is present. If it is, these things just wrap OCIO routines that do color conversion. If not, they should just be built to understand "linear" and "sRGB", so that at least works if no OCIO is present.
  • OK to have a more direct OCIO use in iv to display things properly. (again, falling back on something simple if not found at build time)
  • Appropriate options added to maketx and oiiotool to do named color space conversions.
@ghost ghost assigned jeremyselan Nov 17, 2011
@fpsunflower
Copy link
Contributor

Does this plan include dealing with texture lookups? Or does that come for free?

(I'm thinking of reading texture maps from plain 8 bit jpgs for example where the pixels should be "linearized" as they are read in)

@jeremyselan
Copy link
Contributor Author

This plan does not include that, but it's something we'd like to do as step 2 after the top list is done. We've been pinged on this workflow before so it's definitely good to consider. In terms of implementation, we'll want to choose whether the processing is done as the pixels are read into the tile cache, or on a per-pixel basis at query time. There would be tradeoffs for cpu vs memory vs correctness for both approaches.

@jeremyselan
Copy link
Contributor Author

I've begun a basic implementation:
https://github.com/jeremyselan/oiio/tree/ocio

You can see that the exposed public interface to the color processing doesn't expose anything about OpenColorIO, which will let us stay ABI compatible even if OCIO is not enabled at build time:

https://github.com/jeremyselan/oiio/blob/ocio/src/include/colorprocessor.h

maketx has been updated, and I've confirmed the processing works.

TODO:

  • Get error handling working, and address all TODOs in colorprocessor.h
  • Implement non-OCIO colorprocessor handling
  • Implement colorconvert in other util apps
  • Update convert_types to obey ColorProcessor (if it's appropriate to leave it in)

Eventually,

  • Update texture system to provide runtime color conversion.

@lgritz
Copy link
Collaborator

lgritz commented Nov 10, 2013

Closing, this has long since been done.

@lgritz lgritz closed this as completed Nov 10, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improvement of existing/working features.
Projects
None yet
Development

No branches or pull requests

3 participants