[Bug 205776] New: "Embedded preview loads full image size" does not only do what it says, confusing users

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

           Summary: "Embedded preview loads full image size" does not only
                    do what it says, confusing users
           Product: digikam
           Version: 0.10.0
          Platform: SuSE RPMs
        OS/Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: [hidden email]
        ReportedBy: [hidden email]


Version:           0.10.0 (using KDE 4.2.4)
Installed from:    SuSE RPMs

For raw files, the user setting "Embedded preview loads full image size"
currently decides whether embedded jpg preview is used or whether "full-size"
preview is generated by digikam's raw decoding (in addition to limiting preview
size).

Nikon NEF files contain a full-size jpg preview of the raw file. This is never
used for full-size previews since Digikam chooses its own raw decoding instead,
if full-size previews are requested.

This is not ideal for Nikon NEF files:
If the NEF file has been edited with a program which non-destructively stores
edits in the NEF file itself (Capture NX2, for example), the embedded preview
correctly shows the edited image. Digikam's own raw decoding preview of course
only shows the original version (and Digikam's raw decoding does not use all
raw development settings in the file).

In my opinion there should be two user preferences:
- Whether to load fulls-size previews or limit preview to display size
- Whether to use embedded jpg preview with raw files or to decode the raw file
itself

Maybe it could be possible to combine these to preference with three options:
- Display-sized previews using embedded jpg if possible
- Full-sized previews using embedded jpg if possible
- Full-sized previews using decoded raw data

However, I think that preview size and preview raw decoding preference should
be separate.

Matti Rintala

P.S. I have already made a dirty hack for myself, and that only required minor
modifications in digikam/imagepreviewview.cpp. The decision on whether to add a
new user preference is bigger, of course.

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





--- Comment #1 from Mikolaj Machowski <mikmach wp pl>  2009-08-31 13:58:52 ---
Well, maybe current behavior isn't optimal but in this aspect digiKam behaves
as it should. Option means that in preview will be used *real* image. In this
case RAW is real image and digiKam loads it.

IMO proper way to handle this would be adding sub-option: "In case of RAW files
still use embedded preview" (default on).

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


Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|general                     |RAW files management




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





--- Comment #2 from Matti Rintala <bitti cs tut fi>  2009-08-31 14:12:39 ---
What I meant is that the GUI text is "Embedded preview loads full image size".
It doesn't say anything about "real" or "high-quality", only that full *size*
of image will be used for preview.

I think the wording of the user preference should clearly say how each setting
chooses preview size and whether it uses embedded preview or not. And that it
should be possible to use embedded preview jpg in its full resolution.

I agree with Mikolaj about a sub-option, since users of raw-based previews
probably want full resolution previews anyway (actually half-size, if dcraw -h
equivalent is used to create the quick preview).

Matti

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





--- Comment #3 from Matti Rintala <bitti cs tut fi>  2009-08-31 14:27:00 ---
I just had a new look at the source, and in fact Mikolaj's sub-option idea is
the easiest to implement:

- in digikam/imagepreviewview.cpp ImagePreviewView::setLoadFullImageSize, set
d->previewSize to some huge maximum value, if full-size image is requested.
Otherwise recalculate d->previewSize based on display size like in constructor.

- in digikam/imagepreviewview.cpp ImagePreviewView::setImagePath use the new
raw-preview sub-option instead of d->loadFullImageSize to choose whether to
call d->previewThread->loadHighQuality or d->previewThread->load

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





--- Comment #4 from Gilles Caulier <caulier gilles gmail com>  2009-08-31 14:54:17 ---
Matti,

Patch against code from trunk is welcome...

Gilles Caulier

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





--- Comment #5 from Matti Rintala <bitti cs tut fi>  2009-08-31 15:25:03 ---
Gilles,

I'm ready to try to make a patch (I'm not very familiar with Digikam source,
but after a quick look I think I can learn enough as I go). However, there's a
couple of design decision that should be made and I'm not the right person to
make them:

What kind of GUI should the new setting have? There are at least three choices
I can think of:
- A new checkbox for selecting raw-decoding vs. embedded preview for raw files
("use embedded preview for raw files")
  + Easiest to implement
  + Most backward compatible
  - Adds yet another user preference
  - Combination not-full-size & no-embedded probably not useful (and difficult
to implement in current source)
- Similar to above, but raw-decoding selection is grayed out if full-size is
not selected (reduced-size preview always uses embedded preview if available)
  + Solves the combination problem above
  - I'm not experienced enough with KDE GUI programming to write the GUI logic
- A single radio button / dropdown list for selecting fullsize-raw,
fullsize-embedded and reduced-size-embedded
  + Changes the user preference from a boolean to a three-state value
  - Above makes it less backward compatible? (Old 0.10.0 preference files?)

