[Bug 279544] New: WISH: marking for unsharp pictures

[Axel Krebs]

https://bugs.kde.org/show_bug.cgi?id=279544

           Summary: WISH: marking for unsharp pictures
           Product: digikam
           Version: 2.0.0
          Platform: Ubuntu Packages
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: Filters
        AssignedTo: [hidden email]
        ReportedBy: [hidden email]


Version:           2.0.0 (using KDE 4.6.2)
OS:                Linux

Hello,

When searching through lots of pictures (15.000, e.g.), it would be very
advantegous if there was a way to mark unsharp pics in the collection.

In editing modus, lens correction there is already a procedure to affect
sharpness. Thats why I am hoping there is an algorithm to detect sharpness of a
pic.

Going through huge numbers of pics, it would help to mark pics automatically,
may in classes:

class I:   perfectly sharp
class II:  satisfying sharpness most areas of the pic
class III: misty pics, with no sharp area borders.

I guess, one could deal with sharpness detection by analysing some small areas
(diameter or square of 20 picels wide, e.g.).

For the sake of analysing speed, there could be a statistical approach to
determine this information only on (statistically) selected areas.

This would easy getting better workflow, I assume, as manual and time-consuming
work could be concentrated on worthy pics.

Maybe it is not necessary for all users, and not for all times; but maybe a
switch could enable this feature.


Axel


Axel


Reproducible: Always

Steps to Reproduce:
not avaliable

Actual Results:  
not avaliable

Expected Results:  
should be implemented

OS: Linux (i686) release 2.6.35-30-generic-pae
Compiler: cc

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=279544


Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]
          Component|Filters                     |Tags




--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

https://bugs.kde.org/show_bug.cgi?id=279544


Martin Tlustos <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]




--- Comment #1 from Martin Tlustos <martin tlustos gmail com>  2011-09-22 14:25:24 ---
Yep, that would be great...

--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=279544


Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|WISH: marking for unsharp   |Tag image for unsharp
                   |pictures                    |pictures




--
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gowtham Ashok]

https://bugs.kde.org/show_bug.cgi?id=279544

--- Comment #2 from Gowtham Ashok <[hidden email]> ---
Created attachment 78517
  --> https://bugs.kde.org/attachment.cgi?id=78517&action=edit
Algorithm: Finding blurry images

Basic algorithm which returns a low value when image is blurry and vice versa.
Requires openCV. Needs one image input.
To build it, cmake . and make it.
Please give feedback.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Axel Krebs]

https://bugs.kde.org/show_bug.cgi?id=279544

--- Comment #3 from Axel Krebs <[hidden email]> ---
Dear Gowtham:

Wonderful to read, that you are working on this issue!

Unfortunately, I am not a programmer or software-specialist.

So, I will try to describe my primary intentions with reflection to some
approaches available.

In modern DLRs they use several ways to get to sharpness- you may want
to check http://en.wikipedia.org/wiki/Autofocus .

If this would resonable to copy one of these methods: I do not know.
Maybe the preconditions are different: in reality, when taking a
picture, we have a reduction from 3D to 2d. When searching unsharp
pictures within a collection, we have "pure 2D".

As a matter of fact, when I suggestet this issue, I had in my mind:
checking large picture collection automatically for _completely_ unsharp
pic to have some type of automated filter-function.

So, my intention was originally, to have some sorting-function. This
would be a much weaker demand than we have in autofocus in modern DLRs.
Isn't it?

Ok, when "sorting out", there should be a remaining lot of pics which do
_not_ fulfil this sharpness criterium. These pics has to be marked out
to check these manually.

As an artists intentions maybe changing and lead by art, not
mathematical rules.

For my opinion, the original pic has the highest value.

Yours,


Axel


Am 31.03.2013 01:01, schrieb Gowtham Ashok:

> https://bugs.kde.org/show_bug.cgi?id=279544
>
> --- Comment #2 from Gowtham Ashok <[hidden email]> ---
> Created attachment 78517
>   --> https://bugs.kde.org/attachment.cgi?id=78517&action=edit
> Algorithm: Finding blurry images
>
> Basic algorithm which returns a low value when image is blurry and vice versa.
> Requires openCV. Needs one image input.
> To build it, cmake . and make it.
> Please give feedback.
>

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gowtham Ashok]

