It can be a matrix and I have both broadcast and full range versions. I will look into this possibly after I fix the XYZ hard coded paths.
Feb 26 2015
Feb 21 2015
Where are we at on this?
Feb 18 2015
Seriously folks, it uses a global value. There is el-zippo performance issue here.
Feb 17 2015
Feb 13 2015
Addresses Sergey's remaining concerns.
Feb 11 2015
Also, sorry for spam, but BLI_INLINE doesn't work according to Bishop and testing, without the luminance function being BLI_INLINEd as well.
Regarding legacy files, I believe the worst case weight mangling was approximately 15% for green. I am unsure how to proceed in the color cleanups regarding legacy files, and advice would be appreciated. Versioning strikes me as a potentially problematic implementation?
Feb 10 2015
Hopefully fixes the oopsied last diff.
Feb 9 2015
I'm not 100% certain if all the operations here are in display or linear space. I think compositor is linear, but image (divers.c) and imagefile (png.c) might not be.
Added and tested byte conversions as used by vertex_paint.c. Removed corresponding duplicated function.
Great spot @Kévin Dietrich (kevindietrich), which is exactly why I added you as a subscriber. I also saw one in Freestyle I believe, which is a Python file IIRC.
Feb 8 2015
Marking as invalid and putting relevant data under the Differential based on @Julian Eisel (Severin)'s advice.
The fuzzy is because cubic never passes through the sampled values.
Jan 15 2015
Sergey is 100% correct: this patch is sub-optimal as it currently exists.
Dec 30 2014
A few points, and I'd prefer to cover the follow ups via email as this report is already cluttered up enough for developers that need to tackle the complex issue. You can reach me here.
Dec 29 2014
@Troy Sobotka (sobotka)
In general artists work in srgb space for videos and adobe rgb for paper. Then do a color conversion to match the output device. So srgb is good even if your final output is different (rec709 dci or whatever). At least this is how they recommend to work at Eizo (see page 13).
Forcing an artist to enter linear values instead of sRGB is the same as forcing someone to enter binary numbers instead of decimals. Linear values don't mean anything to artists. Artists are used to Photoshop or Painter that use sRGB space, the same as almost any graphics application around.
padone, assuming any single color space for the color wheel is simply incorrect, as outlined in the other report.
Oct 3 2014
Apologies. You are quite right... It was never intended as harsh.
Sep 28 2014
@David Black (david_black) You are mixing apples and oranges when discussing Photoshop. Photoshop operates on curved non-linear display spaces by default, and I believe it only recently, if at all, color manages the wheel. So it is in no way linear, nor even belongs in this discussion.
Sep 2 2014
Then the UV picker is screwed again.
I've tried to do a very simple example here with scaling. A simple 8 bit sRGB PNG is embedded.
Sep 1 2014
Aug 29 2014
this last patch addresses the transfer curve portion issue but display interpolation is still done in a linear manner across endpoints of the triangles that make up the color wheel during display. Also you'd need to change the code in the vertical widgets to use the unmodified value for displaying the slider, see ui_draw_but_HSV_v. also would probably need to be hooked up in the update functions
Aug 27 2014
So as to (for example) not apply to theme colors which are sRGB always.
Aug 22 2014
So I have completely redone how the original HSV wheel handled color, and tested quite extensively.
Aug 20 2014
So an update...
Aug 19 2014
It all makes much more sense to me now. I suppose the most relevant example of this for me is when I render/composite my image on my right monitor exactly how I want, yet when I drag the image to my left monitor the color is barely different enough to be annoying. While it is annoying, it's quite minor compared to shifting a fundamental aspect of building materials.
I would add that many artists are going to likely split right down the middle on this regarding whether to display the transfer curve as perceptual (current) or display linear (previous) and there is no right or wrong, but rather expectation and experience.
At the request of Pablo, I quickly did up the explanation above to highlight the bug from a colorimetry side.
I've done a little more hunting and can only conclude that the 0.35 red, 0.58 green, and the 0.20 blue belongs to no known primaries that I can find. They appear absolutely arbitrary and entirely out of line with Blender's internally assumed reference space based on the default OpenColorIO configs.
Aug 12 2014
I tend to agree with maisef here in that language is useful.
Aug 11 2014
Sadly, all of the functions here make assumptions of the RGB reference space being sRGB / 709, which is likely unfortunate due to:
- Hard coded reference space assumptions are a Bad Thing(TM) and make the results entirely incorrect and / or unpredictable depending on an artist's chosen reference space.
- Work against and will cause bugs given a proper color managed system, especially with regard to correctly displaying color.
Aug 4 2014
Color management on pickers and swatches goes much further than merely transfer curves.
Jul 25 2014
With the default window size, the text is already clipping.
May 26 2014
May 23 2014
“Okay, then I say it seems the HSV<->RGB conversion used by Blender now works well only between 0 and 1. Above V=1, it is an extrapolation and goes to infinity quickly when converting from HSV to RGB.”
"sRGB is correct only between 0 and 1. What if you use linear space or scaled normalized vectors above V=1?"
I thought that I should add some relevant information, as solving this issue isn't quite as simple as it might first appear.
Apr 15 2014
This extends beyond transfer curve to primaries. This means the actual color cannot be correctly displayed ever, regardless of color space selected, including sRGB.