And this is sigmoid (smooth + sRGB base) next to Blender (I did not match the contrast):
Sure I understand your comparison, my point was that with both of them the compression doesn’t really give the brightness that is expected from the intense light.
I suspect the transition will also be better if this is improved.
In this example here…
…the hard transitions between the colors become much smoother if you set attenuation and color shift for blue:
3 Likes
I found the issue that caused some purple shifts to red: darktable’s HSV handles H = [0, 1), but in my code, some ‘pure’ reds ended up as 0, others as 1 due to arithmetics, and H = 1 is not covered in those HSV routines, and experiences a 60-degree shift, ending up as purple. The reason that even a restoration of 0.01 fixed it was that this only occurred for hue = 1.
The bug is actually in darktable’s conversion functions being inconsistent, requiring hue never being 1 on input, but returning it occasionally. Edit: Probably my bug.
2 Likes
Very cool that you could get to the bottom of that. I guess that makes sense given that the problem came up under very limited circumstances.
After a second look, I think the bug was in my code that connects the two ends of the hue scale, and calculates the difference between two hues. I’ll double-check the details later, but I have the sanitisation code in this new build in agx.c, and it handles the red dress just fine, I think.
I’ve removed the duplicate checkbox for the experimental gamut code. TBH, I think the experimental code will also go, unless someone finds a case where it is definitely beneficial (it’s not urgent to remove it, take your time testing).
The Linux AppImage is here: https://tech.kovacs-telekes.org/dt-agx/Darktable-5.1.0%2B803~g4b359c70db-x86_64.AppImage
@priort, @Dave22152, @MStraeten, please update your builds.
3 Likes
Here’s the build 803 executable for Win 11:
2 Likes
The black in the top left in the blender images just seems like a “truer” black or shadow whereas on the left it looks more like what you see when you turn on black point compensation in an app…I wonder if the difference here is something around the handling of black or the near black tonal range??
I have tried all the recent Windows builds, but they still have the red shift in the highlights at default values:
Just downloaded the Mac version and tried it for my black and white street photos. It is a dream to use, once exposure is set, most (if not all) the global contrast and adjusting of shadows and highlights can be done with this one module. I understand that the module is still not ready and still has its issues with colours.
I can’t wait for it to be available in standard builds.
The only issue I have is related to the UI, the number of sliders make it a very large module and the graph (that I use in conjunction with the waveform scope) is not always visible as it scrolls away…
I understand that these small issues are not a priority yet!
Thanks for all the brilliant work!
Nicolas
(and please keep all the sliders available)
1 Like
yes, i still have this problem with the color cast on three different windows pc.
two of them are without color calibration, the monitors are only adjusted with test graphics
the version “darktable-5.1.0+766~gba2bc2f1e9-win64.exe” does not cause the problem for me.
recent macOS arm64 build:
darktable-5.1.0+704~g1acda16091_arm64.dmg
same comments as in Blender AgX in darktable (proof of concept) - #181
What are you using for a profile on those PC’s…the default windows srgb profile will show this… most other profiles won’t it seems or at least from the feedback above and my testing…
I just threw the latest version into a vanilla WIN11 sandbox VM and I don’t see it…I don’t see it at home on my calibrated system either…
I cycled through various combinations…
Just to be clear, are you talking about the Input Color Profile within Darktable? Or the profile in Windows Color Management here:
But more importantly, does it matter? Because if it’s not a problem for Sigmoid / Filmic, we shouldn’t need to make any changes specifically for AgX, right?
Plus, this was a new issue introduced after build 766.
So @kofa might be able to say what might have changed since v766, but he mentioned something about correcting things to the output profile…I wonder if you use something like srgb or very different from your monitor if something happens?? Maybe this is still off target…but I don’t have a wide gamut monitor so maybe that is why I don’t see this no idea… Under advanced is that is what is set as your default profile??
there is no software calibration on my two PCs. the colors and contrast were set directly on the monitors (test graphics).
on my laptop, an ancient profile was created with datacolor spider 5…, but this is no longer up-to-date.
the slider “with relative exposure” also seems to cut off at a certain point before the actual maximum white and possibly tear off a color channel.
I have only tested this on the laptop so far.
Confirmed. Since the same curve is applied per-channel, I’m baffled.
Export is not affected, though.
I’m just using the default sRGB profile:
I did install the driver that came with my monitor some years back, but I can’t remember now if it made any difference. I don’t think it ever came with its own ICC.
But if you use a different profile from that old one …ie the 2014 update from color.org I don’t think you will see that…
Thanks @kofa .
Since build 766 was fine, I can only suggest checking the code differences from build 790, which is when the issue first arose. But I’m afraid I can’t help more than that.
But let me know if you want me to do any more testing.
What is your monitor… because that is what should be in there if possible…in the first report of this that is what I saw that this profile caused or seemed to be the source of it… switching to another one fixed it… if you switch your display profile just in dt away from system and use srgb does it go away???