darktable-org / darktable

darktable is an open source photography workflow application and raw developer
https://www.darktable.org
GNU General Public License v3.0
9.88k stars 1.15k forks source link

Crop makes image areas burned-white (haze removal) #17358

Open franckmee opened 3 months ago

franckmee commented 3 months ago

Describe the bug

Here is a bug I never had on any picture before : my spider had lots of white-washed areas that did NOT appear on preview.

Trying to work around the problem, I tried quitting&restarting and modifying export color profile with no luck. I then tried de-activating modules. De-activating cropping resolved the issue: the uncropped 4000px (my usual export size) image looks like it did in the preview. Re-activating the crop tool produces the burnt areas again.

The export size also appears to play a part in this: both full size (cropped or not) pictures have some burnt areas, cropped 4000px picture has huge burnt areas, uncropped 4000px looks like the preview, uncropped 2000px looks just a bit lighter than the preview, cropped 2000px looks like the preview. So it seems there's actually a weird relationship between crop size and export size.

The joined file contains original raw and xmp files, a screenshot of the Darktable preview, and exports at 2000px, 4000px and full size of both the original frame and the cropped one.

Steps to reproduce

  1. Load the provided picture with the provided parameters.
  2. Export the picture, 4000 px wide.
  3. Compare exported JPEG to preview.

Expected behavior

The exported file should look like the preview, however cropped and whatever the export size

Logfile | Screenshot | Screencast

Darktable preview Darktable_preview

Exported file DSC08022_cropped_4000

Log file from darktable -d common araignee_common.log

A zip file with original raw and xmp files is available here

Commit

No response

Where did you obtain darktable from?

downloaded from www.darktable.org

darktable version

4.8.0

What OS are you using?

Linux

What is the version of your OS?

Linux Mint 21.3 Cinnamon

Describe your system?

No response

Are you using OpenCL GPU in darktable?

Yes

If yes, what is the GPU card and driver?

NVIDIA GeForce GTX 1060 with Max-Q Design, 6 Go, driver 535.183.01

Please provide additional context if applicable. You can attach files too, but might need to rename to .txt or .zip

No response

ptilopteri commented 3 months ago

and you probably have your "preview" set to imbedded jpg which is produced with proprietary methods not available to dt developers.

set "preview" to "use raw file instead of imbedded jpg" and see what appears.

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc

MStraeten commented 3 months ago

reproduceable on mac @ptilopteri : darkroom doesn't display the embedded jpg but the processed image. even switching to high quality processing gives a proper result in darkroom but that blown areas in the exported jpg after activating crop

MStraeten commented 3 months ago

btw: scaling down the export (e.g. 90%) gives a proper result as long as high quality resampling isn't activated

jenshannoschwalm commented 3 months ago

@franckmee would you share the raw file plus xmp to investigate? EDIT : Sorry, got both.

@MStraeten you're on master I guess?

jenshannoschwalm commented 3 months ago

@franckmee the bad boy is our old friend "haze removal". It calculates some intermediate data from all available areas and does some maths using this intermediate stuff. If other parts of the image are almost black with the almost-white spider this fails. You may even see "inconsistent .." mesaages appearing.

So, a restriction of that module which is pretty difficult to fix due to the algorithm. BTW i don't understand why you want to use that module here, there is no haze :-) Diffuse&sharpen might be better suited.

Overall, for me not a bug.

MStraeten commented 3 months ago

yes I’m on master

I’d expect that at least when using the high quality processing the output in darkroom shouldn’t differ from the exported image. Even this might be an edge case this raises the question if there’s a need for a wysiwyg preview mode (like softproof)

jenshannoschwalm commented 3 months ago

I’d expect that at least when using the high quality processing the output in darkroom shouldn’t differ from the exported image.

The problem is: the mentioned intermediate step happens in the preview pipe iirc.

I looked up that module some time ago when checking #16925 and there seems to be no immediate fix. You wanna have a look?

franckmee commented 3 months ago

@franckmee the bad boy is our old friend "haze removal". It calculates some intermediate data from all available areas and does some maths using this intermediate stuff. If other parts of the image are almost black with the almost-white spider this fails. You may even see "inconsistent .." mesaages appearing.

Ok, thanks for the tip and teh explanation! I still think preview should match the export, but I do understand this module has an unusual behavior that make things complicated.

BTW i don't understand why you want to use that module here, there is no haze :-)

I take LOTS of pics in which atmospheric haze is a problem, so it's actually active in my default presets. For this particular image it is indeed not needed! :)

Thanks to everyone who took time to answer,

MStraeten commented 3 months ago

as @jenshannoschwalm suggested, try to use diffuse&sharpen instead - might need some time to find an appropriate default setting, but less hassle afterwards …

MStraeten commented 3 months ago

quite interesting side effect: when ISO 12646 Mode is enabled - the effect is visible in the darkroom main edit frame

github-actions[bot] commented 1 month ago

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.