I have problems with overexposed and underexposed RAW images. For example, the highlights are displayed in pink. Even when I generate an HDR, the highlights are pink. In other programs like Lightroom and Affinity Photo I have no problems. My camera is a Panasonic Lumix DMC G81. In Lighttable, the pictures are still displayed reasonably. If I open the image in Darkroom, the errors occur. If I export the images as EXR, Darktable saves the pink highlights in the image. Here is a link to a RAW exposure series of mine and a screenshot of how Darktable displays the images.
It seems to be a problem with the Panasonic camera.
I just tested it with RAW images from my Samsung S9+ phone and everything seems to be OK. I also overexposed there, but there are no pink highlights.
Some of the cast may be caused by https://github.com/darktable-org/darktable/issues/10008.
For the highlights, either turn on highlight reconstruction (as suggested by @paperdigits above), or deal with it in filmic (if you are starting out with darktable, Iâd suggest the former; in fact, even with years of darktable experience, thatâs what I use, in LCh mode â you can add an auto-applied preset, so itâs always enabled when you open a raw file).
In the image thatâs overexposed by 3EV (I guess to bring out the shadows for your exposure-bracketed HDR composition), you have a very heavily blown R channel:
I was able to get rid of the purple using highlight recovery and filmic, but I had to adjust the threshold of LCh recovery; see attached sidecar (note: Iâm on the âmasterâ branch, the development version thatâll become darktable 3.8).
Hmm, maybe the red channel is not clipped in the raw file? Disabling white balance (which applies a boost over 2 to the red channel) removes the raw overexposed indication tool.
RawTherapee does not exhibit the purple highlights issue, but they also clip whites at a lower value:
for ISO 100, RawTherapee uses a white level of 2300, if I understand correctly (https://github.com/Beep6581/RawTherapee/blob/dev/rtengine/camconst.json#L2450).
Thank you very much for taking care of my problem.
@ paperdigits
Highlight Reconstruction doesnât fix the problem, unfortunately.
@kofa
Itâs an exposure bracketing that is needed for an HDR image. As I said, in Lightroom, which I have been using for years, the images are displayed normally. Affinity Photo too. I think itâs more my camera which is maybe misinterpreted by darktable. I found something on the internet where someone had this problem with their Canon 7D: https://github.com/darktable-org/darktable/issues/6548
For testing I took a RAW picture with my smartphone where I also overexposed extremely. Everything was displayed correctly by darktable and nothing was pink in the highlights.
If there is a problem with with black point settings, you can adjust that within darktable.
I have the black point issue with my old Canon D60 camera when the white balance is set manually (which is most of my photos, as I used a grey card back then, as its in-camera white balance was often a good bit off).
My workaround, at least until the next version of darktable (or the one after or whenever itâs fixed), was to run exiftool (and dcraw -i -v might also work) on a good number of raw files (especially daylight), note the black setting values, and set them accordingly. Then, I made a preset of that and have it auto-apply to all of the D60 files. Itâs not 100% perfect (as the values vary a slight bit sometimes), but itâs 99% of the way there for most of my files and totally better than what darktable was giving me by default.
For your one file, run exiftool on the file, look at the black point, and make sure it matches inside darktable.
Ideally, darktable would just figure this out itself (and it usually does for most files), but if your camera also has this same problem, then manually checking and setting is the workaround fix for now. (Itâs probably similar or same black points for all the rest of the raw files from your camera too, so you could work around this in a similar manner without having to manually check and set for future photos.)
Related issues & PRs to a few black point issues in various cameras:
Another way of dealing with this (for now) is to convert the raw file (RW2) to DNG using the free Adobe DNG converter.
Just tested this with your P1170148.RW2 file and the resulting DNG file has the âraw black/white point set to 143 (instead of 128 in the equivalent RW2 file) and white point 2600 (instead of 4095 in the equivalent RW2 file).
Note: I convert all my raw files to DNG as I have decided to do so since I begun to shoot in raw.
My reasons are many; some of them are: different cameras, different systems, one unique format and the possibility to open the files in any software, old, or new, that can open DNG files, etcâŚ
@DDHarriman : many open-source developers will tell you not to use DNG, if it can be avoided. (False statement regarding data loss redacted) That said, there are also others who donât worry too much about the format: How to convert raw formats to DNG - RawPedia
Of course itâs a question of choices, and mine was to embrace the DNG format from the start.
Another possible solution to these âpink issuesâ is to shoot with the base iso of the camera (200 iso) and not the extended iso (100 iso), as it looks this situation appears on Panasonic cameras in Darktable, mostly, with files shot with 100 (extended) iso as the ones made available here by Benjamin Berger.
I downloaded P1170150.RW2 and opened it in rawproc with the default processing to a linear RGB, and the âpinkâ is definitely the result of blowing the snot out of the highlights in the camera. The data piles up at the respective channel maximums, then those piles are pulled apart by the white balance - TaDa! Pink! (or more specifically, magenta). My surmise is that, thinking each image stands on its own, Lightroom is applying aggressive highlight reconstruction to âmake niceâ, darktable is just spitting in your eye for egregious overexposureâŚ
Thing is, youâre using these images to make an amalgam HDR, so the important data in this particular capture are the lowest values, and the âpinkâ regions will be supplied by 144, 145, the lower exposed images in the sequence. The over-exposure in the upper images should be of no consequence to the amalgam.
Edit: I downloaded the raws and tried to do a hdrmerge hdr, and indeed, the overexposed images polluted the amalgam dng with âpink-nessâ. So, you at least need to drive the highlights in these images to white.
If weâre talking about Bayer sensor based cameras, this is just pure FUD, please stop perpetuating it. Any issue related to this is pure user error in choosing the âlossy compressionâ option in the tool.
In 2023, itâs apparently on by default, but the slider needs a manual adjustment. Why is that? If the software can detect pink areas and paint them pink, surely the software could also then detect what slider setting to automatically apply in order to remove them?
From a beginnerâs point of view, this seems like unnecessary complexity which no other software has. What is the advantage of forcing the user to manually tweak this before getting started with that you really want to do?
Itâs not painting pink. Your green channel is blown hence the pink. You can show that with the raw overexposure indicator. This can also happen when the raw white point is not correct. When that happens the HLR might need a tweak. All things to confirm. If you want to post a file we can take a look. Usually notbing needs to be doneâŚ