Bug 211423

Summary: Raw import intensity curve is not restored
Product: [Applications] digikam Reporter: Johannes Wienke <languitar>
Component: Plugin-RawImport-NativeAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles
Priority: NOR    
Version: 1.0.0   
Target Milestone: ---   
Platform: Ubuntu   
OS: Unspecified   
Latest Commit: Version Fixed In: 1.0.0
Sentry Crash Report:

Description Johannes Wienke 2009-10-22 11:28:25 UTC
Version:           1.0.0-beta6 (rev.: 1038897) (using KDE 4.3.2)
Installed from:    Ubuntu Packages

When importing a raw file using the advanced import dialog, everything is restored from the previous import action except the intensity curve.
Comment 1 Johannes Wienke 2009-10-22 11:28:58 UTC
Is this RAW files management or image editor? ;)
Comment 3 Andi Clemens 2009-10-22 12:05:56 UTC
Maybe an orphaned or invalid read config var again? This is why I started to use variables instead of hardcoded text,
Comment 4 Johannes Wienke 2009-10-22 17:23:11 UTC
Ok, I found the problem. After some fixes the raw curve points are restored correctly from the rc file but this is not the real problem.

What happens is that:
1. curve is restored for the widget
2. the image is set in CurvesWidget::updateData
3. this method creates new curves depending on if the image is 16 bit or not
=> restored curve is reset

Why does the curve need to know whether the image is 16 bit or not? If this wasn't necessary, then this reset won't be needed. Moreover, what do we do at the moment, if a curve was generated for a 16 bit image and the next one is a normal image with 8 bits per channel?
Comment 5 caulier.gilles 2009-10-22 18:10:50 UTC
It's simple : as you can switch from 8 to 16 and 16 to 8 bits into Raw demosaicing settings between Raw import session, and as Curves widget use this setting to adjust internal image data management, curves informations are formated accordingly with this setting. So if you have curves 8 bits info from rc file to apply on 16 bits image, you need to convert it and vice versa...

Gilles
Comment 6 Johannes Wienke 2009-10-22 18:23:18 UTC
But I don't understand, why the Curve needs the information if demosaicing is for 16 bit or not? To my mind the curve should always have the same external interface (with same data ranges and so on) and should handle the differences for 8 or 16 bit internally. This would really simplify the usage.
Comment 7 caulier.gilles 2009-10-22 18:26:59 UTC
No, it's not the same interface for the histogram. Try CurvesAdjust tool for example... and look in CurvesWidget class for details

Gilles
Comment 8 Johannes Wienke 2009-10-22 18:43:14 UTC
I did not mean the same interface for the histogram. What I meant is why ImageCurves needs to use different data ranges (eg. the QPoints returned in getCurvePoint) depending on the number of bits of the image. Why can't it always use 255 as max value and convert it internally to what is needed?

But maybe I misunderstand the purpose of this class. What exactly is it meant to?
Comment 9 caulier.gilles 2009-10-22 18:51:21 UTC
Because ImageCurves code come from gimp which only support 8 bits color depth. I have adapted code to support 16 bits...

Gilles
Comment 10 Johannes Wienke 2009-10-22 18:53:09 UTC
Ah ok, I see
Comment 11 Johannes Wienke 2009-10-23 01:01:35 UTC
SVN commit 1039201 by jwienke:

Restore curves for raw import. This includes some refactorings and removing of magic numbers.

BUG: 211423

 M  +2 -1      NEWS  
 M  +4 -2      imageplugins/adjustcurves/adjustcurvestool.cpp  
 M  +14 -23    imageplugins/coreplugin/bwsepiatool.cpp  
 M  +17 -17    imageplugins/coreplugin/iccprooftool.cpp  
 M  +173 -51   libs/curves/imagecurves.cpp  
 M  +28 -3     libs/curves/imagecurves.h  
 M  +5 -43     libs/widgets/common/curvesbox.cpp  
 M  +2 -2      libs/widgets/common/curvesbox.h  
 M  +109 -8    libs/widgets/common/curveswidget.cpp  
 M  +38 -0     libs/widgets/common/curveswidget.h  
 M  +2 -26     utilities/imageeditor/rawimport/rawsettingsbox.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1039201