Project

General

Profile

Bug #11548

Output Image Seems Darker

Added by Joe Giampaoli about 2 years ago. Updated about 2 years ago.

Status:
Triaged
Priority:
Low
Assignee:
-
Category:
Darkroom
Target version:
Start date:
03/22/2017
Due date:
% Done:

20%

Affected Version:
2.2.3
System:
all
bitness:
64-bit
hardware architecture:
amd64/x86

Description

Don't know if it's me or what but I believe that my output image is darker than what I see in DT, just noticed this...

Attaching DNG with xmp and screenshots of what I see...

Thanks!

CRW_2663.DNG.xmp (10.2 KB) Joe Giampaoli, 03/22/2017 05:58 AM

Screenshot - 03212017 - 09_53_11 PM.png (661 KB) Joe Giampaoli, 03/22/2017 05:59 AM

Screenshot - 03212017 - 09_53_35 PM.png (596 KB) Joe Giampaoli, 03/22/2017 05:59 AM

CRW_2663.DNG (8.11 MB) Joe Giampaoli, 03/22/2017 06:00 AM

Screenshot_2017-05-02_09-25-41.png - Initial preview (image verson 12, cropping enabled) (2.38 MB) David Houlder, 05/02/2017 07:35 AM

Screenshot_2017-05-02_09-26-15.png - After zooming in one step (image verson 12, cropping enabled) (2.58 MB) David Houlder, 05/02/2017 07:35 AM

Screenshot_2017-05-02_09-26-45.png - After zooming back out one step (image verson 12, cropping enabled) (2.32 MB) David Houlder, 05/02/2017 07:36 AM

IMG_6403_11.CR2.xmp (76.6 KB) David Houlder, 05/02/2017 07:55 AM

IMG_6403_12.CR2.xmp (84.3 KB) David Houlder, 05/02/2017 07:55 AM

History

#1 Updated by Joe Giampaoli about 2 years ago

So yes, I imported the exported file to DT again and the levels are shifted slightly to the left where in the original DNG I am just about clipping my whites. Seems it's one of the modules because I tested with another image and it looked just about identical.

#2 Updated by Ulrich Pegelow about 2 years ago

  • Status changed from New to Confirmed
  • % Done changed from 0 to 10

Looks like global tonemapping is the culprit.

#3 Updated by Joe Giampaoli about 2 years ago

Ulrich Pegelow wrote:

Looks like global tonemapping is the culprit.

Correct, it seems it exports without the tonemapping values, I tested with another image without tonemapping and it exported equal to what I see in DT.

Not 100% sure if it is that precise module, could be a combination of it with other(s) in the pipeline?

#4 Updated by Ulrich Pegelow about 2 years ago

Not 100% sure if it is that precise module, could be a combination of it with other(s) in the pipeline?

The drago operator in global tonemap has a peculiarity: it needs as a processing input the absolute maximum L value of the image. During export it calculates this Lmax value by considering the corresponding buffer of the export pixelpipe, i.e. the image with full resolution. For various reasons this is not possible for the "full" pixelpipe of the center view in the darkroom. Instead the maximum L value is calculated from the scaled-down preview pixelpipe. Typically this delivers a sufficiently good estimation.

Now in the case of your image we have the situation that there is a high number of very small specular highlights: very small spots with high L values surrounded by not so bright areas. When scaled down in the preview pixelpipe these highlight spots get averaged out while in the export pixelpipe each and every pixel counts. Thus the difference in output. Any other module that enhances/reduces this situation, e.g. by pushing the highlights, will influence the difference between darkroom view and exported image.

I fear that there is no easy way out of this problem. One solution could be replacing the automatic detection of L_max by a module parameter that the user needs to set manually, but it might be quite inconvenient to select the right setting of that parameter...

#5 Updated by Joe Giampaoli about 2 years ago

OK, I really appreciate the detailed response and info! I'll just be extra careful with my levels in these "rare" cases, because this is for sure the first time I have ever seen this after hundreds of edits, so next time I come across this similarity which might be in a good while I'll remember this.

Thanks!

#6 Updated by Ulrich Pegelow about 2 years ago

  • % Done changed from 10 to 20
  • System changed from Debian to all
  • Status changed from Confirmed to Triaged
  • Category changed from General to Darkroom

The devs will need to consider how to deal with that topic. Ideally this issue should be fixed as we certainly want darktable's output look the same as the darkroom view.

I have two alternative ideas:

  1. Apply some gaussian blur to a temporary copy of the image before detecting Lmax. The radius of the blur could be adjusted according to the scale ratio of the image so that the preview buffer gets a much lower blur than the export buffer. Extreme values of isolated pixels get averaged out this way.
  2. Use a certain percentile of the image histogram to detect Lmax. This way a few pixels with extreme values wouldn't hurt and make the module behave in a more robust way.

#7 Updated by David Houlder about 2 years ago

Joe: What happens if you switch off "crop and rotate"? I'm experiencing a similar problem on one particular image (see attached IMG_6403_11.CR2.xmp) in dt 2.2.4. I'm using global tonemap (drago) and the preview image and the exported image look significantly different. In my case though, the output image is noticeably lighter or more contrasty. However, if I switch off "crop and rotate" and export the image again, that exported image is a pretty close match to its preview.

In another version of that same image, also using global tonemap, just zooming in and zooming back out again changes the preview noticeably (image version 12, dt 2.2.4, screenshots attached). Again, switching off "crop and rotate" restores normal behaviour (zoom-in followed by zoom-out behaves normally).

I'm happy to supply the raw file if required - it's too big for the redmine file upload.

#8 Updated by Joe Giampaoli about 2 years ago

David Houlder wrote:

Joe: What happens if you switch off "crop and rotate"? I'm experiencing a similar problem on one particular image (see attached IMG_6403_11.CR2.xmp) in dt 2.2.4. I'm using global tonemap (drago) and the preview image and the exported image look significantly different. In my case though, the output image is noticeably lighter or more contrasty. However, if I switch off "crop and rotate" and export the image again, that exported image is a pretty close match to its preview.

David, apparently I still have the same issue with crop and rotate switched off. I have noticed that this bug seems to affect only RAW files, DNG in my case. Since I sometimes do some processing in HDR-Luminance, I export to a 32 bit-float tiff or sometimes to exr, do some extreme tonemapping there and then re-import my file to DT, then this issue doesn't seem to apply, even if I add extra tonemapping in DT (I know, that sounds overkill). Also have noticed it doesn't happen with other normal 8 bit images, so it does seem to be a more of a RAW specific issue.

That's an awesome shot by the way! :)

Cheers and thanks for following up with your report...

#9 Updated by David Houlder about 2 years ago

Joe Giampaoli wrote:

David, apparently I still have the same issue with crop and rotate switched off.

OK - thanks for the feedback. Maybe I've encountered a different bug. I will wait for advice from Ulrich.

That's an awesome shot by the way! :)

Thanks (Tarkine coast, Tasmania (Australia))

#10 Updated by Ulrich Pegelow about 2 years ago

In another version of that same image, also using global tonemap, just zooming in and zooming back out again changes the preview noticeably

That sounds like bug #11497. It's an unrelated problem to this ticket and occurs with several modules including global tonemap, mostly on systems with OpenCL. darktable 2.2.x is affected; the issue has been fixed in current master.

Also available in: Atom PDF