Brecht, you keep explaining to someone that understands colour mechanics better than most on this site, that it will make things worse. This is false. The situation is already dire, and you folks keep resisting against the glaringly obvious problems.
May 5 2018
What part are you not comprehending here exactly?
May 4 2018
We know that the problem with Cycles and every broken area of Blender proper is the worthless convention.
Don't assume sRGB transfer function everywhere. It is 2018.
May 2 2018
The correct formula for calculating scene referred exposure adjustments is:
Apr 30 2018
The coefficients are derived by looping through the entire horizontal and vertical rows and columns of data.
Apr 29 2018
The sampling algorithm and implementation is to be formulated in a terms that does not need require the whole buffer.
You must not duplicate whole buffer, limit it to the tile only.
Apr 19 2018
What a classy gesture on Brecht's part! Props Ton. *clap clap*.
Apr 18 2018
This is a different issue regarding transformation order, but alas.
Apr 9 2018
Jan 9 2018
If you can't tell the difference, it may not be working correctly. Should be as clearly apparent as in https://youtu.be/nfhTET86kdE
Jan 2 2018
Chatted briefly in IRC.
Dec 31 2017
How about we just close this and rename the node to "Doesn't do what the node label is supposed to do" node, then we won't need to commit the three line patch.
This should honour the reference colour space primaries, which I am assuming 0.6, 0.3, 0.1 are attempting to provide some sort of random coefficient weights?
Dec 9 2017
T53471 has the issue and solution. Use width and height instead of DPI setting to render.
Hard coding the pix_width and pix_height solves this if and only if you clean out the prior dot dat files for some reason.
Dec 5 2017
I suspect it is the DPI difference and that somewhere Blender is using that DPI to calculate the canvas size?
Nov 30 2017
These are all display referred formulas. Entirely broken on scene referred data.
Nov 26 2017
OCIO version 2.0 will have CL support.
Nov 20 2017
Any chance we can move a bit on this and T46860 before SIGGRAPH 2018?
Nov 6 2017
Sep 12 2017
Regarding luminescent pixels, I had that fixed at one point. The predivide was the problem here, and I couldn't track down where the case of alpha == 0 was discarding RGB data. It could be solved by skipping the RGB values on the multiply in the case of alpha == 0 or setting the alpha to some extremely small value. Either scenario would preserve RGB for no occlusion / high emission cases. The OpenGL ONE_MINUS set properly blended all values, luminescent and non, when tested.
Sep 10 2017
Bump. Sergey? 2.8 please. kthxbai.
Aug 20 2017
No look indeed corresponds to the Base Contrast, one fewer setup step learn or forget. But also, in OpenColorIO design looks are meant to modify the image in a creative manner, not affect the output color space.
Aug 9 2017
I didn't mention the EOTF anywhere. My point was exactly the that you can get output in sRGB color space even when using a log transform, without the sRGB EOTF.
I just discussed this with Sean Cooper to make sure I wasn't losing my mind. Relevant points follow...
The original SPI configs contain no looks, and the docs seem pretty clear to me.
A “look” is a named color transform, intended to modify the look of an image in a “creative” manner (as opposed to a colorspace definion which tends to be technically/mathematically defined)
Seriously Brecht? Give your head a shake and look at the original Sony configurations.
Base log is useful for a number of reasons, not the least of which is interchange with display referred grading applications.
Jul 23 2017
- (optionnal) color of other engines won't be correct. Make them linear (somehow), maybe by changing the colors in the UBO struct.
Jul 16 2017
Currently the VSE is largely in a maintenance only mode. On your points:
Jun 23 2017
This is sadly due to the swscale reliance in FFMPEG. Currently, all buffers loaded from codecs are converted to RGB at 8 bits per channel via the swscale library. This likely won't be changing any time in the near future unless the FFMPEG handling is overhauled to load raw YCbCr and let OCIO handle the colour transforms.
May 16 2017
May 4 2017
Apr 18 2017
How are you performance testing the lookups with the viewport? I have a few tests I would like to try with a degree of certainty.
Working on it.
Paul, can you test this with your image? I will try if I can get a window when I am near a box.
Apr 16 2017
Jesus Alex, you are at it again with your hyperbolic rubbish.
Mar 12 2017
Ok, I think we have really different ideas about UI design here, I don't think we're going to agree about what the best solution is. I strongly prefer names that indicate purpose rather than implementation, orthogonality of functionality whenever reasonably possible,
Mar 11 2017
I think the filmic transform is very important. I have looked into the ACES config in detail and I believe what I am proposing is consistent with it, but maybe I'm misunderstanding it then.
If we look at the "Utility - sRGB - Texture" color space in the ACES config, it converts from a wide gamut reference space to linear sRGB with a matrix transform, and then to sRGB with the sRGB EOTF. What I'm proposing is that we do the same for image textures when we adopt wide gamut. If the intention for filmic with wide gamut is to do the same as ACES here, that's fine with me.
I think the OpenColorIO design and existing implementations and configurations are clear, color spaces and transforms are not the same thing. Being able to specify an absolute color space rather than a transform relative to some other color space is critical for making exchanging of image files between applications work.
Mar 10 2017
The image setting here is not a transform, it is the color space of the image file on disk. If there are multiple ways to transform to/from that color space, that should be a separate setting.
But that's kind of my point, calling it just "sRGB" is entirely standard in 3D software and accurately describes the color space.
For this we would use a name like Linear sRGB, Linear BT.709, .. to distinguish from sRGB. The way I understand the design of OpenColorIO is that this is a place where you give the name of a color space, not the name of a transform. I don't think anyone will be confused in thinking that selecting "sRGB" will save linear.
If we can get better support for roles in 2.79 I doesn't really matter if it's called Non-Color or Non-Color Data. If we don't get better roles in 2.79, we will need compatible names.
For example if I set a normal map image to Non-Color now, that does not exist in filmic and it will use the SRGB EOTF, and the render will be wrong.
Mar 9 2017
Apologies for not being clear on my thinking.
The only reason we are having this discussion is because folks are actually using and trying the colour management transforms. At least part of that I would attribute to the clairty of the configuration which has all portions operating together.
Mar 8 2017
For filmic though, why have a separate configuration?
Mar 6 2017
How do we make it easier to interchange one configuration with another? Shall we introduce non-color space as a role to address current issues? Do we have other cases to be covered to make interchange less painful?
Feb 10 2017
First, DCI-P3 is a specific shift in chromaticity to the DCI-P3 basis primaries. I haven't confirmed that the correct shift is going on yet with the one that is in the config, and I would not hold my breath as the configuration was cobbled together, mixing and matching transforms.
Nov 27 2016
Jul 14 2016
DPX is actually a SMPTE standard, much like many other facets already within Blender. It is used almost exclusively to communicate display referred image encodings.
Jul 13 2016
Any motion on this?
May 8 2016
While we are at this patch, the default config should be chucked out. The ACES bits are entirely wrong, the legacy copied transforms from the SPI pack is completely wrong in this context, and a hundred other errors.
May 6 2016
On the Offset UI element, it would seem fine to permit negatives?
May 4 2016
Not sure about this if only because it prevents transfer of CDL values to other applications. There is no basis value available in the CDL, simply an offset.
Apr 30 2016
This isn't related to the bug and likely due to a combination of GOP with non-equal encoded data.
Apr 13 2016
The specification is an SMPTE standard that can only be downloaded from the various international standards sites for a fee. The general outline can be read at http://www.digitalpreservation.gov/formats/fdd/fdd000178.shtml#local
It has nothing to do with specs. It has to do with transfer curves, something that everyone in the motion picture world deals with every day. It isn't complex if imagers can select the damn colourspace, just as they do with _every other RGB format out there_.
Apr 12 2016
If one examines the SLog, VLog, CLog, and all of the other variants at HPD's ACES repo here https://github.com/hpd/OpenColorIO-Configs/tree/master/aces_1.0.1/luts, one can see the problem; it is impossible to hard code all of the camera vendor transfer curves into Blender. That doesn't even include revisions and other custom transfers.
Given the ArriRaw converter, there are at least a dozen different implementations that can be encoded into a DPX.
Mar 27 2016
Sergey, can we just fix this? I am really hesitant to even attempt to fix anything else color related, of which there are hundreds of things, if we can't simply agree that:
Mar 14 2016
I don't think it's really great idea to change wheels to sliders, and i don't find new tooltips any more artists friendly.
Mar 8 2016
Mar 7 2016
Oops. I mistakingly posted "Slope" when I should have said "Offset". Dummy.
Mar 6 2016
I'm strongly believing we should revisit this and make DPX code loading precisely the same as the rest of the image loading code, EXR excluded as also needing transforms.
Feb 18 2016
Currently, getting in and out of Blender is a challenge.
Feb 17 2016
Just bumped into this today.
Feb 6 2016
Operating system and graphics card
Linux amd64 Debian Squeeze
Feb 1 2016
@Sergey Sharybin (sergey), would you be against a global flag in User Preferences that flips on a "Legacy Mode"?
Jan 23 2016
It is a step to getting Blender's internal logic up to date.
This is a tremendous question actually.
Apologies for mixing. I will re-report two more.
Jan 20 2016
On subject, it appears the line in rna_nodetree.c that restricts the maximum value to 1.0 should be changed to FLT_MAX to accommodate Cycles scene referred ranges as well.
Luminance will always depend on the chromaticity coordinates of the particular RGB reference.
I haven't exactly looked at the code, but I'm pretty sure that it isn't a Bradford transform, which could be added later as a toggle.
Jan 4 2016
Ok so my other bug report appeared to be correct to the best of my knowledge; the mix node in default "Mix" mode ignores the colour in the node socket if it is unattached.
While I was working on a patch for this, it strikes me that there is a zero percent chance that the "Use second image's alpha" works correctly either.
Nov 26 2015
Just donned on me that we can't leave the sRGB transfer curve hard coded as it makes no sense.
Nov 25 2015
If the plan is to improve color space support for image textures as well, then you either need LUTs for conversion in the kernel, or we can do conversion to linear (half?) float outside the kernel, at the cost of increased memory usage.
Aug 26 2015
@Alexey (Inwader77): Chances are “proper working” means “completely broken” in terms of color management.
i don't understand, why "completely broken" maybe in this node we have other errors, but with value all properly - value equal maximum of R G and B. for Lift, gamma and Gain color selectors only, in image input color slector - working with bug.
The issue is the correct transformation of primaries for the reference space.
Aug 24 2015
@Alexey (Inwader77): Chances are “proper working” means “completely broken” in terms of color management.
Mar 22 2015
As per above. At the very least, the weights should be sRGB / 709, and we should begin a discussion about color managed UI in earnest as it covers much more than this touchpoint.
I'm sorry, but everything about this is wrong.