Bug 264830 - Raw importer broken. Not possible to revert changes.
Summary: Raw importer broken. Not possible to revert changes.
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-DImg-RAW (show other bugs)
Version: 1.8.0
Platform: Compiled Sources Linux
: NOR major
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-01-30 11:35 UTC by falolaf
Modified: 2012-06-27 10:32 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 1.9.0


Attachments
Screenshot before EV correction. (143.86 KB, image/jpeg)
2011-01-30 12:06 UTC, falolaf
Details
Screenshot with 0.50 EV correction. (136.49 KB, image/jpeg)
2011-01-30 12:07 UTC, falolaf
Details
Screenshot after lowering EV correction to 0.30. (121.22 KB, image/jpeg)
2011-01-30 12:08 UTC, falolaf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description falolaf 2011-01-30 11:35:05 UTC
Version:           1.8.0 (using KDE 4.5.5) 
OS:                Linux

When importing raw images and e.g. increase EV and then decide the corrections was wrong, lowering EV doens't effect the original image. Only possibility is to revert to original and start over again.

Reproducible: Always

Steps to Reproduce:
(Taken from mail conversation in Digikam-users mailing list)
However, I hit another snag when developing RAW files (Sony ARW in my case):
it usedd to be that if I added an EV correction, and then decided it was too
much, the new (lower) correction was applied to the original RAW output (i.e.
an image update after having lowered an EV correction was less luminous);
with the 1.8.0 version, the second lower correction is applied to the already
corrected image => severe over correction and no way to get back, except
through an update in the RAW tab
(say I start with a correction of +.3, then decide +.2 would have been better:
in <=1.7.0 I ended up with a correction of +.2,
in 1.8.0 I end up with a correction of +.5...)



Expected Results:  
Have the original images as base for all corrections.
Comment 1 falolaf 2011-01-30 11:38:03 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
Comment 2 falolaf 2011-01-30 11:59:30 UTC
Here's an image to test with(Canon CR2):
http://www.adrive.com/public/1528c14240e0794c7a8e2fbc558241e6f517cae694a017247e2717534684a1d0.html
Comment 3 falolaf 2011-01-30 12:06:54 UTC
Created attachment 56656 [details]
Screenshot before EV correction.
Comment 4 falolaf 2011-01-30 12:07:33 UTC
Created attachment 56657 [details]
Screenshot with 0.50 EV correction.
Comment 5 falolaf 2011-01-30 12:08:09 UTC
Created attachment 56658 [details]
Screenshot after lowering EV correction to 0.30.
Comment 6 S. Burmeister 2011-01-30 12:13:22 UTC
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
Comment 7 caulier.gilles 2011-02-03 09:43:29 UTC
Marcel, i confirm this dysfunction.

Very strange...

Gilles Caulier
Comment 8 caulier.gilles 2011-02-03 09:47:24 UTC
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
Comment 9 falolaf 2011-02-03 10:30:08 UTC
It's not only the white balance correction that is affected. I had the same behaviour with brightness.

/Anders
Comment 10 caulier.gilles 2011-02-03 11:03:55 UTC
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
Comment 11 caulier.gilles 2011-02-03 11:59:17 UTC
Marcel,

I just tested with 2.0.0, and i cannot reproduce the problem.

So, it's only affect 1.x.

Gilles
Comment 12 caulier.gilles 2011-02-03 12:16:44 UTC
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
Comment 13 caulier.gilles 2011-02-03 12:44:10 UTC
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