Summary: | Raw import intensity curve is not restored | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Johannes Wienke <languitar> |
Component: | Plugin-RawImport-Native | Assignee: | 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
Is this RAW files management or image editor? ;) But this code is dedicated for this task : http://lxr.kde.org/source/extragear/graphics/digikam/utilities/imageeditor/rawimport/rawsettingsbox.cpp#526 http://lxr.kde.org/source/extragear/graphics/digikam/utilities/imageeditor/rawimport/rawsettingsbox.cpp#463 Gilles Maybe an orphaned or invalid read config var again? This is why I started to use variables instead of hardcoded text, 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? 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 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. No, it's not the same interface for the histogram. Try CurvesAdjust tool for example... and look in CurvesWidget class for details Gilles 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? Because ImageCurves code come from gimp which only support 8 bits color depth. I have adapted code to support 16 bits... Gilles Ah ok, I see 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 |