In any of the cases above, on the source level there will be changes to the
interface of several classes, since current preview classes explicitly name the
member functions "...LoadFullImageSize...", so using existing member functions
to select raw/embedded-jpg is not appropriate in my opinion. Either new methods
"...LoadEmbeddedPreview..." should be added or the current methods should be
renamed "...PreviewQuality..." or something similar.

Any opinions before I try to mess up the source? :-)

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





--- Comment #6 from Mikolaj Machowski <mikmach wp pl>  2009-08-31 16:44:38 ---
2nd version is the best. 3rd also isn't bad (I think dropdown list better to
save size of dialog).

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

[Marcel Wiesweg]

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


Marcel Wiesweg <[hidden email]> changed:

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




--- Comment #7 from Marcel Wiesweg <marcel wiesweg gmx de>  2009-08-31 18:09:41 ---
My vote for 2) as well.

Is the embedded preview in raw files always full size, or only for some
formats? Can we know in advance?

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





--- Comment #8 from Matti Rintala <bitti cs tut fi>  2009-08-31 19:12:32 ---
I see what you mean. That affects how the settings should be described in GUI.

Currently Digikam offers two choices for raw files:
1) full-size preview off: use embedded preview (if exists), limit preview size
to display size
2) full-size preview on: raw-decode preview, use full image size in preview

So if a raw file from some camera only contains a small preview, the user
simple switches full-size preview on (using raw decoding as a side effect).
However, if the raw file contains a full-size preview, there's no way to use it
full-sized.

With my suggestion, there would be three choices (these choices are a little
bit different than what I suggested before):
1) embedded preview off: raw-decode preview, use full image size in preview
2) embedded preview on & limit preview size off: use embedded preview (if
exists) using its native size
3) embedded preview on & limit preview size on: use embedded preview (if
exists), limit preview size to display size

Now raw files with full-sized embedded preview can be viewed properly. If some
raw file only contains tiny embedded preview, the user just switches embedded
preview off to use raw decoded preview.

What do you think?

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

[Marcel Wiesweg]

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





--- Comment #9 from Marcel Wiesweg <marcel wiesweg gmx de>  2009-08-31 19:31:17 ---
I was mainly asking because of implementation details involved. I think the
wording of the options should be plain and intuitive.

Let's think about the rationale behind this: This is mainly about JPEGs and RAW
files. It is faster to load a JPEG to a smaller size; it is much faster to load
a RAW embedded preview than loading a full RAW file. So users should choose
between speed and quality. Imagine two radio boxes
(x) Load previews fast
( ) Load previews in high quality
Now comes RAW; for RAWs, "high quality" is not clearly defined. For choice 2,
we can
a) load a full-quality embedded preview
b) load a reduced quality embedded preview
c) load with RAW loader (automatic colors and white balance)

For the "fast" choice, a) + b) + c) are acceptable (in this order); for the
high quality choice, I would default to b) iff we can verify that the preview
is really full-quality - that was why I was asking if we can verify this.
For me it's all right to add a dependent non-default option "Always load RAW
files from actual RAW data" or a default option "Use full quality embedded
preview in RAW files".

We need to decide on the intended behavior; secondly we need to look at the
implementation and tweak it a bit.

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





--- Comment #10 from Matti Rintala <bitti cs tut fi>  2009-08-31 21:31:55 ---
I only have first-hand experience of Nikon raw files which to my knowledge all
store full-resolution jpg previews. But I think I have read that there are
other cameras where the preview is a thumbnail only. (Nikon have designed NEF
format to contain non-destructive editing information, so full-size preview is
a must-have thing).

But even for Nikon raw files the "quality" of embedded full-size preview
varies. Low-end models use much higher compression than high-end models (to
save space). And raw files edited with Capture NX2 have an extremely high-end
jpg preview (its size can be over 40 % of the raw file size in extreme cases).

To some people the size of the preview may be most important. But if the
compression is high, the quality may be too low to some people in some cases.
So I don't think there's any automatic way to know whether embedded jpg preview
is of acceptable quality to the user.

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


Gilles Caulier <[hidden email]> changed:

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




--- Comment #11 from Gilles Caulier <caulier gilles gmail com>  2009-08-31 22:34:41 ---
Marcel,

With last Exiv2, you can extract a specific preview that you want from RAW
file, if more than one is available. I don't know if libraw can do it too...

Gilles Caulier

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


Andreas Huggel <[hidden email]> changed:

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




--- Comment #12 from Andreas Huggel <ahuggel gmx net>  2009-09-01 03:48:06 ---
> With last Exiv2, you can extract a specific preview that you want from RAW
> file, if more than one is available.

Here is some info on this:
http://dev.exiv2.org/wiki/exiv2/Accessing_preview_images

