| Summary: | Raw importer broken. Not possible to revert changes. | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | falolaf |
| Component: | Plugin-DImg-RAW | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | caulier.gilles, sven.burmeister |
| Priority: | NOR | ||
| Version: | 1.8.0 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 1.9.0 | |
| Sentry Crash Report: | |||
| Attachments: |
Screenshot before EV correction.
Screenshot with 0.50 EV correction. Screenshot after lowering EV correction to 0.30. |
||
|
Description
falolaf
2011-01-30 11:35:05 UTC
(Taken from mail conversation in Digikam-users mailing list) Reinstalled kipi-plugins 1.7.0, still problems. Then resinstalled digiKam 1.7.0, all back to normal again. Tested with a new config for a different user. Still same problem. LibKdcraw: 1.1.0 Libraw: 0.11.3 Here's an image to test with(Canon CR2): http://www.adrive.com/public/1528c14240e0794c7a8e2fbc558241e6f517cae694a017247e2717534684a1d0.html Created attachment 56656 [details]
Screenshot before EV correction.
Created attachment 56657 [details]
Screenshot with 0.50 EV correction.
Created attachment 56658 [details]
Screenshot after lowering EV correction to 0.30.
I can confirm the bug. If one uses the EV number box to increase the level to 2.x the image gets brighter. If one then decreases it to say 0.9 the image gets even brighter. digiKam version 1.8.0 Exiv2 kann in JP2 speichern: Ja Exiv2 kann in JPEG speichern: Ja Exiv2 kann in PGF speichern: Ja Exiv2 kann in PNG speichern: Ja Exiv2 kann in TIFF speichern: Ja Exiv2 unterstützt XMP-Metadaten: Ja LibCImg: 130 LibClapack: internal library LibExiv2: 0.20 LibJPEG: 62 LibJasper: 1.900.1 LibKDE: 4.6.00 (4.6.0) LibKExiv2: 1.2.0 LibKdcraw: 1.2.0 LibLCMS: 119 LibLensFun: external shared library LibLqr: internal library LibPGF: 6.09.44 - internal library LibPNG: 1.4.4 LibQt: 4.7.1 LibRaw: 0.11.3 LibTIFF: LIBTIFF, Version 3.9.4 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc. Marble-Funktion: 0.11.0 (Stable Release) Parallelisiertes Entfernen von Mosaikmustern: Ja Datenbanktreiber: QSQLITE LibGphoto2: 2.4.10 LibKipi: 1.2.0 Marcel, i confirm this dysfunction. Very strange... Gilles Caulier I cannot reproduce this problem with White Balance tool which use the same Exposure Compensation algorithm. I suspect a problem in GUI of RAW Import post processing settings. Gilles Caulier It's not only the white balance correction that is affected. I had the same behaviour with brightness. /Anders I confirm. I suspect that post processing is applied to post processed image previously computed, and not the demosaiced image (both are stored in memory). Gilles Caulier Marcel, I just tested with 2.0.0, and i cannot reproduce the problem. So, it's only affect 1.x. Gilles Marcel,
If i save demosaiced image like this :
void RawImport::prepareEffect()
{
DImg postImg = d->previewWidget->demosaicedImage();
postImg.save("/home/gilles/demo.png", "PNG");
setFilter(dynamic_cast<DImgThreadedFilter*>(new RawPostProcessing(&postImg, this, rawDecodingSettings())));
}
before post-processing adjustements, I can confirm that RawPreview::RawPreviewPriv::demosaicedImg is corrupted after post-processing adjutments.
The image must still the same.
Look into the code, i cannot see how this DImg is modified by post processing...
Note : i also check if post-processing settings is fine, and all values used by post-processing code is fine.
Gilles
SVN commit 1218636 by cgilles: use a deep copy of demosaiced image to avoid cumulative post-processed changes BUGS: 264830 M +1 -1 rawpostprocessing.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1218636 |