Version: 2.0.0 (using KDE 4.7.0) OS: Linux I'm trying to change the curves on some images with the Digikam batch processor, but it doesn't work. Everything seems to work, the history box reports that the images has been processed, but when viewing the output image, it looks exactly like the original. Reproducible: Always Steps to Reproduce: Open Digikam batch processor Add images Select "Curves adjustment", change something Press start button... Actual Results: You get a copy of the original image Expected Results: You get an image that has been adjusted like you have set the curves.
Git commit 984dcf90e526f427d53976717beb14b78b08b027 by Gilles Caulier. Committed on 31/08/2011 at 14:45. Pushed by cgilles into branch 'master'. fix curve adjust BQM tool t use right color depth with image to process BUGS: 281095 M +24 -25 utilities/queuemanager/basetools/color/curvesadjust.cpp M +1 -1 utilities/queuemanager/basetools/color/curvesadjust.h M +3 -0 libs/dimg/filters/curves/curvesfilter.cpp http://commits.kde.org/digikam/984dcf90e526f427d53976717beb14b78b08b027
I re-open this file. It still a problem with curve applied in BQM in FREE edition mode. SMOTH edition work fine. It's due to a lack of information passed from an edition mode to another one. I will fix it to 2.2.0 release (too late for 2.1.0) Gilles Caulier
*** Bug 284391 has been marked as a duplicate of this bug. ***
Normally, the ImageCurvesFilter should convert the ImageCurves object to the necessary bits depth with ImageCurves::fillFromOtherCurves, which produces debug info. Anyone already found out where exactly the problem is?
Marcel, Yes i found it. Let's me some time to find my bookmark in code... Gilles
The problems seems to be still present in digikam-2.4.1 with kipi-plugins-2.4.1. Do you confirm ?
yes, i don't have fixed it... Gilles Caulier
The bug seems to be still present in DigiKam 2.5.0 (KDE 4.7.4). Is there any workaround to be able to batch process B&W filter before the bug gets closed? Or is there any way I can help solving the bug?
Any testing here with a recent version?
Unfortunately I don't have latest version (I would have to recompile whole KDE), but with 2.9.0 the bug was still present.
If to reproduce it's enough to try 'curves adjust' on a photo in batch queue manager I can't reproduce (current master, 5673a4b). I haven't understood the difference between "BQM in FREE/SMOTH edition mode" mentioned earlier though.
"Curve adjust" works in Digikam 3.0 but "B&W convert" is still broken : - Open the "Batch Queue Manager" - Add "B&W convert" (without modifying anything) - Run --> All the generated images are black
Marcel, If you look my previous comment #2 and #5, the problem still here. I don't have fixed code. It's due to a lack of curve data transformation code between smooth and draw mode. If i remember, one transformation is missing, which make black image result. Curve data are managed in draw when image is processed. Why ? to not lack any information. When you play curve in smooth mode (16 points max) and must be transformed as draw. this want mean one point for one value under 16 bits : 65536 points. This is 16 bits in all cases and switch from 8 bits to 16 bits transformation must be done (and vis-versa). If i remember this last transformation is missing. Gilles Caulier
ImageCurves::fillFromOtherCurves is not sufficient for 8 <-> 16 bit conversion?
I think no, if i remember my investigations. Something is missing in source code to convert from smooth to draw mode and vis versa.
That is not implemented, and FREE cannot be converted to SMOOTH mode. Why would we need it? Either the curve is created by the user in FREE, or in SMOOTH mode.
Marcel, I just tested. There are two problems : 1/ In BQM, Adjust curves tool do not take effect on image when it's processed as FREE mode. In SMOOTH mode no problem. To reproduce it's very simple : Load few JPEG in BQM, assign curves adjust + PNG export tools, change curve settings to reduce luminosity (just drop-down curve with one central point to the bottom). In a first time use SMOOTH mode and look result. All is fine in target image. Now, just switch mode from SMOOTH to DRAW. central point disappear. Remove previous target PNG and run again the queue. Look the result : source and target image have the same luminosity. 2/ In BQM, Convert to B&W produce black hole images when curve adjustments is used. Use same queue context than 1/ and replace Adjust Curves tool by Convert to B&W. In B&W settings use Generic film + No Lens Filter + No Tone Filter. Just go to Luminosity curve and drop-down curve in SMOOTH mode to reduce luminosity. Run queue, and look the result : all target image are black holes. Now switch curve from SMOOTH to FREE and run again the queue : All image are converted to B&W but luminosity is not changed. Gilles Caulier
Marcel, Another point : If you test image editor tool (B&W and Adjust Curves), no dysfunction are visible. Only BQM tools are broken. The reason about is that BQM tools settings widget pass curves parameters to BQM action thread using a QPolygon container for each color channel to apply (See CurvesContainer API). Format of data osted in QPolygon depand of curves widget settings of course. In BQM, it's always set as 16bits color depth, to be compatible with all image type (we know the color depth of image only when queue is processed). Also, FREE or SMOOTH mode depend of user choice done in GUI. Action thread recieve QPolygon data and must convert curves settings to the right format, compatible with image properties just loaded in BQM tool to be processed. It's at this time that curves conversion are processed and failed. Gilles
*** Bug 317658 has been marked as a duplicate of this bug. ***
Git commit 76de9f0a1f21a28218bc4b24dbea5ede0d3b3388 by Marcel Wiesweg. Committed on 01/05/2013 at 16:30. Pushed by mwiesweg into branch 'master'. Fix curve conversion in FREE mode from 16 to 8 bit FIXED-IN: 3.2.0 M +1 -1 libs/dimg/filters/curves/imagecurves.cpp http://commits.kde.org/digikam/76de9f0a1f21a28218bc4b24dbea5ede0d3b3388
Git commit 85622209f06f61efb7dcce98508e7f9119294f2e by Marcel Wiesweg. Committed on 01/05/2013 at 16:52. Pushed by mwiesweg into branch 'master'. Properly initialize a smooth curve to be linear. Last point was set as first point. The bug only appeared in BQM's B&W conversion which only uses the luminosity channel, taking the default constructed CurvesContainer for the other colors. M +1 -1 libs/dimg/filters/curves/curvescontainer.cpp M +1 -1 libs/dimg/filters/curves/imagecurves.cpp http://commits.kde.org/digikam/85622209f06f61efb7dcce98508e7f9119294f2e
Many thanks Marcel! This patch works for me.
Git commit 9d109067cd2237840373b6857e8c68d608f1015b by Veaceslav Munteanu, on behalf of Marcel Wiesweg. Committed on 01/05/2013 at 16:30. Pushed by munteanu into branch 'picassafacetag'. Fix curve conversion in FREE mode from 16 to 8 bit FIXED-IN: 3.2.0 M +1 -1 libs/dimg/filters/curves/imagecurves.cpp http://commits.kde.org/digikam/9d109067cd2237840373b6857e8c68d608f1015b
Git commit 0ac25a4a0d77b58fc8dd76d9abee3ba14fa0a4eb by Veaceslav Munteanu, on behalf of Marcel Wiesweg. Committed on 01/05/2013 at 16:52. Pushed by munteanu into branch 'picassafacetag'. Properly initialize a smooth curve to be linear. Last point was set as first point. The bug only appeared in BQM's B&W conversion which only uses the luminosity channel, taking the default constructed CurvesContainer for the other colors. M +1 -1 libs/dimg/filters/curves/curvescontainer.cpp M +1 -1 libs/dimg/filters/curves/imagecurves.cpp http://commits.kde.org/digikam/0ac25a4a0d77b58fc8dd76d9abee3ba14fa0a4eb