5
$\begingroup$

I am aware that there are other posts about color management, but bear with me. I have a wide-gamut monitor and HW calibrators (Spyder 3 and i1 Pro) with custom profiles, meaning without the SW knowing it is displaying in wide-gamut and even a bit adjusted colors, the displayed colors are waaay off. I already made a monitor profile and put it into the Blender color management pipeline ( How can Blender be augmented to display color critical and accurate results? ). I now have concatenated Filmic + sRGB-> monitor profile. However working with colors just improved from unusable to barely acceptable, there are still a lot of issues, that I need help to solve.

Main issues currently bothering me:

  1. The final render is displayed in my monitor's color profile, which is nice. However, after saving the file is in this profile as well, i.e. I have to process it in another step... something like open Photoshop, assign my monitor profile, convert to sRGB and save. I guess the current workaround is to set "Filmic-only" profile before saving and then switch it back again, which is an annyonce and error-prone (could be done by script though). Is there another way that I missed?

  2. Compositor: If I load a file, which should be on top of the render (model on a green-screen, logo, anything, ...) it is processed by the same color transformation as the render: Filmic + sRGB -> monitor's profile. The latter part is ok I guess, but Filmic should not be applied here. How to turn it off for images imported in compositor?

Ideally it seems to me that there should be separate monitor profile that is applied on top of everyting (render image, color pickers, compositor) without other parts of Blender even knowing that.

Also I now wish there was a color conversion node in Compositor that would allow conversion from/to various color spaces. Just an option to load a manually-prepared LUT would be enough. This would solve a lot of issues for me.

Am I getting something wrong and there is an straightforward way to fix theses issues? Thanks!

Improve this question
$\endgroup$
4
  • $\begingroup$ I don't think solutions to the 2 problems currently exist in Blender. "meaning without the SW knowing it is displaying in wide-gamut and even a bit adjusted colors, the displayed colors are waaay off. " What do you mean by this? What color space is it displaying? How specifically are the colors "a bit adjusted" and to what? How do you know they are "waaay off"? If color is somehow managed in the hardware of the monitor it is very important to understand how. Keep in mind Troy's answer "relies on a wide gamut display being set to sRGB emulation mode for the sake of clarity.". $\endgroup$
    – Martynas Žiemys
    Commented Jul 26, 2020 at 9:35
  • $\begingroup$ @MartynasŽiemys: Sorry, I was too vague in this part. I mean my monitor is close to AdobeRGB, so if any software expects sRGB and outputs image as such, it is very different compared to the expected (it is visibly much more saturated). In addition my monitor has not an exact AdobeRGB spectrum, so even outputting colors using a generic AdobeRGB profile is not enough, since the colors are adjusted even more by the custom profile. (There is no hardware managment for the colors, sorry to mislead.) $\endgroup$
    – Vit Kovalcik
    Commented Jul 26, 2020 at 12:44
  • $\begingroup$ maybe @troy_s can help here? $\endgroup$
    – susu
    Commented Jul 26, 2020 at 15:57
  • $\begingroup$ I think I found the task that mentions these improvements should be made in Blender. More specifically Render file output and file saving needs to have a configurable color space to write to. and The compositor should get a compositor node to convert between two color spaces defined in the OpenColorIO configuration. amongst others. See this: developer.blender.org/T68926 I guess we can award a token there to attract more attention. $\endgroup$
    – Vit Kovalcik
    Commented Jul 27, 2020 at 10:42

2 Answers 2

Reset to default
5
$\begingroup$

Main issues currently bothering me:

There are quite a few issues, and thankfully more folks are learning them.

The final render is displayed in my monitor's color profile, which is nice. However, after saving the file is in this profile as well, i.e. I have to process it in another step...

This is because Blender has a horrific file encoding chain. The default is to bake in the Display / View / Look transform, which means that if you have any colourimetric twists in your displays, that will end up encoded into the code values.

Hack Solution:

  1. For canonical sRGB encoding to nonlinear display referred outputs, prior to saving to a display referred output such as JPEG or TIFF, change the Display / View / Look combination to the same combination with sRGB chosen as display.
  2. For EXR encoding, the native buffer will be encoded, so the results skip all management altogether.

Proper Solution:

  1. Pressure the development to implement an encoding panel. This would be something akin to a selection box with a stack of elements similar to a texture, that would have sane defaults and allow the audience to encode a specific chain of transforms into their output imagery.

Compositor: If I load a file, which should be on top of the render (model on a green-screen, logo, anything, ...) it is processed by the same color transformation as the render: Filmic + sRGB -> monitor's profile. The latter part is ok I guess, but Filmic should not be applied here. How to turn it off for images imported in compositor?

When you load an image, you must describe the encoding to Blender. Sadly, this is hidden away behind a bunch of obfuscating menu elements. One method is to open up the Image Viewer, open the sidebar properties panel on the right, and select the encoding that describes the encoding of the footage or shot.

This will cascade into another problem because, again, generic imagery does not work in a radiometric-like compositing environment. There's nothing short of hackery and quackery that can be done to try and get a generic sRGB image into the radiometric domain, as he data is not there.

Hack Solution:

  1. Set the sRGB image to be Filmic encoded. This will artificially "stretch" the range to become a no-operation after the output chain.

More Proper Solution:

  1. Use properly encoded imagery! Camera raws, log encodings with documented transforms, etc. can all be coaxed to do things more correctly. For all work generated from within Blender, never ever use any other file encoding other than EXR. Start with EXR. Stay there. Never leave. Only after completely finished, deliver to the delivery encodings.

It's a deeper subject than this, but hopefully there's enough here to get you moving in the right direction.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Thank you very much! I now see several ways to do what I needed. Maybe a follow-up question: What would be the best way to "pressure the development" of a certain feature? $\endgroup$
    – Vit Kovalcik
    Commented Jul 30, 2020 at 6:32
  • 1
    $\begingroup$ Complex question. It would seem reasonable that a first baby step is to have the audience acutely aware of the issue, how it impacts work, etc. The more people who understand the core issues, and how it cascades into file encoding, the better. Good luck with your work! Hopefully it gets one step closer to the creative goal! $\endgroup$
    – troy_s
    Commented Jul 30, 2020 at 15:10
2
$\begingroup$

If case anyone is wondering what I ended up doing (and for the future me): I used the @troy_s answer and there were a few tricks I needed to do.

I added current Filmic from here [ https://github.com/sobotka/filmic-blender ], added a new display alongside sRGB and Adobe P3, so it will include my monitor profile.

The new display is similar to Adobe P3, but instead of the transformations to P3 space it transforms to my monitor space using SPI3D LUT from file.

I can then quickly switch to my monitor calibration (for viewing) to sRGB (for saving into PNG). Saving to OpenEXR or MultiLayerEXR works without switching, but for example Sheep It render farm doesn't support EXR, so there are drawbacks.

For the images imported to compositor, which currently have to be in sRGB (sorry, linear space is out of question currently): I tried to use Filmic Log as input color space. The render color space have to be Filmic Log with "None" look as well and some simple grading can be done in compositor instead using Color Balance node with ASC-CDL settings. This grading is only performed on the rendered image, not on the imported image. This however isn't visible in viewport render.

So instead I used Filmic with the "Base contrast" look for render and created a new very specific colorspace which has these transformations baked in ("My Filmic with Base contrast color space"). This colorspace is assigned to the imported image in compositor and all seems to be working. The image is composed with the render without changes and then is converted into my monitor's color space.

Very ugly, but works for now.

Improve this answer
$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .