- User Since
- May 20 2007, 5:54 AM (608 w, 4 d)
Sun, Jan 6
I’d add that if the baseline in all of Blender were associated, the many, many, many non trivial alpha errors, including the flip flop issue you cited, would be solved. You’d never be going unassociated from associated at 8 but, as it is nonsensical.
I believe it is more than a round trip quantisation issue.
The hack only applies to file reading, and does not affect the metadata saved into any file.
- Save an image with alpha from Blender, or attempt to find a image with unassociated alpha on the net. The latter will be virtually impossible as TIFFs by canonical default are associated.
- Load the file in Blender.
I was under the impression that the IB_PREMUL flags handled the saving? If not I can fix that.
Fixed by D4175.
Sat, Jan 5
Flagging as resolved.
Who knew! Thanks @Philipp Oeser (lichtwerk) that indeed was the difference.
Yes. I suspected that, but for me, the darn popup still isn't appearing. Even tried assigning it to a keypress.
Tue, Dec 25
I've long been of the opinion that the VSE needs a complete redesign and rewrite from scratch.
Mon, Dec 24
I’m with @Brecht Van Lommel (brecht) on the subject; random concepts makes for random design. Focus on the needs of the open movies to guide the nature of the design.
Dec 18 2018
2018 and the viewer is still broken peeps. Can we fix it please?
Dec 14 2018
Dec 6 2018
Seems to segfault when no active displays listed.
Dec 5 2018
Intent is that a person who saves a file using a proper transform doesn't end up with the proper file.
Dec 2 2018
Nov 26 2018
This is dumb.
Nov 7 2018
Nov 6 2018
This is an easy fix I believe in the broken GPU allocation.
Oct 13 2018
Highlight compression is the distance between the peak of the linear section of the curve and the terminating value. It's probably something that loosely controls the shape of the curve or the range of values.
I think the Looks implementation is a bit in need of an update for sure. @Brecht Van Lommel (brecht) wisely implemented some rudimentary filtering, which would be likely more ideal via OCIO's families perhaps.
Not sure here, but Gamma can be used in place of contrast when it comes to Filmic but maybe it only affects the midtones.
Sep 25 2018
This appears still in master.
Sep 4 2018
@Jeroen Bakker (jbakker) any chance we can revisit this and implement the cubic prefilter approach? It is likely one of the best in breed for pixel manipulations given it doesn't overshoot nor undershoot, and delivers stable math on the output.
Aug 26 2018
Shorter term solution should be:
- Replace drop down with an OCIO enumeration of available transforms.
- Run the curve interpolated values through the selected transform as a to_reference, and use accordingly.
Having done more research on this strange looking bit of code, it would seem a poorly researched implementation that derives from some other software. In particular, this poorly researched offering is what ended up with the weighting put into Natron, unsurprisingly:
Aug 25 2018
Can you explain what this is doing Jeroen?
Aug 4 2018
Any chance of changing the cancerous format known as PNG to OpenEXR half with DWA for default? PNG compounds the accumulating alpha problems, as well as makes things very challenging moving forwards with proper scene referred streamlining.
Jun 16 2018
For future reference for the XYZ function matching:
May 12 2018
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
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...
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?