https://bugs.kde.org/show_bug.cgi?id=279544

Gowtham Ashok <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #4 from Gowtham Ashok <[hidden email]> ---
I have used a concept similar to autofocus in the code.
Better Explanation:
http://www.howstuffworks.com/autofocus3.htm

Yes, after image is taken, we do not have any data about the distance of the
camera from the subject(that is why we have to use passive autofocus).

Sharp or blurry is somewhat subjective. There are also cases where the
photographer intended to give a blur effect, or while taking a shot of a
fast-moving object.
http://img.ehowcdn.com/article-new/ehow/images/a05/ah/vv/fast-f1-car_-800x800.jpg

So, if we can take care of this, we can probably have a useful image
classification algorithm.
We can also combine this with face detection algorithm to give better output.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Axel Krebs]

https://bugs.kde.org/show_bug.cgi?id=279544

--- Comment #5 from Axel Krebs <[hidden email]> ---
I can tell you just- some considerations.

Thank you for the links, content, I read with great interest.

"sharp or blurry .. subjective": you are right, and, maybe even more
difficult, it might be intentional in certain cases. I agree.

The smple for fast moving object is another topic, which comes
instanteneously in my mind: but in contradiction to that, there should
be a possiblitzy to "filter" any linear or even non-linear movement. And
derive a sharp pic inversely, when substraction the dislocation vector.

I am happy that you seem to be able to take care of this issue. For my
opinion, this inverse procedure could be an intelligent way to sharpen
even blurry pics- under the precondition, that there is a (mathematical)
linear movement involved. mathematoical linear. I mean, a movement path
which coul be a strauigtgt line, a periodic ("wavy") function or
something similar.

!!
I guess, we should distinguish between filterung blurry pics ("BPF")
 and gaining sharp pics from ones the the blurry because of moving te
lens while exposing a pic.
!!

Am 31.03.2013 11:44, schrieb Gowtham Ashok:

> https://bugs.kde.org/show_bug.cgi?id=279544
>
> Gowtham Ashok <[hidden email]> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |[hidden email]
>
> --- Comment #4 from Gowtham Ashok <[hidden email]> ---
> I have used a concept similar to autofocus in the code.
> Better Explanation:
> http://www.howstuffworks.com/autofocus3.htm
>
> Yes, after image is taken, we do not have any data about the distance of the
> camera from the subject(that is why we have to use passive autofocus).
>
> Sharp or blurry is somewhat subjective. There are also cases where the
> photographer intended to give a blur effect, or while taking a shot of a
> fast-moving object.
> http://img.ehowcdn.com/article-new/ehow/images/a05/ah/vv/fast-f1-car_-800x800.jpg
>
> So, if we can take care of this, we can probably have a useful image
> classification algorithm.
> We can also combine this with face detection algorithm to give better output.
>

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Axel Krebs]

https://bugs.kde.org/show_bug.cgi?id=279544

--- Comment #6 from Axel Krebs <[hidden email]> ---
Dear Gotham:

Maybe you still work on this issue?

As I found several hits in this context recently, I assume, finding
sharp/unsharp pics automatically could be a technologgy of the future.

Recent article in a leading German computer paper:
http://www.heise.de/ct/inhalt/2013/18/68/ "Verwackelkandidate" (meaning
"de-unsharp-utitility")

Others.
- http://www.heise.de/download/image-analyzer-1121815.html
- http://logicnet.dk/Analyzer/
I guess, you'll keepo track with relevant developments?

All the best



Axel

Am 31.03.2013 13:44, schrieb Gowtham Ashok:

