Darktable 4.4 Released

[maltmoose]

Just tested my style with the new build and did a few tweaks to make sure it works with the new version. All good but one thing is driving me nuts!

Input Color Profile!

It appears that regardless of what my profile is set to or even if when darktable loads its default profile the Input color profile can be be different requiring it to be reset even after applying your profile or loading a fresh file.

On different cameras its also different. sometimes it loads srgb or standard color matrix when it should be embeded matrix. often it loads linear req709 when linear req 2020 should be used. Anyway it seems inconsistent and infuriating, shouldnt need to have to mess with this. Sure i can reset it but im not doing this all the time, must be a bug or compatibility issue.

Anyone else seeing this issue?

 

[Kameratrollet]

Just tested my style with the new build and did a few tweaks to make sure it works with the new version. All good but one thing is driving me nuts!

Input Color Profile!

It appears that regardless of what my profile is set to or even if when darktable loads its default profile the Input color profile can be be different requiring it to be reset even after applying your profile or loading a fresh file.

On different cameras its also different. sometimes it loads srgb or standard color matrix when it should be embeded matrix. often it loads linear req709 when linear req 2020 should be used. Anyway it seems inconsistent and infuriating, shouldnt need to have to mess with this. Sure i can reset it but im not doing this all the time, must be a bug or compatibility issue.

Anyone else seeing this issue?

Create an issue here https://github.com/darktable-org/darktable/issues

Don't forget affected raw files and print screens.

With my 1Ds I got the same and I created a preset so that the standard profile always was loaded.

 

[maltmoose]

Just tested my style with the new build and did a few tweaks to make sure it works with the new version. All good but one thing is driving me nuts!

Input Color Profile!

It appears that regardless of what my profile is set to or even if when darktable loads its default profile the Input color profile can be be different requiring it to be reset even after applying your profile or loading a fresh file.

On different cameras its also different. sometimes it loads srgb or standard color matrix when it should be embeded matrix. often it loads linear req709 when linear req 2020 should be used. Anyway it seems inconsistent and infuriating, shouldnt need to have to mess with this. Sure i can reset it but im not doing this all the time, must be a bug or compatibility issue.

Anyone else seeing this issue?

Create an issue here https://github.com/darktable-org/darktable/issues

Don't forget affected raw files and print screens.

With my 1Ds I got the same and I created a preset so that the standard profile always was loaded.

I was just going to do a ticket and share a link to a couple of raws in their own directory and i did a final test and could not replicate the issue!

Found the issue again in a full directory of images. I deleted the xmp files in that directory and the problem was fixed. Not sure what the issue is in the xmp but dont have time to track it down further than that at the minute.

Quick edit, just found the issue. The issue is created by having 2 similar named xmp files one for the dng and one for a jpeg.

e.g.

GR12345.dng.xmp (for the raw)

GR12345.xmp (for the jpeg)

If you delete xmp GR12345.xmp the issue is fixed and the input color profile is consistent.

 

[maltmoose]

Just tested my style with the new build and did a few tweaks to make sure it works with the new version. All good but one thing is driving me nuts!

Input Color Profile!

It appears that regardless of what my profile is set to or even if when darktable loads its default profile the Input color profile can be be different requiring it to be reset even after applying your profile or loading a fresh file.

On different cameras its also different. sometimes it loads srgb or standard color matrix when it should be embeded matrix. often it loads linear req709 when linear req 2020 should be used. Anyway it seems inconsistent and infuriating, shouldnt need to have to mess with this. Sure i can reset it but im not doing this all the time, must be a bug or compatibility issue.

Anyone else seeing this issue?

Create an issue here https://github.com/darktable-org/darktable/issues

Don't forget affected raw files and print screens.

With my 1Ds I got the same and I created a preset so that the standard profile always was loaded.

I was just going to do a ticket and share a link to a couple of raws in their own directory and i did a final test and could not replicate the issue!

Found the issue again in a full directory of images. I deleted the xmp files in that directory and the problem was fixed. Not sure what the issue is in the xmp but dont have time to track it down further than that at the minute.

Quick edit, just found the issue. The issue is created by having 2 similar named xmp files one for the dng and one for a jpeg.

e.g.

GR12345.dng.xmp (for the raw)

GR12345.xmp (for the jpeg)

If you delete xmp GR12345.xmp the issue is fixed and the input color profile is consistent.

Just thought i'd update that this bug has been squashed already in the nightly build.

darktable working well, speed increases are welcome.


Processed in darktable.

 

[bastibe]

Just tested my style with the new build and did a few tweaks to make sure it works with the new version. All good but one thing is driving me nuts!

Input Color Profile!

It appears that regardless of what my profile is set to or even if when darktable loads its default profile the Input color profile can be be different requiring it to be reset even after applying your profile or loading a fresh file.

