Color-Picker preview does not consider the current View Transform selected #124544

New Issue

Liam Collod · 2024-07-11T18:15:53+02:00

Liam Collod commented

2024-07-11 18:15:53 +02:00

Hello,
I am reporting what seems to be a bug or more like a missing implementation.

topics: graphical-interface, color-management, color-picker, OCIO

observation

When using the Color-Picker we can notice that the GUI preview is not updated when we change the active View Transform being applied. Actually, the color-picker seems hardcoded to use the first View (OCIO term) defined in the config for the active Display.
On the positive side, we can notice that changing the active Display in the GUI does update the color-picker GUI preview accordingly.

steps to reproduce

Here is a recording showcasing the issue, first part showcases the change of Display works as expected but then the change of View-Transform does not.

recorded on Blender 4.1.1, branch: blender-v4.1-release, platform: 'Windows-10-10.0.19045-SP0' with native color config

indentification

I tried to browse the code to confirm the observation which led me to:

		source/blender/imbuf/intern/colormanagement.cc
		Line 990 in 6e683e26cc
	
				      const char *view_name = colormanage_view_get_default_name(display);

If I correctly understand the code it seems we are only tracking the active Display which is being provided as a parameter, however for the view we rely on colormanage_view_get_default_name :

		source/blender/imbuf/intern/colormanagement.cc
		Line 3097 in 6e683e26cc
	
				  const char *name = OCIO_configGetDefaultView(config, display->name);

which basically relies on the native OCIO function OCIO_configGetDefaultView:

https://opencolorio.org/old/developers/api/OpenColorIO.html#Config::getDefaultView__cCPC
(sharing the legacy doc because Git Blame indicate the line hasn't moved in 12 years)

conclusion

By not using the View-Transform in the generation of the color-picker GUI we rely on OCIO native behaviour of providing us a default View, happening to just be the first View defined for a given Display in the current OCIO config.

This behaviour forces OCIO config authors to make sure they sort their View according to which one they want it to be used for Blender color-picker but also means that artist will never get the actual preview of their picked color once it has gone through the View Transform and just rely upon whatever the config author have defined (or not).

I also want to point out that the same issue can be found for Looks, where changing the active Look will not impact the color-picker. However, also applying the active Look in the color-picker might be a more subjective decision than the View.

This is the first time I am reporting what seems to me like a bug so please let me know if this is not the appropriate platform of if anything is missing.
Best,
Liam.

Hello, I am reporting what seems to be a bug or more like a missing implementation. topics: graphical-interface, color-management, color-picker, OCIO # observation When using the Color-Picker we can notice that the GUI preview is not updated when we change the active `View Transform` being applied. Actually, the color-picker seems hardcoded to use the first `View` (OCIO term) defined in the config for the active `Display`. On the positive side, we can notice that changing the active `Display` in the GUI does update the color-picker GUI preview accordingly. ## steps to reproduce Here is a recording showcasing the issue, first part showcases the change of `Display` works as expected but then the change of `View-Transform` does not. > recorded on Blender 4.1.1, branch: blender-v4.1-release, platform: 'Windows-10-10.0.19045-SP0' with native color config <video src="/attachments/5ec6ffd6-0d95-4bbd-9611-4ac8e10483f9" title="2024_07_11_173601_x.mp4" controls></video> # indentification I tried to browse the code to confirm the observation which led me to: https://projects.blender.org/blender/blender/src/commit/6e683e26ccb671d80d25f3ca1fc1d78177901dd3/source/blender/imbuf/intern/colormanagement.cc#L990 If I correctly understand the code it seems we are only tracking the active `Display` which is being provided as a parameter, however for the view we rely on `colormanage_view_get_default_name` : https://projects.blender.org/blender/blender/src/commit/6e683e26ccb671d80d25f3ca1fc1d78177901dd3/source/blender/imbuf/intern/colormanagement.cc#L3097 which basically relies on the native OCIO function `OCIO_configGetDefaultView`: > https://opencolorio.org/old/developers/api/OpenColorIO.html#Config::getDefaultView__cCPC > (sharing the legacy doc because Git Blame indicate the line hasn't moved in 12 years) # conclusion By not using the View-Transform in the generation of the color-picker GUI we rely on OCIO native behaviour of providing us a default `View`, happening to just be the first `View` defined for a given `Display` in the current OCIO config. This behaviour forces OCIO config authors to make sure they sort their View according to which one they want it to be used for Blender color-picker but also means that artist will never get the actual preview of their picked color once it has gone through the `View Transform` and just rely upon whatever the config author have defined (or not). I also want to point out that the same issue can be found for `Looks`, where changing the active `Look` will not impact the color-picker. However, also applying the active `Look` in the color-picker might be a more subjective decision than the `View`. --- This is the first time I am reporting what seems to me like a bug so please let me know if this is not the appropriate platform of if anything is missing. Best, Liam.

2024_07_11_173601_x.mp4

214 KiB

Liam Collod added the

labels 2024-07-11 18:15:54 +02:00

Iliya Katushenock added the