[Digikam-devel] [Bug 132047] New: Faster display of images and/or prefetch wished for

[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=132047         




------- Additional Comments From arnd.baecker web de  2008-03-20 10:52 -------
It feels solved - many thanks!
Still I have two questions:
a) how large is the cache size (it seems that
   around 3-4 Raws are kept in memory)?
   Could/should one make this configurable?
b) When being in preview mode (with loading of the full image
   marked as active), there is something which puzzles me:
   Using PageDown for the sequence  
     IMG_8305.CR2  
     IMG_8306.CR2
     IMG_7061.CR2  
   I get the following  dcraw commands
   shown on the konsole :
   - Still in thumbnail view (i.e. initial start):
     kdcraw -c -v -4 -h -H 0 -b 1 -w -q 0 -o 1 IMG_8305.CR2
   - then preview:
     kdcraw -c -v    -h -H 0 -b 1 -w -q 0 -o 1 IMG_8305.CR2
     kdcraw -c -v    -h -H 0 -b 1 -w -q 0 -o 1 IMG_8306.CR2
       (i.e preloading works!)
   - then PageDown
     kdcraw -c -v    -h -H 0 -b 1 -w -q 0 -o 1 IMG_7061.CR2
     kdcraw -c -v -4 -h -H 0 -b 1 -w -q 0 -o 1 IMG_8306.CR2

     Question: what is the -4 variant being used for ?

   Such a command sometimes also gets triggered for images, which apparantly
   are still in cache (at least the display is instantaneous)?
_______________________________________________
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=132047         




------- Additional Comments From caulier.gilles gmail com  2008-03-20 13:43 -------
Arnd,

"-4" option is dedicated to handle 16 bits color depth. Perhaps are you enabled  histogram on righ side bar which render stat using 16 bits color depth... And yes, in this case, both version are loaded in memory... it's not optimum (:=)))

Gilles
_______________________________________________
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=132047         




------- Additional Comments From arnd.baecker web de  2008-03-20 17:24 -------
Well, I did not really enable the histogramm ;-) The right side-bar
was closed, however, it seems that the histogramm is still computed
in the background.
So in view of this bug here, everything is fine!
However, I will have to open new (separate) bugs for
a) don't load histogram if it is not visible
b) optimize memory usage/speed for histogram computation (i.e. re-use
   the data in memory, if availble)
c) there is no histogram for raws (only in log scale you see something)
d) allow full size preview (i.e. a 100% view should be a 100% and not a 50% one)

Best, Arnd
_______________________________________________
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=132047         




------- Additional Comments From marcel.wiesweg gmx de  2008-03-21 15:32 -------
For RAW images, the situation is complex, because there is the preview (jpeg from metadata), the full size preview (fast dcraw loading, 8bit), the image for the histogram (fast dcraw loading, 16 bit), and the full 16-bit image for the editor.

We usually try to reuse as much cached image as possible, but priority is to load as fast as possible, and when then a higher-quality version is required, the already loaded data must be discarded. There is infrastructure to handle the event of a concurrent "more complete loading event": If the histogram is loading an image, and then the image editor begins to load, the histogram is notified and can decide to cancel its own operation and wait on the other.
Worst case is: First thumbnail generation, then preview, then histogram, then editor. This results in four subsequent dcraw calls. But we cannot avoid that: We dont know in advance what the user decides, and if he only wants the preview, we cannot accept to load the full version, which takes much longer, only because the user could choose to need in the next time. We cache what we have, we use higher-quality cached images if lower-quality is requested, and we can handle concurrent operations, cancelling the lower for the higher quality load.

Now we could go on and wait in the preview for the 16 bit image from histogram: Gilles, is this now possible after your auto coloradjustment feature for 16bit raws? Previously, the histogram image could not be reused for viewing.

You see that it is complex to decide what image can be used for what purpose,
_______________________________________________
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=132047         




------- Additional Comments From caulier.gilles gmail com  2008-03-22 10:00 -------
Marcel,

>Now we could go on and wait in the preview for the 16 bit image from histogram: >Gilles, is this now possible after your auto coloradjustment feature for 16bit >raws? Previously, the histogram image could not be reused for viewing.

Yes, it's possible, but there is many points where we need to take a care :

- 1st, there is 2 way to get preview : embeded JPEG or half decoded raw image.
- 2nd, histogram is currently always computed in 16 bits color depth with RAW.
- 3rd, preview is always in 8 bits color depth.
- 4th, editor never use half RAW decoded image but full RAW decoded image instead.

Like 8 and 16 bits color depth RAW decoding have the same auto-gamma now, and if preview != embeded JPEG, i propose :

- to always use the same bits depth everywhere to compute preview and histogram
- to use the same image to compute histogram and preview.
- to always use the same settings about RAW color depth handling everywhere.

This way will simplify all RAW cache operations and will optimize memory consumptions.

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