On different cameras its also different. sometimes it loads srgb or standard color matrix when it should be embeded matrix. often it loads linear req709 when linear req 2020 should be used. Anyway it seems inconsistent and infuriating, shouldnt need to have to mess with this. Sure i can reset it but im not doing this all the time, must be a bug or compatibility issue.

Anyone else seeing this issue?

I have this issue if I open an image in Capture One, before opening it in Darktable. What happens is that C1 creates an XMP sidecar file, which contains an input profile, and darktable imports that XMP and applied a bogus input profile. You get a little status message to this effect as well ("imported settings" or something like that).

I wish there was an option for importing only metadata from other editors.

I've created a simple style that resets the input profile and apply it to an entire film roll whenever this happens. Annoying, but at least it's easy to fix. (Once you know the reason. Which took me way too long, back when it first happened).

 

[Henry Richardson]

https://github.com/darktable-org/darktable/releases/tag/release-4.4.1

Bug fixes.

 

[RidgeRoadPost]

As a film colourist and photographer for over 20 years, I welcome the scene referred workflow. Most raw editing programs like Lightroom or Capture One are display referred which means they automatically apply a gamma curve to your image to make it look similar to your J-Peg preview that’s imbedded in your raw file. When shooting high dynamic range scenes like a landscape at sunrise you can loose critical shadow and highlight detail from this enforced gamma correction which you then have to try and correct in the software. A scene referred workflow does not apply this curve. If you are familiar with video capture at all, people often shoot in a log format which is a scene referred colour and gamma space. This allows you to take advantage of the full range and tone the camera captures. You then transform it into a display referred space like Rec.709 or sRGB so that it looks correct on your viewing medium like your monitor. This practice gives you more control over the range of tones your camera is able to capture.
Many people are happy with the restrictions imposed with a display referred workflow but for those who want the most control of their image, a scene referred workflow is by far the better way to process your image. It may not appeal to many who want a simple solution, but for fine art photographers who want full control of their image, Datktable is a great option. It’s just too bad it can be buggy.
here is an article which explains the difference between a scene referred and display referred workflow. https://docs.darktable.org/usermanual/development/en/overview/workflow/process/

 

[pdqgp]

Cleaning this thread up a bit. Let's go back to our respective corners and come back editing and productive please.

 

[charlyw64]

You then transform it into a display referred space like Rec.709 or sRGB so that it looks correct on your viewing medium like your monitor. This practice gives you more control over the range of tones your camera is able to capture.

I stil think that this only true if you can control the display media. Which for photography you can't and thus the scene referenced workflow only adds additional cruft to the workflow, especially if you print because then you have to keep the restrictions of the output media in view and forget all that large dynamic range - you need to grow balls to cut off that what you can not use unless you go for the hapless HDR tonemapped to death look.

Many people are happy with the restrictions imposed with a display referred workflow

You haven't understood the workflow of the normal editing programs at all... They don't differ from the scene referenced except they remove the artificial distinction between editing and manipulation colorspace which the scene referenced workflow introduces and in the end the result bear this - I haven't seen a single well processed image from darktable, not a single one!

 

[sstb]

I haven't seen a single well processed image from darktable, not a single one!

Really?
There are people who are very good with Darktable.

 

[charlyw64]

I haven't seen a single well processed image from darktable, not a single one!

Really?
There are people who are very good with Darktable.

And yet I have only seen horrendously looking half baked color graded and tone mapped to death results from any of them... The problem with the approach is that the choice of scene referenced editing makes edits like sharpening or color balancing virtually impossible to gauge in their effect because they are applied before the necessary transistion into a usable colorspace happens. The scene referenced colorspace is not well defined and falls apart on many of the possible edits and thus the results are more random and impossible to adjust correctly. That's why the filmic chimera has several "rescue" modes to try to salvage what has gone wrong in the previous edits and the haphazard transformation applied by that completely ill conceived mess of a filter.

Why do I single out sharpening (a rather mundane task) in this context? Because sharpening needs to be applied in different strengths depending on the display brightness of the final image - not the arbitrary scene. Virtually every one of the shown darktable edits suffers from horrendous sharpening halos, even if the "halo reduction" was applied (which has dire consequences on the consistency of the sharpening).

 

[sstb]

I don't have the knowledge to really have a say here. But I find the topic interesting because I have considered using Darktable.
But I don't want to use garbage either.
I'm just surprised that you can't find any complaints on the internet about the subject and that there are people who I think develop really good photos (and obviously professionally, e.g. Shane Milton, Boris Hajdukovic, etc.). They should notice these problems?!

Edit:

Just discovered but not yet seen:

Answers to @MiltonPhoto's rant with darktable's 4.0 new features (Aurélien PIERRE)

The original video can no longer be found on YouTube and Shane Milton seems to be using Darktable (again) (instead of CaptureOne).

 