> https://bugs.kde.org/show_bug.cgi?id=279544
>
> Gowtham Ashok <[hidden email]> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |[hidden email]
>
> --- Comment #4 from Gowtham Ashok <[hidden email]> ---
> I have used a concept similar to autofocus in the code.
> Better Explanation:
> http://www.howstuffworks.com/autofocus3.htm
>
> Yes, after image is taken, we do not have any data about the distance of the
> camera from the subject(that is why we have to use passive autofocus).
>
> Sharp or blurry is somewhat subjective. There are also cases where the
> photographer intended to give a blur effect, or while taking a shot of a
> fast-moving object.
> http://img.ehowcdn.com/article-new/ehow/images/a05/ah/vv/fast-f1-car_-800x800.jpg
>
> So, if we can take care of this, we can probably have a useful image
> classification algorithm.
> We can also combine this with face detection algorithm to give better output.
>

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gowtham Ashok]

https://bugs.kde.org/show_bug.cgi?id=279544

--- Comment #7 from Gowtham Ashok <[hidden email]> ---
Hello Axel,

Thanks for the links. Gilles, Marcel and me are working on adding this feature
to digiKam.

For more information, please refer to
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/gwty/1

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Axel Krebs]

https://bugs.kde.org/show_bug.cgi?id=279544

--- Comment #8 from Axel Krebs <[hidden email]> ---
Dear Gotham, Gilles and Marcel,

This sounds absolutely great!

I believe this project has a good chance to force through against
commercial prgs.

Thank you for your efforts!


Axel
--
Am 24.08.2013 13:44, schrieb Gowtham Ashok:

> https://bugs.kde.org/show_bug.cgi?id=279544
>
> --- Comment #7 from Gowtham Ashok <[hidden email]> ---
> Hello Axel,
>
> Thanks for the links. Gilles, Marcel and me are working on adding this feature
> to digiKam.
>
> For more information, please refer to
> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/gwty/1
>

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Axel Krebs]

https://bugs.kde.org/show_bug.cgi?id=279544

--- Comment #9 from Axel Krebs <[hidden email]> ---
Am 24.08.2013 13:44, schrieb Gowtham Ashok:

> https://bugs.kde.org/show_bug.cgi?id=279544
>
> --- Comment #7 from Gowtham Ashok <[hidden email]> ---
> Hello Axel,
>
> Thanks for the links. Gilles, Marcel and me are working on adding this feature
> to digiKam.
>
> For more information, please refer to
> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/gwty/1
>

Dear Gowtham:

My original intention reffered on blur- which comes more and more
objective.

NIKON advices certain techniques to reduce bluring effects see
<http://www.nikonusa.com/en_US/o/Y6wrkA9OU_z04IreazIXl_22UII/PDF/D800_TechnicalGuide_En.pdf>
for its Model D800 / D800 E.
(I own one- great machine, 36 MPixels ;-)! )

From my fotographical practise, I experienced, that blur can be an
interesting effect. But, most of the time, we want or even need to avoid
this unsharpness type!

When having _real_ fotographic situations in mind, I feel, that _linear_
transitions ("mistakes, unsharpness effects") are _not_ the single
interesting ones.

There can be circular or bow-shaped transitions or others. Imagine, a
photographer stands in the wind and get hit by a gust of wind. Not
having a tripod because of weight limitations.

The movement of an imaginary pics point will then _not_ follow a line
nor a circle but rather more a _freely_ curved line.
---

Another type of mistake maybe related to the artefacts/mistakes, you
mentioned in your descriptive
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/gwty/1

What happens, if some parts of a pic are too bright by far? Maybe there
is a way to reconstruct the brightness distribution around such a
brigthish area using neural network approaches for self learning
procedures, how "burned-out" areas can be filled according to surronding
areas? And still keep similar appearences compared to the surrounding areas?
--

I mention this idea to show, that I guess, the borderline between
filtering for quality and impoving is not a fixed line at all but needs
interpretation. Maybe numerical interpretation?

Besides, some number characteristics could help to concentrate on such
pics which are worth for improving techniques or- not.

Some further thoughts-


Yours Axel

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

https://bugs.kde.org/show_bug.cgi?id=279544

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
   Version Fixed In|                            |4.0.0
         Resolution|---                         |FIXED

--- Comment #10 from Gilles Caulier <[hidden email]> ---
Implemented in 4.0.0 release.

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel