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

------- 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         
           Summary: Faster display of images and/or prefetch wished for
           Product: digikam
           Version: unspecified
          Platform: Debian testing
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: general
        AssignedTo: digikam-devel kde org
        ReportedBy: kdebug mail 4brad com


Version:           1:0.9-beta1-2 (using KDE KDE 3.5.4)
Installed from:    Debian testing/unstable Packages

You can never have enough speed.  I've been moving to digikam from other applications, and some of them are a great deal faster at display of today's large jpegs.   Some of them, like kuickshow, are just plain fast at rendering a jpeg.   Go steal its code!  pho is also fast, so is xzgv.

Another technique that can be very useful is to pre-fetch the next and/or previous image and render them in memory, or even in hidden windows/video card buffers.  RAM (screen sized ram anyway) is cheap.   Then the switch can be instant if the user has paused.  Do it in a niced background thread of course.

Digikam is much more full featured than most other programs, but once you get used to speed, it's very hard to give up speed, the features must be very compelling.  Now that digikam has the ability to do ratings, tags and comments in the large picture view (which is a must for me) the speed of going to the next picture in this view becomes important.

Some programs are also clever, and if they see the screen is much smaller than the image (as is typical) they will do a much faster cheap jpeg decode which does not extract all pixels.  Of course that means more time if the image needs zoom.   Clever programs do the mini render and have another background thread do the full render or any more complex processing.
_______________________________________________
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         
marcel.wiesweg gmx de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |wishlist
             Status|UNCONFIRMED                 |NEW
      everconfirmed|0                           |1



------- Additional Comments From marcel.wiesweg gmx de  2006-08-08 16:29 -------
Your suggestions for fast rendering are important optimisations. For a viewer. Please note that digikam currently has no viewer, only an image editor. (Showfoto is supposed to be a viewer, but in its heart it is an editor)

As the image editor is an editor, it needs the full pixels at any time. Btw, only for JPEGs it is possible to save time loading in a lower resolution.
We can preload the next image, that costs RAM (image size), but no problem.
Rendering cannot be done in a background thread, it must be done in a foreground thread (it is X server communication in the end).

That does not mean we cannot have a dedicated speed-optimized viewer for image _watching_, fully integrated with all sidebar stuff of course, allowing nice slideshows, easily opening the IE if editing is needed.
_______________________________________________
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=132047         




------- Additional Comments From kdebug mail 4brad com  2006-08-08 22:44 -------
Thanks.   My personal taste is I want gimp or other such tools for my true editing, and from my photo organizer I want to edit captions, tags and albums most.  Though of course many people do minor edits in photo organizers.  (Rotate is not so much an edit, since to be lossless for jpeg it usually involves re-reading the file.)

However, I come to digikam mainly for organizing, and it has the potential to be the best at that.   Right now the main barriers are the various beta bugs and crashes (since I am using the 9-beta1-2) which will of course go away, and the speed.   I have a number of other things I would like ( http://ideas.4brad.com/archives/000189.html ) but I think speed is the key missing element.

When I refer to rendering, I mean the decompression of the jpeg, what the editor is doing when it says "loading" with a status bar.  That (and also the scaling down to the planned viewing size) can be done in a background thread for the predicted next picture.   Then when it's time to display, a foreground thread w ould send the graphics to the X-server.   (Though on many displays now it is possible, I believe, to send it in advance to a hidden area, and then reveal the area for a truly instant display.  That's more important for slideshows than image management.)

If you've tried out kuickshow/pho/xzgv you will have seen how much faster they can move from one picture to the next, without pre-fetch.  If you try out gqview, you will see it's not as fast on the loading but does the pre-fetch.

RAM, as we know today, costs about $70 per gigabyte.  8 megapixel images require 24mb.   Who would not spend $1.68 in memory per picture to get lighting response.   If you store it at viewing size, it's probably just 6MB for 1600x1200 screens.  I have a 2560x1600 screen but I can handle it.
_______________________________________________
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=132047         
gilles vonet lu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gilles vonet lu
_______________________________________________
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=132047         




------- Additional Comments From mikmach wp pl  2006-08-28 12:11 -------
Isn't F3 action opening image viewer?
_______________________________________________
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=132047         




------- Additional Comments From kde_bugs hubbertz de  2006-09-07 00:22 -------
100% ACK to Brad Templeton.

digikam is a really great photo organizer. So it's a pitty that I usually usw kuickshow to actually view my photos because digikam is that slow.... :-(


BTW: I haven't heard of the F3 action before. "View Image" should belong into the context menu not only the main menu bar. This viewer is exactly what I want (as you have access to all digikam functions with its hotkeys (rating etc.), but it's still too slow in showing the next image.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier]

------- 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         
caulier.gilles free fr changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|general                     |Albums GUI



