- User Since
- May 20 2007, 5:54 AM (504 w, 3 d)
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.
The fuzzy is because cubic never passes through the sampled values.
Jan 15 2015
Sergey is 100% correct: this patch is sub-optimal as it currently exists.
Dec 30 2014
A few points, and I'd prefer to cover the follow ups via email as this report is already cluttered up enough for developers that need to tackle the complex issue. You can reach me here.
Dec 29 2014
Forcing an artist to enter linear values instead of sRGB is the same as forcing someone to enter binary numbers instead of decimals. Linear values don't mean anything to artists. Artists are used to Photoshop or Painter that use sRGB space, the same as almost any graphics application around.
padone, assuming any single color space for the color wheel is simply incorrect, as outlined in the other report.
Oct 3 2014
Apologies. You are quite right... It was never intended as harsh.
Sep 28 2014
@David Black (david_black) You are mixing apples and oranges when discussing Photoshop. Photoshop operates on curved non-linear display spaces by default, and I believe it only recently, if at all, color manages the wheel. So it is in no way linear, nor even belongs in this discussion.
Sep 2 2014
Then the UV picker is screwed again.
I've tried to do a very simple example here with scaling. A simple 8 bit sRGB PNG is embedded.
Sep 1 2014
Aug 29 2014
this last patch addresses the transfer curve portion issue but display interpolation is still done in a linear manner across endpoints of the triangles that make up the color wheel during display. Also you'd need to change the code in the vertical widgets to use the unmodified value for displaying the slider, see ui_draw_but_HSV_v. also would probably need to be hooked up in the update functions
Aug 27 2014
So as to (for example) not apply to theme colors which are sRGB always.
Aug 22 2014
So I have completely redone how the original HSV wheel handled color, and tested quite extensively.
Aug 20 2014
So an update...
Aug 19 2014
It all makes much more sense to me now. I suppose the most relevant example of this for me is when I render/composite my image on my right monitor exactly how I want, yet when I drag the image to my left monitor the color is barely different enough to be annoying. While it is annoying, it's quite minor compared to shifting a fundamental aspect of building materials.
I would add that many artists are going to likely split right down the middle on this regarding whether to display the transfer curve as perceptual (current) or display linear (previous) and there is no right or wrong, but rather expectation and experience.
At the request of Pablo, I quickly did up the explanation above to highlight the bug from a colorimetry side.
I've done a little more hunting and can only conclude that the 0.35 red, 0.58 green, and the 0.20 blue belongs to no known primaries that I can find. They appear absolutely arbitrary and entirely out of line with Blender's internally assumed reference space based on the default OpenColorIO configs.
Aug 12 2014
I tend to agree with maisef here in that language is useful.
Aug 11 2014
Sadly, all of the functions here make assumptions of the RGB reference space being sRGB / 709, which is likely unfortunate due to:
- Hard coded reference space assumptions are a Bad Thing(TM) and make the results entirely incorrect and / or unpredictable depending on an artist's chosen reference space.
- Work against and will cause bugs given a proper color managed system, especially with regard to correctly displaying color.
Aug 4 2014
Color management on pickers and swatches goes much further than merely transfer curves.
Jul 25 2014
With the default window size, the text is already clipping.
May 26 2014
May 23 2014
“Okay, then I say it seems the HSV<->RGB conversion used by Blender now works well only between 0 and 1. Above V=1, it is an extrapolation and goes to infinity quickly when converting from HSV to RGB.”