hey how,
I recently moved over to the ACES workflow. I noticed that the Color Editor also changed in tearms of the appereance. The Colors are looking different (in the Editor)then before moving to the ocio pipline. Why is this so? are there any quidelines to folow when working with exaxt color values? What i am going to do when i get a specifc colorvalue from the artdirector for example? can anybody help me out with additional infos?
cheers
Fred
ACES/OCIO
3639 4 2- Fred Eric
- Member
- 50 posts
- Joined: Sept. 2019
- Offline
- malbrecht
- Member
- 806 posts
- Joined: Oct. 2016
- Offline
Hi,
> when working with exaxt color values?
… “exact color values” and “Aces” don't fit into one context in my world :-) (tongue in cheek). ACES, like all other attempts to agree on something, is a “forced definition”, not something exact. Besides, due to some obscure “640kB will be enough for everyone” philosophy, ACES uses 16bit floating point, limiting (necessary) headroom for floating point rounding errors.
That ranted, a well defined color workflow depends on every device being set up properly: From your monitor's calibration and a matching profile for your display pipeline (your Operating System may apply its own “correction”, so may do your graphic card driver) through your tool (Houdini) to your input data (do you need a “de-gamma” to be applied to get into anything linear?). Without knowing your precise workflow it's hard to tell why exactly you are seeing different colors when turning ONE switch in the whole process.
Marc
> when working with exaxt color values?
… “exact color values” and “Aces” don't fit into one context in my world :-) (tongue in cheek). ACES, like all other attempts to agree on something, is a “forced definition”, not something exact. Besides, due to some obscure “640kB will be enough for everyone” philosophy, ACES uses 16bit floating point, limiting (necessary) headroom for floating point rounding errors.
That ranted, a well defined color workflow depends on every device being set up properly: From your monitor's calibration and a matching profile for your display pipeline (your Operating System may apply its own “correction”, so may do your graphic card driver) through your tool (Houdini) to your input data (do you need a “de-gamma” to be applied to get into anything linear?). Without knowing your precise workflow it's hard to tell why exactly you are seeing different colors when turning ONE switch in the whole process.
Marc
---
Out of here. Being called a dick after having supported Houdini users for years is over my paygrade.
I will work for money, but NOT for "you have to provide people with free products" Indie-artists.
Good bye.
https://www.marc-albrecht.de [www.marc-albrecht.de]
Out of here. Being called a dick after having supported Houdini users for years is over my paygrade.
I will work for money, but NOT for "you have to provide people with free products" Indie-artists.
Good bye.
https://www.marc-albrecht.de [www.marc-albrecht.de]
- toadstorm
- Member
- 385 posts
- Joined: April 2017
- Offline
If you're in a situation where the art director says “this thing has to be exactly this shade of magenta!” then you're in for a treat. There's two approaches: the simple hacky way is to fix it in post. Handle your whole color workflow using ACES like you normally would, and then at the end of your comp after you've used OCIO to transform everything into your delivery colorspace (probably sRGB), apply your brand colors / color corrections.
The second approach would be to apply the inverse of your usual color transform to the target color. It's a bit like how you'd apply an inverse gamma curve to an sRGB texture (1/2.2 = 0.4545) in order to linearize a texture for normal rendering. The exact operation here depends on what your input and output spaces are, but generally what you want to do is take your source swatch or texture and convert it FROM your output space (Output - sRGB probably) TO your working space (ACES - ACEScg). This will ensure that what you see is what you get. It does come with the possibility of giving you some very weird color values, though, and this could affect your lighting solution (especially if you're trying to match a very bright color).
The second approach would be to apply the inverse of your usual color transform to the target color. It's a bit like how you'd apply an inverse gamma curve to an sRGB texture (1/2.2 = 0.4545) in order to linearize a texture for normal rendering. The exact operation here depends on what your input and output spaces are, but generally what you want to do is take your source swatch or texture and convert it FROM your output space (Output - sRGB probably) TO your working space (ACES - ACEScg). This will ensure that what you see is what you get. It does come with the possibility of giving you some very weird color values, though, and this could affect your lighting solution (especially if you're trying to match a very bright color).
MOPs (Motion Operators for Houdini): http://www.motionoperators.com [www.motionoperators.com]
- Fred Eric
- Member
- 50 posts
- Joined: Sept. 2019
- Offline
malbrecht
Hi,
> when working with exaxt color values?
… “exact color values” and “Aces” don't fit into one context in my world :-) (tongue in cheek). ACES, like all other attempts to agree on something, is a “forced definition”, not something exact. Besides, due to some obscure “640kB will be enough for everyone” philosophy, ACES uses 16bit floating point, limiting (necessary) headroom for floating point rounding errors.
That ranted, a well defined color workflow depends on every device being set up properly: From your monitor's calibration and a matching profile for your display pipeline (your Operating System may apply its own “correction”, so may do your graphic card driver) through your tool (Houdini) to your input data (do you need a “de-gamma” to be applied to get into anything linear?). Without knowing your precise workflow it's hard to tell why exactly you are seeing different colors when turning ONE switch in the whole process.
Marc
thx for your reply Marc, i just noticed that the color editor looks different then before but your right. I have to digg deeper into the technical aspects from colorspaces etc.
- Fred Eric
- Member
- 50 posts
- Joined: Sept. 2019
- Offline
toadstorm
If you're in a situation where the art director says “this thing has to be exactly this shade of magenta!” then you're in for a treat. There's two approaches: the simple hacky way is to fix it in post. Handle your whole color workflow using ACES like you normally would, and then at the end of your comp after you've used OCIO to transform everything into your delivery colorspace (probably sRGB), apply your brand colors / color corrections.
The second approach would be to apply the inverse of your usual color transform to the target color. It's a bit like how you'd apply an inverse gamma curve to an sRGB texture (1/2.2 = 0.4545) in order to linearize a texture for normal rendering. The exact operation here depends on what your input and output spaces are, but generally what you want to do is take your source swatch or texture and convert it FROM your output space (Output - sRGB probably) TO your working space (ACES - ACEScg). This will ensure that what you see is what you get. It does come with the possibility of giving you some very weird color values, though, and this could affect your lighting solution (especially if you're trying to match a very bright color).
Thanks for this super helpful information. I am going to try the second approach. Lets see how this will work out for me. I also read your guide in this context. awesome
-
- Quick Links