------- Additional Comments From caulier.gilles free fr  2006-09-08 16:57 -------
Ian,

I know the problem about F3 preview mode speed. Look my comments #2 in B.K.O #133590

When i said that it's a _FAST_ preview mode, it's true with :

* _ALL_ raw files type (500ms-1000ms instead 10s-20s depending of your computer speed).
* _ALL PNG or TIFF file saved with digiKam image editor, witch save a preview image in IPTC metadata ((500ms-1000ms instead 3s-5s)

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

[Gilles Caulier]

------- 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 free fr  2006-09-08 19:07 -------
SVN commit 582220 by cgilles:

digikam from trunk : add link to image preview feature into album icon item popup menu.
CCBUGS: 132047

 M  +11 -5     albumiconview.cpp  
 M  +2 -1      albumiconview.h  
 M  +5 -2      digikamview.cpp  


--- trunk/extragear/graphics/digikam/digikam/albumiconview.cpp #582219:582220
 @ -107,13 +107,14  @
 #include "cameradragobject.h"
 #include "dragobjects.h"
 #include "dmetadata.h"
-#include "albumiconitem.h"
-#include "albumicongroupitem.h"
-#include "albumiconview.h"
 #include "albumdb.h"
 #include "imageattributeswatch.h"
 #include "dcrawbinary.h"
 #include "deletedialog.h"
+#include "albumiconitem.h"
+#include "albumicongroupitem.h"
+#include "albumiconview.h"
+#include "albumiconview.moc"
 
 namespace Digikam
 {
 @ -505,6 +506,7  @
     // --------------------------------------------------------
 
     QPopupMenu popmenu(this);
+    popmenu.insertItem(SmallIcon("viewimage"), i18n("View..."), 18);
     popmenu.insertItem(SmallIcon("editimage"), i18n("Edit..."), 10);
     popmenu.insertItem(i18n("Open With"), &openWithMenu, 11);
     popmenu.insertSeparator();
 @ -657,6 +659,12  @
           slotSetAlbumThumbnail(iconItem);
           break;
       }
+
+      case 18:
+      {
+          signalPreviewItem(iconItem);
+          break;
+      }
   
       default:
           break;
 @ -1838,5 +1846,3  @
 }
 
 }  // namespace Digikam
-
-#include "albumiconview.moc"
--- trunk/extragear/graphics/digikam/digikam/albumiconview.h #582219:582220
 @ -113,8 +113,9  @
 
 signals:
 
+    void signalPreviewItem(AlbumIconItem*);
     void signalItemsAdded();
-    void signalItemDeleted(AlbumIconItem* iconItem);
+    void signalItemDeleted(AlbumIconItem*);
     void signalCleared();
 
 public slots:
--- trunk/extragear/graphics/digikam/digikam/digikamview.cpp #582219:582220
 @ -69,6 +69,7  @
 #include "dio.h"
 #include "digikamapp.h"
 #include "digikamview.h"
+#include "digikamview.moc"
 
 namespace Digikam
 {
 @ -226,6 +227,10  @
     connect(d->iconView, SIGNAL(signalItemsAdded()),
             this, SLOT(slotAlbumHighlight()));
 
+    connect(d->iconView, SIGNAL(signalPreviewItem(AlbumIconItem*)),
+            this, SLOT(slot_imagePreview(AlbumIconItem*)));
+
+
     //connect(d->iconView, SIGNAL(signalItemDeleted(AlbumIconItem*)),
       //      this, SIGNAL(signal_noCurrentItem()));
 
 @ -977,5 +982,3  @
 }
 
 }  // namespace Digikam
-
-#include "digikamview.moc"
_______________________________________________
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=132047         
caulier.gilles kdemail net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |krienke uni-koblenz de



------- Additional Comments From caulier.gilles kdemail net  2006-12-11 15:00 -------
*** Bug 133590 has been marked as a duplicate of this bug. ***
_______________________________________________
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  2006-12-12 08:26 -------
Just pasting a part of my comment from 133590 so that it does not get lost:

What gqview does (if the next image has not yet already been
loaded in the background, e.g. when trying to go through many images
too quickly) is  to incrementally display
the new image starting from the top.
By this it is at least possible to decide earlier to move on or not.
Not sure whether this is possible with the widget used for the display.
_______________________________________________
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  2007-01-03 22:44 -------
SVN commit 619531 by mwiesweg:

Loading of previews is now multithreaded:
- integrate preview loading into the load-save framework
- the PreviewLoadTask is a cut-down version of the normal SharedLoadingTask
- use the same cache