[bastibe]

But I don't want to use garbage either.

Don't worry. There are always naysayers. Charlyw64 is well-known around here to dislike darktable.

But there are plenty of people doing great work in darktable. At the end of the day, the quality of your results is defined by the skill of the operator, not the brand of their tools. Darktable is an unusual program in some respects, such that skills from Lightroom don't translate as easily as they do for some other programs. Perhaps that makes some people quick to dismiss it.

At any rate, most of Darktable's community hangs out at discuss.pixls.us.

 

[charlyw64]

I don't have the knowledge to really have a say here. But I find the topic interesting because I have considered using Darktable.
But I don't want to use garbage either.
I'm just surprised that you can't find any complaints on the internet about the subject and that there are people who I think develop really good photos (and obviously professionally, e.g. Shane Milton, Boris Hajdukovic, etc.). They should notice these problems?!

Edit:

Just discovered but not yet seen:

Answers to @MiltonPhoto's rant with darktable's 4.0 new features (Aurélien PIERRE)

You do know that Aurelien Pierre shortly after this video has left the Darktable development team (because they went too extreme on the scene referenced push - and he basically was the only one that really pushed that for a long long time) and his whole reasoning in favour of scene referenced workflow falls apart if you don't want to produce color graded (like in video) HDR images that can only be properly displayed on HDR displays and nothing else. The moment you have to deal with print output or "normal" sRGB/P3/AdobeRGB displays then scene referenced workflow has no benefits and only drawbacks because for the most part of your editing workflow you are performing your edits flying blind...

 

[geni1105]

You do know that Aurelien Pierre shortly after this video has left the Darktable development team (because they went too extreme on the scene referenced push

That’s not true. He left because he was in disagreement about the direction of the UI.

His fork „Ansel“ fully embraces the scene-referred workflow, and he continues to develop it, now with the 7th version of his „Filmic“ module.

 

[Henry Richardson]

You do know that Aurelien Pierre shortly after this video has left the Darktable development team (because they went too extreme on the scene referenced push

That’s not true. He left because he was in disagreement about the direction of the UI.
His fork „Ansel“ fully embraces the scene-referred workflow, and he continues to develop it, now with the 7th version of his „Filmic“ module.

If you do not like filmic then use base curve.

2022: darktable filmic & base curve now on equal footing

https://www.dpreview.com/forums/post/65943665

There is a recent post by Aurélien Pierre. He is the person who has spent the last few years creating the new scene-referred workflow (using the filmic module) in darktable. He says now that display-referred (using the base curve module) has also been fixed because of all the changes to darktable. So now you can choose whichever one you prefer and still be able to get good results. Here is his post and thread:

https://discuss.pixls.us/t/aurelien-said-basecurve-is-bad/29055

Here is the bit at the bottom which sort of summarizes it:

So now, base curve is color-safe, as far as color profiles and chromatic adaptation are concerned.

So, as of darktable 3.0 and later, base curve or filmic achieve the same goal mostly the same way (you get those chromaticity-preserving norms in base curve too), the only difference being in the GUI and the ability to scale the curve look to the input dynamic range.

So filmic is essentially a base curve with a different GUI. And a sh!tload of other features because just applying a tone curve is not nearly enough to get a smooth highlights roll-off. But, now, filmic or base curve is pretty much a matter of taste, and whether you keep a pipeline normalized between [0;1] or not.

By the way, a new, big update of darktable normally happens around Christmas so probably soon there will be one.

 

[charlyw64]

So, as of darktable 3.0 and later, base curve or filmic achieve the same goal mostly the same way (you get those chromaticity-preserving norms in base curve too), the only difference being in the GUI and the ability to scale the curve look to the input dynamic range.

So filmic is essentially a base curve with a different GUI. And a sh!tload of other features because just applying a tone curve is not nearly enough to get a smooth highlights roll-off. But, now, filmic or base curve is pretty much a matter of taste, and whether you keep a pipeline normalized between [0;1] or not.

Except that many of the required modules you must apply later in the pipeline have been deprecated while that was not true and partly have been removed. So while technically they may have made that filmic abomination less relevant, they de-facto have still made it mandatory.

 

[geni1105]

I was not arguing against Filmic, rather commented on the misinformation that Aurelien left because he would have objected against the scene-referred workflow.

Anyway, you also have Sigmoid now, in addition to Filmic and Base Curve.

 

[sstb]

I have seen that there are various videos on the subject on YouTube.

[ENG] What does Filmic do ?

Why I use Scene Referred Workflow in darktable 3.6.1 (vs Display Referred Workflow)!

 

[charlyw64]

I have seen that there are various videos on the subject on YouTube.

Plenty and not a single one can explain how to consistently edit images doing so - every image is treated differently and has different look in the end.