# May 5 2018

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.

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

Troy Sobotka (sobotka) added a comment to D2984: Add Cubic B-Spline with Prefilter Algorithm.

The coefficients are derived by looping through the entire horizontal and vertical rows and columns of data.

# Apr 29 2018

Troy Sobotka (sobotka) added a comment to D2984: Add Cubic B-Spline with Prefilter Algorithm.

The sampling algorithm and implementation is to be formulated in a terms that does not need require the whole buffer.

Troy Sobotka (sobotka) added a comment to D2984: Add Cubic B-Spline with Prefilter Algorithm.

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.

# Jan 9 2018

Troy Sobotka (sobotka) added a comment to D2984: Add Cubic B-Spline with Prefilter Algorithm.

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.

Troy Sobotka (sobotka) added a comment to T53471: blender_icons_update.py causes build segfault.

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

Troy Sobotka (sobotka) added a comment to T53471: blender_icons_update.py causes build segfault.

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?

# Sep 12 2017

Troy Sobotka (sobotka) added a comment to T52680: Alpha difference Viewport/F12 .

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

Troy Sobotka (sobotka) added a comment to T47212: Luminance Matte Node Fix.

# Aug 20 2017

Troy Sobotka (sobotka) added a comment to T51896: Filmic default view isn't working correctly.

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

Troy Sobotka (sobotka) added a comment to T52046: Filmic not working on rendered frame in EEVEE.
1. (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 4 2017

Troy Sobotka (sobotka) updated the task description for T51417: sRGB OETF: Unused and wasted performance via the SPI sRGB OETF.

# Apr 18 2017

Troy Sobotka (sobotka) added a comment to T51217: HDR black pixels with buildbot releases only.

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.

Troy Sobotka (sobotka) added a comment to T51217: HDR black pixels with buildbot releases only.

Working on it.

Troy Sobotka (sobotka) added a comment to T51217: HDR black pixels with buildbot releases only.

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

Troy Sobotka (sobotka) added a comment to D2159: DCI-P3 Wasn't Showing.

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.

# 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

Troy Sobotka (sobotka) added a comment to T47212: Luminance Matte Node Fix.

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.

Valid points.

# 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

Troy Sobotka (sobotka) added a comment to T47336: ASC CDL Node: Clamps.

Sorry.
System Information
Operating system and graphics card
Linux amd64 Debian Squeeze

# Feb 1 2016

Troy Sobotka (sobotka) added a comment to T47212: Luminance Matte Node Fix.

@Sergey Sharybin (sergey), would you be against a global flag in User Preferences that flips on a "Legacy Mode"?

# Jan 23 2016

Troy Sobotka (sobotka) added a comment to T47212: Luminance Matte Node Fix.

It is a step to getting Blender's internal logic up to date.

Troy Sobotka (sobotka) added a comment to T47212: Luminance Matte Node Fix.

This is a tremendous question actually.

Troy Sobotka (sobotka) added a comment to T47212: Luminance Matte Node Fix.

Apologies for mixing. I will re-report two more.

# Jan 20 2016

Troy Sobotka (sobotka) added a comment to T47212: Luminance Matte Node Fix.

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.

Troy Sobotka (sobotka) added a comment to T47212: Luminance Matte Node Fix.

Luminance will always depend on the chromaticity coordinates of the particular RGB reference.

Troy Sobotka (sobotka) updated subscribers of T47212: Luminance Matte Node Fix.

@Sergey Sharybin (sergey), @Brecht Van Lommel (brecht), or @Lukas Stockner (lukasstockner97) care to apply this trivial one?

Troy Sobotka (sobotka) added a comment to T47156: Crashes with white balance filter .

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.

Close. Mistake.

# Nov 26 2015

Troy Sobotka (sobotka) added a comment to T46860: Cycles Color space flexibility.

Just donned on me that we can't leave the sRGB transfer curve hard coded as it makes no sense.

# Nov 25 2015

Troy Sobotka (sobotka) updated subscribers of T46860: Cycles Color space flexibility.

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

Troy Sobotka (sobotka) raised a concern with rB4f602ff943d9: Revert part of recent color-management commit.

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.