CCMAIL: digikam-devel kde org



 M  +0 -1      digikam/Makefile.am  
 M  +31 -43    digikam/imagepreviewwidget.cpp  
 M  +4 -4      digikam/imagepreviewwidget.h  
 M  +4 -0      libs/threadimageio/Makefile.am  
 M  +11 -3     libs/threadimageio/loadingcache.cpp  
 M  +24 -0     libs/threadimageio/loadingdescription.h  
 M  +1 -1      libs/threadimageio/loadsavetask.cpp  
 M  +1 -1      libs/threadimageio/loadsavetask.h  
 M  +13 -3     libs/threadimageio/loadsavethread.cpp  
 M  +40 -0     libs/threadimageio/managedloadsavethread.cpp  
 M  +1 -0      libs/threadimageio/managedloadsavethread.h  
 A             libs/threadimageio/previewloadthread.cpp   [License: GPL]
 A             libs/threadimageio/previewloadthread.h   [License: GPL]
 A             libs/threadimageio/previewtask.cpp   [License: GPL]
 A             libs/threadimageio/previewtask.h   [License: GPL]
_______________________________________________
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=132047         




------- Additional Comments From kdebug mail 4brad com  2007-01-04 00:44 -------
Multithreading is great since I do have dual core.  But it still doesn't hold a candle to what pre-decompress gets you or plain old faster jpeg decoding as you would get by just taking the code of the other programs.

What might make sense is to have two modes of full-size preview, one of which allows more complex modifications to the image directly, and the other of which requires the image be re-loaded before most pixel modifications (rotate and flip should be possible without re-load since they can be done lossless on the file as in thumb mode.)

This would allow the very fastest loads which are, for large images, only needing 1/4 of the pixels or less.

Now I have to admit, the speed is getting pretty good for me on my dual core Intel 6600, but that's one of the faster systems out there.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

------- 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 kdemail net  2007-01-04 07:53 -------
Brad,

>Multithreading is great since I do have dual core.  But it still doesn't hold a candle to what >pre-decompress gets you or plain old faster jpeg decoding as you would get by just taking >the code of the other programs.
 
No need to re-invent the wheel to take the code from other programs. The image loader implementation are very similar and cannot be optimized anymore. The ultimate optimization to do is to preload in background to the cache the next and previous image around the current selected image from current album.

Kuickshow and digiKam image editor < 0.9 use this mechanism with imlib2 library.

>What might make sense is to have two modes of full-size preview, one of which allows >more complex modifications to the image directly, and the other of which requires the >image be re-loaded before most pixel modifications (rotate and flip should be possible >without re-load since they can be done lossless on the file as in thumb mode.)

This is out of context of this file. Please open a new wish.

Other optimizations to speed-up the drawing of pictures on the screen can be done using Qt4. No need to re-invent the wheel again...

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

[Arnd Baecker]

> The ultimate optimization to do is to
> preload in background to the cache the next and previous image
> around the current selected image from current album.

One might even think of:
- preloading the next (e.g.) 2-5  images in the background
- keep the last viewed (e.g.) 2-5 images in the cache

The precise numbers + an upper RAM limit for the cache
should be configurable by the user according to his preferences/resources.

Best, Arnd
_______________________________________________
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  2007-01-04 08:34 -------
> The ultimate optimization to do is to
> preload in background to the cache the next and previous image
> around the current selected image from current album.


One might even think of:
- preloading the next (e.g.) 2-5  images in the background
- keep the last viewed (e.g.) 2-5 images in the cache

The precise numbers + an upper RAM limit for the cache
should be configurable by the user according to his preferences/resources.

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  2007-01-04 12:46 -------
The last viewed images are kept in the cache, until it is full. (If a full-blown version is in the cache, it is used as well btw)

For preloading there is a requirement that we dont meet currently: The ability to stop the loading. We can do this with the DImg loaders, but the preview is based on QImage.

I'm currently wondering if it is desirable to use the cheap-loading optimization for JPEGs, that is also used in the thumbnail loader.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Arnd Baecker]

> The last viewed images are kept in the cache, until it is full. (If
> a full-blown version is in the cache, it is used as well btw)

I see - very nice.
How large is that cache (presently that size is
not configurable, right?)?

> I'm currently wondering if it is desirable to use the cheap-loading
> optimization for JPEGs, that is also used in the thumbnail loader.

If that would bring speed-improvements, why not? ;-)
_______________________________________________
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  2007-01-04 12:55 -------
> The last viewed images are kept in the cache, until it is full. (If
> a full-blown version is in the cache, it is used as well btw)


I see - very nice.
How large is that cache (presently that size is
not configurable, right?)?

> I'm currently wondering if it is desirable to use the cheap-loading
> optimization for JPEGs, that is also used in the thumbnail loader.


If that would bring speed-improvements, why not? ;-)
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Mircea Bardac]

------- 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         
bug-report mircea bardac net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bug-report mircea bardac net
_______________________________________________
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=132047         
cimmo libero it changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cimmo libero it
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel