[Bug 148382] New: overexposure indication already when fully "saturated"

[Alexander Neundorf]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=148382         
           Summary: overexposure indication already when fully "saturated"
           Product: digikam
           Version: 0.8.2
          Platform: Compiled Sources
        OS/Version: Linux
            Status: NEW
          Severity: wishlist
          Priority: NOR
         Component: general
        AssignedTo: digikam-devel kde org
        ReportedBy: neundorf kde org


Version:           0.8.2 (using KDE KDE 3.5.5)
Installed from:    Compiled From Sources

Hi,

in the digikam color tools I can enable a "overexposure indicator", which works good so far.
But it is too optimistic, it seems to only consider pixels as overexposed if they really went beyond the 255 count due to some actions in digikam. They should already be marked as overexposed if one channel hits the 255, because this means that this channel had at least 255, so the color has been lost for this pixel.

The images coming from my camera don't go up to 255, they stop at 254 (I think leaving 0xff out as valid pixel value may be the case for many cameras), so I'd say the threshold shouldn't be 255, but 254.

It would also be nice if this would work already in the thumbnail gallery, so that you can see it already in the overview where the bad images are.

Alex
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=148382         




------- Additional Comments From mikmach wp pl  2007-07-31 08:16 -------
> Version:           0.8.2 (using KDE KDE 3.5.5)

Report bugs against latest version (0.9.2)

> The images coming from my camera don't go up to 255, they stop at 254 (I
> think leaving 0xff out as valid pixel value may be the case for many
> cameras), so I'd say the threshold shouldn't be 255, but 254.

Do you have any proof of that?

m.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=148382         
mikmach wp pl changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|general                     |Image Editor
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Alexander Neundorf]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=148382         




------- Additional Comments From neundorf kde org  2007-08-01 01:35 -------
Ok, I checked again, it was in the downscaled version that the values only go to 254, in the fullsize view they reach 255.

Sorry for this.

The other point is still valid (but I didn't check with current svn). Can you point me to the source file where overexposure is detected ?

Alex
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=148382         




------- Additional Comments From marcel.wiesweg gmx de  2007-08-01 16:57 -------
In trunk/ it's line 1204, QImage DImg::pureColorMask(ExposureSettingsContainer *expoSettings) of libs/dimg/dimg.cpp.
The method is called from void DImgInterface::paintOnDevice, utilities/imageeditor/canvas/dimginterface.cpp
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Alexander Neundorf]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=148382         




------- Additional Comments From neundorf kde org  2007-08-02 04:39 -------
I should really try current svn...

Anyway, changing the following line from:
 if (expoSettings->overExposureIndicator &&
     pix.red() == max && pix.green() == max && pix.blue() == max)

to

 if (expoSettings->overExposureIndicator &&
     pix.red() == max || pix.green() == max || pix.blue() == max)

might be a good idea, so you will also catch areas where only one channel is overexposed, which also leads to bad colors, e.g. if you have an area where green would go from 200 to 400 and red and blue from 125 to 250, which would be a bright green gradient, you will instead get a change from bright green to white, since green can't go beyond the 255. Detecting these areas too would show this problem.

Not quite sure about underexposure...
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Alexander Neundorf]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=148382         




------- Additional Comments From neundorf kde org  2007-08-02 04:41 -------
Does this actually work on the full image data or on the image which is scaled down for display ?

In the scaled down image white areas here are only 254, 254, 254 instead of full 255, 255, 255.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=148382         




------- Additional Comments From marcel.wiesweg gmx de  2007-08-02 17:56 -------
It operates on the full image. If you look at paintOnDevice(), which draws a part of the image on a specified region of a paint device, first the image is smoothScaled, then converted to pixmap (with color management applied if enabled) and drawn.
The mask is then created from the relevant part of the full image, scaled, converted to pixmap and drawn.

I am no expert on this, for any changes I suggest to wait until Gilles is back from his holidays.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=148382         




------- Additional Comments From arnd.baecker web de  2007-09-01 02:02 -------
Gilles,

any feedback from your side on this issue?
In particular #4 does sound very reasonable to me.

Arnd
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=148382         




------- Additional Comments From caulier.gilles gmail com  2007-09-01 09:22 -------
Arnd,

Well no. Overexposure for me is to have a real white color (R= 255, G=255, B=255 for 8 bits color depth). For ex. (R=255, G=125, B= 25) is not and overexposed color...

Perhaps we need to add an overage around the limit, for exemple if R > 250 && G < 250 && B > 250

What do you think about ?

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=148382         




------- Additional Comments From mikmach wp pl  2007-09-01 11:42 -------
Maybe two types of overexposure indicator with different colors.
Example: when red is 255 show red zebra, when green is 255 show green
zebra, etc. Only solid black (or white) when all colors are maxed.
Behaviour could be configurable.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=148382         




------- Additional Comments From arnd.baecker web de  2007-09-01 14:33 -------

Currently it is already  possible
to change the colors for over/under exposure.
So this would mean to add two more colors for over-exposure indication?
(do we need the same for under-exposure?, presumably not ...)

Gilles, I do think that individual R, G, B channels can be
overexposed, see e.g.
""" You need to have a histogram that shows each of the R, G and B
channels. Single channel histograms don't show when just one color
is overexposed."""
(from http://www.kenrockwell.com/tech/yrgb.htm)
Therefore I am not sure whether averaging is the right approach.
Any value 255 could mean that this was 256 or more, clipped to 255.

I still find #4 convincing.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel