Linear Histogram is always empty

[manuel]

Binary package hint: digikam

Only logarithmic histogram show any information, linear histogram is always empty

ProblemType: Bug
Architecture: i386
Date: Wed Dec 16 23:10:23 2009
DistroRelease: Ubuntu 9.10
Package: digikam 2:1.0.0~rc-1ubuntu1~karmic1
ProcEnviron:
 PATH=(custom, no user)
 LANG=es_VE.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-17.54-generic
SourcePackage: digikam
Uname: Linux 2.6.31-17-generic i686

[dhjt (d-h-j-takken)]

Version: 0.9.4-beta4 (using KDE 3.5.8)
OS: Linux

I get the impression that the histogram preview is calculated from a downscaled version of the image. The result is that the histogram preview is not very accurate.

When working with large images, this causes problems. The original image may contain many small highlights that completely disappear when the image is scaled down. So, in the Adjust Curves preview window, these highlights go unnoticed. When adjusting the curve, you can easily clip the high lights without noticing it. Only after applying the final Adjust Curves settings, the full histogram is re-calculated. Often, it turns out that the histogram has been clipped, while the preview looked just fine.

IMHO an accurate preview of the resulting histogram is critical to a Adjust Curves tool. Maybe the plugin should have an option to create a preview based on the full image in stead of a scaled down version. I can imagine adding a 'fast preview' checkbox that is checked by default.

The Adjust Levels tool will probably have the same problem, but I did not check.

[Kde-20-micorreo (kde-20-micorreo)]

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

[Caulier-gilles-9 (caulier-gilles-9)]

This problem have been fixed with 1.0.0. Check this version.

Gilles Caulier

[Luka Renko (lure)]

I cannot reproduce this problem with 1.0/final.

Digikam 1.0/final is now available for Karmic users in karmic-backports repository. Can you enable backports repository and confirm that you still have this problem?

[manuel (manuel-soto)]

2010/1/3 Luka Renko - :
> I cannot reproduce this problem with 1.0/final.
>
> Digikam 1.0/final is now available for Karmic users in karmic-backports
> repository. Can you enable backports repository and confirm that you
> still have this problem?
>
>
> ** Changed in: digikam (Ubuntu)
>       Status: New => Incomplete
>
> --
> Linear Histogram is always empty
> https://bugs.launchpad.net/bugs/497620
> You received this bug notification because you are a direct subscriber
> of the bug.
>
>

Fixed in 1.0 karmic-backports

[Luka Renko (lure)]

Thanks for testing and confirming it is fixed.

[Caulier-gilles-9 (caulier-gilles-9)]

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

[Caulier-gilles-9 (caulier-gilles-9)]

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

[dhjt (d-h-j-takken)]

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.

[Caulier-gilles-9 (caulier-gilles-9)]

>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

[tschenser (tschenser)]

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

[Caulier-gilles-9 (caulier-gilles-9)]

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

[tschenser (tschenser)]

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

[Caulier-gilles-9 (caulier-gilles-9)]

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

[Caulier-gilles-9 (caulier-gilles-9)]

>- 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

[Caulier-gilles-9 (caulier-gilles-9)]

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

[Caulier-gilles-9 (caulier-gilles-9)]

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

[tschenser (tschenser)]

> 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!

[tschenser (tschenser)]

@ 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.

[Caulier-gilles-9 (caulier-gilles-9)]

Jens, yes, it's possible. I will take a look.

Gilles

[Caulier-gilles-9 (caulier-gilles-9)]

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