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

Comments

Projects
None yet
3 participants
@jeremyselan
Contributor

jeremyselan commented Nov 17, 2011

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

This comment has been minimized.

Show comment
Hide comment
@fpsunflower

fpsunflower Nov 17, 2011

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)

Contributor

fpsunflower commented Nov 17, 2011

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

This comment has been minimized.

Show comment
Hide comment
@jeremyselan

jeremyselan Nov 17, 2011

Contributor

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.

Contributor

jeremyselan commented Nov 17, 2011

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

This comment has been minimized.

Show comment
Hide comment
@jeremyselan

jeremyselan Dec 3, 2011

Contributor

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.
Contributor

jeremyselan commented Dec 3, 2011

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

This comment has been minimized.

Show comment
Hide comment
@lgritz

lgritz Nov 10, 2013

Contributor

Closing, this has long since been done.

Contributor

lgritz commented Nov 10, 2013

Closing, this has long since been done.

@lgritz lgritz closed this Nov 10, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment