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…
Your pink areas are most likely (>99.9%) simply blown-out sensor data, you can read in detail in the manual what this is about and how the algos work.
In maybe the rest (<0.1%) of all images we can have some camera data wrongfully interpreted (or wrongfully written by the camera firmware). We call this wrong whitepoint. That sometimes needs some tweaking …
Is it then, perhaps just a case of finding the button which switches the pink color off?
(Again, my confusion stems from the fact that Affinity and Lightroom do not show this pink color, and for example, my camera does have a setting to turn it off.)
The pink color is the result of trying to white balance patches in the image where clipping of the highlights occur. Other software performs extra processing to negate pink highlights, but dakrtble does not.
One of the new highlight reconstructions should solve it, or just select “clip highlights” and let them clip.