Andreas

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





--- Comment #13 from Matti Rintala <bitti cs tut fi>  2009-09-01 12:08:42 ---
Gilles,

I'm not familiar with Digikam's internals, but I got the impression that raw
files' embedded previews are stored in exif data (at least in the raw files
I've worked with). So is libraw should not be needed for that?

Marcel,

In your second list, are choices a) and b) switched? I.e. reduced-size embedded
preview is better than fulls-size for fast preview)?

And yes, I think also that "high-quality" is a difficult concept with raw
previews.

The embedded preview is produced by camera or raw editing program, so it's
conversion parameters are probably better than Digikam's. Also, if dcraw -h
-style preview raw decoding is used by Digikam (is it?), raw-decoded preview is
only half-size (makes it worse for checking focus). If the raw file has been
edited (Capture NX2 etc.), the embedded preview is the only right option, since
there's no way to tell how much the image has been edited (without being able
to decode the editing metadata stored by the raw editor). So people using
Digikam only for photo management but not raw photo editing (that's me) need
embedded previews.

On the other hand, if the embedded preview is very small or of low quality,
then Digikam's raw decoding produces a better result. The same probably applies
if the user is going to edit the raw file in Digikam anyway (preview shows the
starting point).

My opinion is that the choice between embedded raw previews and raw decoding
should be user's. There's no way to know which is "high quality" for a
particular user's needs.

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


Gilles Caulier <[hidden email]> changed:

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




--- Comment #14 from Gilles Caulier <caulier gilles gmail com>  2009-09-01 12:34:07 ---
Matti,

Yes, RAW preview image is stored Exif, but in proprietary makernote tags. This
is not a standardized place.

2 way can be done to extrcat preview :

1/ libraw, as you can see with dcraw command line tool
2/ exiv2, but you need to parse file type to get right makernote tag.

Way 1/ is the most simple to do because libraw will analyze Raw format for you
automatically. This is the current way used in digiKam ,thrue libkdcraw
interface :

http://websvn.kde.org/trunk/KDE/kdegraphics/libs/libkdcraw/

You will find last libraw code here...

Currently, libkdcraw extract preview to emulate dcraw -e option :

http://lxr.kde.org/source/KDE/kdegraphics/libs/libkdcraw/libkdcraw/kdcraw.cpp#99

But i'm not sure if libraw API is able to select a specific preview image if
more that one is available. Perhaps Alex can guide us here...

Gilles Caulier

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





--- Comment #15 from Andreas Huggel <ahuggel gmx net>  2009-09-01 14:26:22 ---
Gilles,

> 2 way can be done to extrcat preview :
>
> 1/ [...]
> 2/ exiv2, but you need to parse file type to get right makernote tag.

No, it's transparent for the application. See the link I posted above.

Andreas

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

[Alex Tutubalin]

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





--- Comment #16 from Gilles Caulier <caulier gilles gmail com>  2009-09-01 14:39:54 ---
Andreas

Great. Thanks !

Gilles

--- Comment #17 from Alex Tutubalin <lexa lexa ru>  2009-09-01 19:21:29 ---
LibRaw is another story. LibRaw extracts only one preview (usually the largest
one) from RAW. There is no near plans to change this behavior in 0.8.x
(current) version.

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





--- Comment #18 from Matti Rintala <bitti cs tut fi>  2009-09-01 19:41:03 ---
I like Marcel's "speed / quality" idea for user preference.

How about a checkbox "Fast previews (limit preview size)"? When checked,
Digikam limits preview size (to display size or something) and tries to load
embedded preview for raw files (in future, maybe smallest preview that is at
least of required size) and scales it to preview size (just like now).

When that box unchecked, Digikam loads full-size preview for jpegs. Unchecking
the box also enables a sub-option check box "prefer embedded preview for raw
files". Checking it uses embedded preview (largest that can be found) without
scaling. If the option is unchecked, raw decoding preview is used.

Would this be clear enough? Or is it illogical that the sub-option becomes
available only you the main option is *not* checked? From my own experience I
hope that the main option text would mention both speed and the fact the
preview size is limited.

Of course the main option could be close to current "preview loads full image
size", but I think the wording could be improved somewhat.

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

[Marcel Wiesweg]

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





--- Comment #19 from Marcel Wiesweg <marcel wiesweg gmx de>  2009-09-01 20:05:56 ---
Gilles: It seems to me that exiv2 provides the superior mechanism here. It's
just what we need to decide in advance if we can use the preview for our
purpose.

Matti: For the sake of clarity, maybe to radio buttons and the second one with
the check box:
( ) Fast preview loading (limiting preview size)
(X) Load previews full size
    [X] Always prefer embedded preview for RAW files

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