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

Marcel Wiesweg marcel.wiesweg at gmx.de
Fri Mar 21 14:32:07 GMT 2008


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



More information about the Digikam-devel mailing list