Open franckmee opened 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.
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
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
btw: scaling down the export (e.g. 90%) gives a proper result as long as high quality resampling isn't activated
@franckmee would you share the raw file plus xmp to investigate? EDIT : Sorry, got both.
@MStraeten you're on master I guess?
@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.
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)
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 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,
as @jenshannoschwalm suggested, try to use diffuse&sharpen instead - might need some time to find an appropriate default setting, but less hassle afterwards …
quite interesting side effect: when ISO 12646 Mode is enabled - the effect is visible in the darkroom main edit frame
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.
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
Expected behavior
The exported file should look like the preview, however cropped and whatever the export size
Logfile | Screenshot | Screencast
Darktable preview
Exported file
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