| Summary: | Accurate histogram preview required | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Dik Takken <kde> |
| Component: | Plugin-Editor-Curves | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | wishlist | CC: | caulier.gilles, kde.20.micorreo, tschenser |
| Priority: | NOR | ||
| Version: | 1.2.0 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 1.2.0 | |
| Sentry Crash Report: | |||
|
Description
Dik Takken
2008-06-05 18:28:18 UTC
In my case, I don't know if the problem is related to my installation, linear histogram rarely display anything, I've to work all the time using logarithm histogram Later Manuel This problem have been fixed with 1.0.0. Check this version. Gilles Caulier Dik, With 1.2.0, I plan to change all Colors Correction tools in editor to : - Use zommable preview widget. - Use mutithreading everywhere with this tools (not yet done since a long time) - Compute histogram on visible preview. If you zoom to fit image on scrren, you will compute histogram on whole image. I started with BCG tool. Code is in svn now. I would to know your feedback here before to continue. Relevant tools to do are : - HSL - Color Balance - Chanels mixer - B&W - Auto corrections - Levels - Curves - White Balance Gilles Caulier SVN commit 1087337 by cgilles: port BCG tool to use zoomable preview, multithreading, and histogram computation based on visible preview region. CCBUGS: 163286 M +16 -29 bcgtool.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1087337 Gilles, This sounds really good. Does this mean that it is possible to preview the histogram of a small detail as well? That would enable us to check if small details become overexposed for example. I might get to try a SVN checkout this weekend. >Does this mean that it is possible to preview the histogram of a small detail as >well?
Yes absolutly. The histogram is computed with visible preview area, set by preview mode buttons from right side of status bar. If you zoom indeep the image, you will compute histogram from this part.
Gilles Caulier
I can not check this as histogram in BCG is not working for me at the moment. But does this mean that histogram is _always_ computated on visible preview area? I mean this is a feature, but we do also not update image dimension display on visible preview area. Even in zoom it should be possible to have a full image histogram and for my understandings this should be standard. Or do I understand something wrong? Jens Jens, As with 1.1.0, histogram been computed with preview area. The difference now, is to not use fit on screen widget for preview (imageguidewidget), but a zoomable widget (imageregionwidget). The advange are huge : you can select the region to explore, zoom to 1:1, and zoom to fit. So, if you want full image histogram, fit preview and use target image preview mode. Gilles Caulier Gilles, the advantages of a zoomable imageregionwidget are huge, indeed! But not for histogram display. Let me explain why: - If I need histogramdata of a square area on my 16:9 display I do not want to buy a new monitor or adjust digikam window size - In canvas we have full histogram and selection histogram regardless of zoom. If I switch now to a tool this should be the pure opposite? So why not reuse selection histogram in tools? That would be consistent. Jens SVN commit 1088545 by cgilles: Color Balance tool : - use multithreading. - use zommable preview widget. - compute histogram on visible preview area. CCBUGS: 163286 M +1 -1 CMakeLists.txt M +61 -251 imageplugins/coreplugin/rgbtool.cpp M +13 -14 imageplugins/coreplugin/rgbtool.h M +3 -1 libs/dimg/filters/CMakeLists.txt A libs/dimg/filters/cb/cbsettings.cpp libs/dimg/filters/bcg/bcgsettings.cpp#1088116 [License: GPL (v2+)] A libs/dimg/filters/cb/cbsettings.h libs/dimg/filters/bcg/bcgsettings.h#1088116 [License: GPL (v2+)] D libs/dimg/filters/cb/colormodifier.cpp D libs/dimg/filters/cb/colormodifier.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1088545 >- If I need histogramdata of a square area on my 16:9 display I do not want to >buy a new monitor or adjust digikam window size But there is no regression why new code compared to old one based on imageguide widget. before to use zoomable preview, you cannot do that too. Also, this is not the goal to show a specific region rectangle (with a specific ratio) of image. When you use BCG tool, you just want to see a preview relevant of future change. For technical reason, we use geometry of preview widget to render that. It's more simple. >- In canvas we have full histogram and selection histogram regardless of zoom. >If I switch now to a tool this should be the pure opposite? Yes, and you can do it again. This feature is not removed. >So why not reuse selection histogram in tools? That would be consistent. Because, all preveiw widget are not yet factorized. I have alredy factored a lots of code there, but i must take a care to not break all faster. Your idea will be possible when editor canvas and preview widget implementation will be merged, and also ported to pure Qt4. This is not yet the case. Editor canvas as selection code, preview widget no. To be clear here, preview widget are : - previewwidget (root code Q3Scrollview based zoomable but without preview mode) - imageregionwidget (based on preview widget, used by editor tools, implementing preview modes) - canvas (based on Q3Scrollview, used for main editor view, zoomable, implementing selection) - rawpreview (used by RawImport tool, based on previewwidget) - lighttablepreview (used by LT, based on previewwidget) - imagepreviewview (used by AlbumGUI preview, based on previewwidget) Image editor use too imageguidewidget with some tools which need a preview fit on window. All color correction tools are based on this, and i currently port all on imageregionwidget. The pure Qt4 port of preview widget is very important to the future. QScrollArea API must be used there. My first plan is to polish all digiKam API before to have a cleaned code to port. I think i have review all and Qt4 port can be done as well... but you can imagine all regression tests to do there. This will require a digiKam release only for that. So, like there are a lots of changes done with 1.2, i will wait 1.3 a little bit. If you is interrested to help me here, let's me hear. Gilles Caulier Another comment on my work : I currently port of color correction editor tools to use multithreading (as sharpen or NR work). This require to review all algorithms in digiKam core (DImg) and create new classes. I separate all implementations to be clear. For each editor tool, we will have : - a core algorithm multitreadable. - a settings widget. - a settings container. The goal is to share all possible code between editor tool and... Batch Queue Manager tool. For each editor tool, i create a new BQM tool. Look my changes done with BCG correction which is now available in BQM. Gilles Caulier SVN commit 1088804 by cgilles: HSL editor tool : - use multithreading. - use zommable preview widget. - compute histogram on visible preview area. CCBUGS: 163286 M +1 -0 CMakeLists.txt M +4 -7 imageplugins/coreplugin/bcgtool.cpp M +64 -230 imageplugins/coreplugin/hsltool.cpp M +8 -13 imageplugins/coreplugin/hsltool.h A libs/dimg/filters/hsl/hslsettings.cpp libs/dimg/filters/bcg/bcgsettings.cpp#1088597 [License: GPL (v2+)] A libs/dimg/filters/hsl/hslsettings.h libs/dimg/filters/bcg/bcgsettings.h#1088597 [License: GPL (v2+)] WebSVN link: http://websvn.kde.org/?view=rev&revision=1088804 > Because, all preveiw widget are not yet factorized. I have alredy factored > a lots of code there, but i must take a care to not break all faster. > > Your idea will be possible when editor canvas and preview widget > implementation will be merged, and also ported to pure Qt4. This is not > yet the case. That I truly understand. Also that you do not not want to make regressions and for that I be at one with you. But my opinion for future stays the the same, tools should act like current canvas do in case of zoom and histogram. > The pure Qt4 port of preview widget is very important to the future. > QScrollArea API must be used there. My first plan is to polish all digiKam > API before to have a cleaned code to port. Definitively right! @ Gilles: As far as I can see a call to slotEffect() is missing in EditorTool::slotInit() after unblocking signals. http://lxr.kde.org/source/extragear/graphics/digikam/utilities/imageeditor/editor/editortool.cpp#182 This is needed for initial preview and initial histogram update. As I'm not shure on overall interactions I mark this only here. Jens, yes, it's possible. I will take a look. Gilles SVN commit 1098360 by cgilles: port Adjust Levels tool to use zoomable preview, multithreading, and histogram computation based on visible preview region. BUGS: 163286 M +82 -70 imageplugins/coreplugin/adjustlevelstool.cpp M +17 -12 imageplugins/coreplugin/adjustlevelstool.h M +8 -8 imageplugins/coreplugin/bcgtool.cpp M +1 -1 libs/dimg/filters/levels/levelsfilter.cpp M +13 -8 libs/widgets/common/dgradientslider.cpp M +13 -10 libs/widgets/common/dgradientslider.h M +13 -6 libs/widgets/common/histogrambox.cpp M +1 -0 libs/widgets/common/histogrambox.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1098360 |