- User Since
- May 20 2007, 5:54 AM (548 w, 1 d)
Any chance we can move a bit on this and T46860 before SIGGRAPH 2018?
Mon, Nov 6
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...
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
Mar 11 2017
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
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
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.
Feb 26 2015
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 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.