- User Since
- May 20 2007, 5:54 AM (643 w, 4 d)
Wed, Sep 11
Thu, Aug 22
OpenEXR reading and writing should use chromaticity metadata to determine the color space of the image, and convert it to and from the working color space.
Aug 5 2019
But it’s a deep rabbit hole that requires attention.
Jul 13 2019
So what to do?
Jun 14 2019
@Ivan Cappiello (icappiello) I had ordered the config originally because Blender didn’t have the colour picker role in use, and it went by order for a long time.
May 28 2019
The alpha format dictates the over operation here. Wrong over, wrong output.
May 27 2019
I rebuilt my example shader in Unity and Unreal Engine, and neither of them display dark outlines in the semi transparent areas of the image texture.
May 23 2019
I believe UE BLEND_AlphaComposite performs the canonized Porter Duff and assumes associated.
The problem is that hardware accelerated sRGB to linear conversion appears to assume unassociated alpha.
...because the color information is lost...
May 20 2019
May 18 2019
This serves as an ideal example of an image that has colour data in the 100% transparent pixels that you can view in Blender's image editor by isolating the "Color" channel.
May 15 2019
It is indeed sub-optimal. Promotion makes good sense I suppose in this light.
I see your vantage.
OpenColorIO handles all of the shader compression schemes, so no issue on that side. V2 elevates it further, making for a 1:1 with CPU, via the same compression architecture extended to more granular results.
Doesn’t it make more sense to simply let OCIO do the full transform and utilize the allocation format and range assigned for maximum fidelity?
May 14 2019
It’s not about optimizing so much as keeping the encoding as it is tagged. A simple example is a camera referred REC.709 OETF at 8 bit; it should come back as such, not as the sRGB OETF. Same goes for the litany of other encodings that are designed for 8 bit.
Yes. I see that my comment is not specific to this fix, which is required.
I believe this might be problematic on the 8 bit front, as it ends up encoding the resultant buffer to an unknown, unclassified state?
The procedure to reproduce it is pretty easy and straightforward, why do you need a gif?
Hex values are colourspace dependent and have little use outside of other facets. They are a *very* bad idea.
“Go crazy” isn’t a very useful description. Can you provide screenshots or an animated GIF of the issue happening, along with samples of some of the values?
May 5 2019
Words like Default and Standard don’t really tell the user anything useful.
Can we keep this on topic?
We should not make any changes here for 2.80.
May 4 2019
Color management discussions are confusing enough, I can't rely on an interpretation of a Slack conversation to make design changes.
Brecht, I'm not the enemy here. I'm speaking solely on the "authority" of understanding a basic level of colorimetry and having spent quite a few years around the OpenColorIO folks. I'm not making things up here.
As an addendum, if you do intend to adhere to some Blender rules about how Blender thinks colour transforms work, you'd be wise to follow OpenColorIO's design and not use children of GroupTransforms to accomplish it. Use the View, and append the look onto the view using suitable syntax. As an example:
This isn’t about your opinion beyond how you wish something to be in Blender. That's fine. It's a personal misunderstanding as to how OpenColorIO works, and pixel management in general.
now follows the OpenColorIO design better
Apr 4 2019
Apr 3 2019
Apr 2 2019
Apr 1 2019
You can’t calculate vectorscope positions without knowing the chromaticites of your RGGB camera primaries.
Mar 31 2019
Feb 2 2019
The inputs would indeed need to be applied per image buffer, as that is OCIO’s design to take all imagery to the same scene referred reference space. The VSE abuses this design.
Part of this is the fact that the VSE abuses OCIO in an attempt to work around some of its limitations.
Jan 28 2019
Wait, did you just ask me to submit a patch on broken code that you just committed when the fix is to simply not put the code into the codebase in the first place?
Jan 27 2019
That’s great news then!
Perhaps I wasn't clear.
So I'm wrong again.
OCIO has two paths:
@Brecht Van Lommel (brecht) It appears this never was reverted to undo the broken code. Can we fix this please?
Jan 19 2019
It’s Blender’s broken alpha handling. Has been this way forever, and the “fixes” that were added broke it at least as bad. And the viewer is broken.
Jan 6 2019
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 bit, 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.
Jan 5 2019
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.
Dec 25 2018
I've long been of the opinion that the VSE needs a complete redesign and rewrite from scratch.
Dec 24 2018
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: