Color picker colors drift value for some OCIO configurations #101000
Open
opened 2022-09-12 12:02:16 +02:00 by Zijun Zhou
·
42 comments
No Branch/Tag Specified
main
blender-v3.3-release
blender-v3.6-release
asset-browser-frontend-split
universal-scene-description
temp-sculpt-dyntopo
brush-assets-project
asset-shelf
anim/armature-drawing-refactor-3
temp-sculpt-dyntopo-hive-alloc
tmp-usd-python-mtl
tmp-usd-3.6
blender-v3.5-release
blender-projects-basics
blender-v2.93-release
temp-sculpt-attr-api
realtime-clock
sculpt-dev
gpencil-next
bevelv2
microfacet_hair
xr-dev
principled-v2
v3.6.3
v3.3.11
v3.6.2
v3.3.10
v3.6.1
v3.3.9
v3.6.0
v3.3.8
v3.3.7
v2.93.18
v3.5.1
v3.3.6
v2.93.17
v3.5.0
v2.93.16
v3.3.5
v3.3.4
v2.93.15
v2.93.14
v3.3.3
v2.93.13
v2.93.12
v3.4.1
v3.3.2
v3.4.0
v3.3.1
v2.93.11
v3.3.0
v3.2.2
v2.93.10
v3.2.1
v3.2.0
v2.83.20
v2.93.9
v3.1.2
v3.1.1
v3.1.0
v2.83.19
v2.93.8
v3.0.1
v2.93.7
v3.0.0
v2.93.6
v2.93.5
v2.83.18
v2.93.4
v2.93.3
v2.83.17
v2.93.2
v2.93.1
v2.83.16
v2.93.0
v2.83.15
v2.83.14
v2.83.13
v2.92.0
v2.83.12
v2.91.2
v2.83.10
v2.91.0
v2.83.9
v2.83.8
v2.83.7
v2.90.1
v2.83.6.1
v2.83.6
v2.90.0
v2.83.5
v2.83.4
v2.83.3
v2.83.2
v2.83.1
v2.83
v2.82a
v2.82
v2.81a
v2.81
v2.80
v2.80-rc3
v2.80-rc2
v2.80-rc1
v2.79b
v2.79a
v2.79
v2.79-rc2
v2.79-rc1
v2.78c
v2.78b
v2.78a
v2.78
v2.78-rc2
v2.78-rc1
v2.77a
v2.77
v2.77-rc2
v2.77-rc1
v2.76b
v2.76a
v2.76
v2.76-rc3
v2.76-rc2
v2.76-rc1
v2.75a
v2.75
v2.75-rc2
v2.75-rc1
v2.74
v2.74-rc4
v2.74-rc3
v2.74-rc2
v2.74-rc1
v2.73a
v2.73
v2.73-rc1
v2.72b
2.72b
v2.72a
v2.72
v2.72-rc1
v2.71
v2.71-rc2
v2.71-rc1
v2.70a
v2.70
v2.70-rc2
v2.70-rc
v2.69
v2.68a
v2.68
v2.67b
v2.67a
v2.67
v2.66a
v2.66
v2.65a
v2.65
v2.64a
v2.64
v2.63a
v2.63
v2.61
v2.60a
v2.60
v2.59
v2.58a
v2.58
v2.57b
v2.57a
v2.57
v2.56a
v2.56
v2.55
v2.54
v2.53
v2.52
v2.51
v2.50
v2.49b
v2.49a
v2.49
v2.48a
v2.48
v2.47
v2.46
v2.45
v2.44
v2.43
v2.42a
v2.42
v2.41
v2.40
v2.37a
v2.37
v2.36
v2.35a
v2.35
v2.34
v2.33a
v2.33
v2.32
v2.31a
v2.31
v2.30
v2.28c
v2.28a
v2.28
v2.27
v2.26
v2.25
Labels
Clear labels
This issue affects/is about backward or forward compatibility
Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports
Apply labels
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
This issue affects/is about backward or forward compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest: Wayland
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest: Wayland
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
Milestone
Set milestone
Clear milestone
No items
No Milestone
Projects
Set Project
Clear projects
No project
Assignees
Assign users
Clear assignees
No Assignees
5 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#101000
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
System Information
Operating system: Windows-10-10.0.22000-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3050 Laptop GPU/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 516.59
Blender Version
Broken: version: 3.4.0 Alpha, branch: master, commit date: 2022-09-04 04:25, hash:
0ff920b777
Worked: never
Short description of error
The OCIO config's
color_picking
role seems to only accept two situations: 1. Colorspace with Linear Transfer Function or 2. Colorspace with Blender's sRGB LUT. Note OCIOv2's builtin sRGB transform also doesn't work, it seems to only work if we use Blender's sRGB LUT.Here is the demostration of the error:
Color Picker Error.mp4
Sept 19 EDIT:
Color Picker Bug 2.mp4
See how the max(RGB)/HSV's V keeps getting higher and higher.
Exact steps for others to reproduce the error
To demonstrate the point, we will use a colorspace that doesn't make sense to use the sRGB LUT, BT.2020.
Download and unzip this testing OCIO config and put it in colormanagement folder:
color picker bug.7z
This testing config has the working space (
scene_linear
role) set to Linear BT.2020, and thecolor_picking
role set to the BT.2020 with this colorspace standard's native EOTFITU-R BT.1886 2.4
.V
value goes up over time. Then close Blendercolor_picking
role at line 11 toBT.2020 with sRGB LUT
, then reopen BlenderV
is unchanged.It doesn't make sense for BT.2020 to use the sRGB LUT, ideally we should be able to use the colorspace with its native EOTF (or any transfer function you want to use it with), instead of hardcode it for a specific LUT.
This is problematic for the development of the Filmic upgrade (AgX) config, as we will not include the sRGB LUT in the new config at all.
Added subscriber: @Eary
I believe color management is under
Render & Cycles
moduleAdded subscriber: @brecht
I didn't check the bug yet, but I hope the plan is not to use BT.2020 as the scene linear color space in a config intended for users? The industry is standardizing on ACEScg for that purpose, using something else is going to create a compatibility mess and I would very strongly advise against it.
The plan is to use
Linear DCI-[P3](https://archive.blender.org/developer/P3.txt)
. The BT.2020 here is just for demonstration.That's not any better, still going to be different than what everyone else uses.
I don't understand how is using a different working space is going to create compatibility issue. Compatibility should be fine with import and export options. The internal working space shouldn't really matter, if I understand it correctly.
Conversion between color spaces is imperfect for arbitrary shading nodes manipulating those colors, smaller gamut means ACEScg colors imported into Blender will be clipped, and from a user point of view it will just be confusing to see different scene linear values in different applications and make interop harder.
From my tests out-of-scope values seems to be present as negative values, the negatives seems to go all the way into the end compositor, where some operations like denoising would clip those negative values. If you don't apply any operation in compositor to clip those negative values, we are developing some negative value handling in the view transform at the moment to bring some values back in range for image formation.
But note we will go spectral in the future. We can easily render values outside of even ACEScg with spectral rendering. Setting the working space to ACEScg won't really solve the problem. And ACEScg involves parts outside of the spectral locus, it will create problems for 1. The image formation (what should a "color" that is not actually a "color" looks like? e.g. ACEScg (0, 1, 0) ) , 2. the spectral reconstruction for spectral Cycles.
It is important to realize that people with Mac etc. have Display P3 monitors, so a reasonable amount of users can actually see those P3 values as they are rendered, on their screens. ACEScg, however, the AP1 primaries are just math results of the CIE XYZ projection. There will never be a display device for it. BT.2020 currently only has laser projectors, but it still exists. So BT.2020 is protentially acceptable given some of its problems with image formation etc. will hopefully be solved in the future.
Regardless if it clips or gives negative values, that's an interop issues users now have to deal with if they bring in EXRs rendered in another application that uses ACEScg that they wouldn't have to deal with otherwise.
As a user, no you should not be able to easily get values outside of ACEScg in a render buffer, the renderer should clip that for you.
In general, I don't agree with the apparent argument that because X or Y would be a problem regardless, we may as well accept dozens of other interop issues that can be avoided.
Added subscriber: @kram1032
The big issue I see with ACEScg as a working space is, that you can get unphysical values not just as initial colors (which, ok, if you happen to know that you can just not make use of those values I guess), but also as bounce light which would be very tricky to account for.
I think with ACEScg that's going to happen for the red and green region. - In those regions, there simply is no good choice for what to display for those colors. They do not exist.
Meanwhile, a large chunk of green and purple values are also excluded by it, so the renderer would be unable to produce them (before spectral rendering and without negative light sources) - but that may be a lesser problem. The only way to fix that with a tristimulus gamut would be to exacerbate the previous problem, going beyond spectral even more.
IMO Color pickers and such ought to have a colorspace dropdown menu, defaulting to whatever the working space is. The ideal implementation would also let people pick what that default is, perhaps in some sort of advanced options menu in the color management menu. That way, people can decide for themselves whether ACEScg is what they want.
But just getting all of that through OCIO configs would also work to the same effect. Either way, it should not be hardcoded.
If you decide, that ACEScg should indeed be the new default, at least making it easily possible to switch to whatever config is desired for a given project by a given user.
An advanced method might display, in an "Advanced Colormanagement" subpanel, what the currently chosen OCIO config gives you for various spaces, plus the ability to overwrite pieces of that config if you so desire.
I.e. it could show this section of OCIO configs (or if the config doesn't specify, use the default Blender configs)
(there are example settings and may not be sensible as such - I'm honestly not sure what some of these mean, although most are pretty self-explanatory I think)
and add an overwrite-toggle next to each, in which case the corresponding line would turn into a dropdown menu with all color spaces Blender currently knows about from various configs.
This would also future-proof Blender in case the aforementioned industry standard gets changed yet again.
But anyway, even if not that, at least a per-material or per Color-node dropdown menu to that effect would be great to have, and could certainly fix the shown issue for any situation. The color picker would simply convert whatever color it picks from what space it currently is into the space specified by the dropdown menu.
Probably should also show some clear UI indicator if the chosen space in the dropdown menu doesn't match the working space to avoid confusion, and the default should be either the working space or, if the config specifies, the
color_picking
space.The Sequencer already has a special menu overwrite, presumably defaulting to
default_sequencer
but overwriting that if need be, and imported images (as textures or in the compositor) also have their overwritable defaults, so it makes sense to expand that to more places in Blender where specifying the way color is interpreted might make a difference.This might be me getting ahead of myself but it would also be nice if configs could actually be passed in as a special socket type in the various node editors. Imagine a huge node tree which, once everything is connected up as desired, you can set to work for a different specific other color space in a single click. If no noodle goes in, it's a regular dropdown menu, but otherwise the colorspace can be passed around freely, including implicit conversions and such.
This would also be quite useful for the Convert Colorspace node in the Compositor, such that you don't have to think about how to interpret the color, you could just go "convert from whatever it currently is (by plugging in the relevant noodle) to this specific one I now want (which also gets stored in an output for yet another noodle)"
No the renderer should make sure it doesn't clip the negatives so the end view transform can utilize the values. If you clip it upstream in the renderer, the gamut clipping and posterization will be a done deal. But with negative values preserved, the view transform will be able to convert those values into XYZ and do stuff to pull more data back in, during the image formation chain.
We need to stop pretending setting ACEScg as working space will avoid any of the stated issue. People would use Adobe RGB, ProPhoto RGB etc. in other software, setting the working space to ACEScg is not going to avoid any interop issue. People have been and will be seeing different working space values in different software, it is more or less expected.
The solution I see, is 1. make sure the renderers don't clip the negatives, so the view transform can do its job. 2. support
convert colorspace
node in the shader editor. 3. support easy on-the-fly change of config file they want to useBTW P3 is actually an industrial standard working space, P3 is the standard for end cinema delivery, so it's natural to use that as working space. For instance, the Lego movie used Linear P3 I-D60 working space for the rendering, and used Baselight for downstream process like view transform etc. We are not "doing something the industry isn't", since P3 is also widely used in "the industry", if you will.
The values will be need to be clipped, you can't correctly accumulate negative samples in a render buffer or EXR file.
When it comes to 3D apps, I think the only people who will be doing this is those who already know what they are doing with color spaces. Most users will use the default configs that use either Rec.709 or ACEScg linear spaces. And so assets interchanged between apps, USD files, are not going to be AdobeRGB or something.
And then the studio switched to ACEScg once that was established as the standard.
It has been very clear that ACES has been used as file interchange space. "The industry is using ACES" is more or less an illusion.
Again, P3 is industrial standard, we are not doing things very different from what "the industry" is doing.
Then I guess it will be solved by spectral rendering, where the accumulated samples are spectral based, and it will go through the observer model into RGB after the sampling process. I wish there is a way to avoid clamping negatives upstream for RGB rendering though. One thing I am sure is that EXR files can correctly encode negative vlaues, since the EXRs we have been testing against have a lot of negatives in them.
Well, it's not an illusion in the Animal Logic case I think, given the assets in the ALab scene. And also not an illusion for all the Maya users that have it as their default config.
P3 is a standard display color space, not a standard working space in 3D apps.
For pipelines that are already using ACEScg this may not be a real problem so it remains to be seen if a lot of applications will even try to solving it. I certainly would not prioritize it in Cycles development.
It's also a standard practice to use P3 working space in "the industry".
Again ACEScg doesn't solve the problem since it doesn't cover the entire spectral locus like spectral rendering does. Negative value handling is essential to prevent clipping and posterization. I can already tell you the current in-development AgX can already avoid some posterization present in "the ACES workflow" by having the in-development negative value handling. But clamping it upstream will make this effort meaningless, since the data will not make it to the end view transform.
Here:
https://devtalk.blender.org/t/filmic-and-aces/22408/38?u=eary
Someone who actually worked in Animal Logic said:
The thing about Maya etc. was those parties reaffirming the illusion.
RE-EDIT: Ok they did mention using ACEScg for rendering, I admit my selection bias here
Whether P3 or ACES is to be the default (Personally I'm on team P3), the current color picker does not work for anything other than Rec.709, right? Something needs to change, and I think a config-based approach is going to be the most flexible, most future-proof method.
Even if ACES really were the de-facto industry standard right now, there is no reason to expect that it's going to keep that distinction forever.
So they did confirm ACEScg is used for rendering, not sure why you edited your comment to remove that info.
@kram1032, yes, there is most likely a bug here that needs to be fixed. I highly doubt we'll ship any configuration in Blender that is not Rec.709 or ACEScg, but with OCIO config files you can do whatever.
Ok I admit that's a selection bias on my part. But I still believe ACEScg is just a extended-to-outside-of-the-locus version of Linear BT.2020 with a non-standard white point, which means BT.2020 would be the more reasonable choice.
I thought properly at least supporting P3 was one of the goals of https://developer.blender.org/T68926 ?
At least that's how I understand the meaning of
That's of course a Display setting, but if you're gonna be able to use P3 displays, I'd hope you could also specify colors with respect to such a display. It'd be weird to only be able to either select from Rec.709 so you can't even reach the limits of P3, or select from all of ACEScg so you can easily escape from P3 on accident
It means only what it says, there's no intent to ship with a P3 working color space.
Added subscriber: @OcularEvolution
@brecht So then will a proper config based method be implemented? Because currently, having to manually replace config files between Filmic, Aces, and AgX, based on either client or personal work is such a pain. :(
I think the perfect solution is to have colorspace dropdown in the color picker wheel UI. Similar to units setting, when unit scale is at default 1.0, Blender internally uses meter unit, even when the user set the unit setting to centimeter. Similar things can be done with color picker UI. We can either have a per-color-wheel setting or a global setting, to have the color picker expose values in a certain colorspace that can be different from the working space, like internally meter, but UI displays centimeter.
This will also solve the problem with backward and forward compatibility when you change the working space. Older .blend files pre-3.x (which ever version AgX ends up merging to) can be detected and the setting will just fall back to Linear BT.709 I-D65. Newer .blend files can have that setting memorized, so in the future if we change the working space again, that setting will remain, making the RGB inputs consistent despite the change in the working space in future versions.
Working space choice should prioritize the need of the software itself, not "use the same values as other software". For example, in preparation for spectral Cycles, the working space will need to have illuminant E white point. So BT.709 or P3 or anything, it will need to be I-E based. If we keep the existing color picker UI, I imagine you will disagree with I-E as well. But with a UI only setting similar to the unit setting, I think you can accept P3.
I think the sane option is to have ACEScg as a working space and store the colors as such, and then provide UI options to edit colors in other spaces if desired. I don't think that spectral rendering requires illuminant E white point in the working space, why would it?
UI settings can only hide so much. Once you start doing things procedurally with shading nodes, geometry nodes, drivers, then the real values start to matter. Converting .blend files between different working spaces is something we plan to implement, but it will be imperfect since we can't convert procedural aspects. Interop between applications becomes a mess as colors become negative or get clipped, USD files and textures will have no or wrong metadata requiring users to manually specify color spaces, custom scripts will forget to do proper conversions, etc. The reality is not an ideal world where every part of the pipeline perfectly handles color spaces, it's a patchwork of many different things and using as few working spaces as possible prevents issues.
It's for the spectral reconstruction/upsampling from RGB textures. In users standpoint, RGB (1, 1, 1) means white, meaning they reflect the incoming light in 100%. But when you turn that RGB texture into spectral data, it only makes sense to have the "white" be illuminant E, otherwise the color mixing behavior would be biased. The spectral branch has been shipping a custom config with I-E based working space. It is essential to have I-E based working space looking ahead.
In those case we need to have
Convert Colorspace
node in the shader editor. The node can be auto-added as versioning solution. Like Geometry Nodes auto-addsRealize Instances
node as versioning, I think auto addConvert Colorspace
node should also work.P3 is reasonably large already. It shouldn't matter as long as the view transform holds up and not producing a broken image. I think AgX is doing a good job at those areas. Just tested again and hard clipping in P3 is causing significantly less problems than hard clip in BT.709. As long as the end image holds up, I think hard clipping is fine.
Negative vlaues are fine as well since the view transform will transform them to XYZ and do stuff (it's actually better to leave those negatives for the view transform to handle). Again it's fine as long as the end image holds up, and the view transform is the key here.
I have not looked at this closely enough, but I imagine applications/studios using ACEScg somehow don't impose this requirement.
A shader or compositing setup where every other node is a convert colorspace node is hardly usable and will have poor performance. It would also only solve part of the problem. I don't see any application implementing this kind of thing.
The negative values are not going straight to the view transform, they're going to cause problems in shading and compositing before that.
Getting back to the bug report, I'm actually unable to reproduce this so far with either
color_picking
space. Tested on macOS Arm.`It looks like some precision issue where the values drift away from 1.0.
The Color Picker is Hardcoded for the sRGB LUTto Color picker colors drift above 1 for some OCIO configurationsChanged status from 'Needs Triage' to: 'Resolved'
Fixed in
2eb19ee
.There's indeed some imprecision going back and forth between color spaces:
There's nothing hardcoded to Blender's sRGB LUT, that one just maps 1 exactly to 1.
Not sure how other spectral renderers handle this, but this is indeed what spectral Cycles requires. Note spectral Cycles also require XYZ role to be I-E based (well, the proper XYZ standard has always been I-E based anyways), meaning the sky texture, blackbody nodes etc. need to stop assuming XYZ I-D65, and instead properly expect the XYZ I-E standard. Keep in mind and be ready, an I-E based system will be more future proof, so AgX will come with an I-E based config.
Good to know, glad it's fixed. Just not sure why the sRGB LUT didn't suffer from the precision issue.
Just tested in the latest daily build, it's not fixed. If you set the
V
value to 1 in advance, it keeps 1 unchanged, but if you setV
to 0.8 in advance, it starts drifting to 0.801, then 0.802 again. The precision issue seems to be still there.Updated the description with updated video
I mean some imprecision is gonna be unavoidable. However, the level of imprecision here probably comes down to how many digits after the decimal point the transformation matrices use...
If they only use like four digits, they are only accurate to like four digits, and every time the conversion happens, you add more and more errors on top.
Maybe the behavior could somehow be improved by locking in some coordinates so they can't change at all?
Specifically, when dragging the dot in the color circle, the value would by definition be fixed, right? So as long as the dragging happens, the conversion should ignore the updated value and keep the old value.
Meanwhile, if you drag the value slider, the hue and saturation ought to be locked.
I'm not sure if this is completely feasible, but that would certainly fix this issue, right?
Not sure if that would also automatically fix the issue in RGB mode but I'd kinda think so. A value of 1 means a maximum RGB value of 1, so it should be fine, right?
It's very clear now that the colorpicker itself does indeed change color spaces: You can tell by the new video, that it struggles to show the full space. For instance, there is a visible line between yellow and red. (To be clear, this is expected behavior, not a bug!)
The display of the color wheel is different from the values, the wheel I believe uses the first view transform in the config. Meaning it can potentially be displayed with AgX if the order of the views change, but I think we can keep display's native as the first view.
At any rate, this task needs to be reopened, the problem is still there, just with a different behavior at
1
, still the same as before at0.8
. @brechtChanged status from 'Resolved' to: 'Confirmed'
Color picker colors drift above 1 for some OCIO configurationsto Color picker colors drift value for some OCIO configurationsAdded subscriber: @Accelero
To the actual Problem: From my own testing with OCIO configs, my first guess, without looking at the code would be, that the Picker is not limited to the visible color wheel and allows picking values outside the circle. When choosing sRGB to display colors in the picker and using a much larger scene referred color space, the selection can be outside the visible wheel anywhere in the scene referred space. This makes sRGB values above 1 possible and the picker's behavior is strangely for that. The issue should therefore only occur after touching the outer edge of the color wheel (V doesnt have to be 1, just one component above 1).
Ways to prevent this are:
The behavior with values above 1 sould be looked at, but for now one of the 2 solutions above should prevent the problem.