[Digikam-devel] Experimental : image preview on main interface

Caulier Gilles caulier.gilles at kdemail.net
Fri Jun 16 21:50:37 BST 2006

Le Jeudi 15 Juin 2006 22:10, Marcel Wiesweg a écrit :
> > Hi all,
> >
> > Following some reports from B.K.O and discussions by IRC/mails, some
> > users would to have a preview mode of current album item, directly in
> > main interface, without to start an instance of image editor. Image
> > editor take a while with old computer to just previewing a RAW picture.
> >
> > I have search a simple solution to do it.... and this is my proposal :
> >
> > http://digikam3rdparty.free.fr/Screenshots/image_preview_on_main_interfac
> >e. png
> >
> > I have make an experimental patch using QWidgetStack to embed into album
> > collection area a new image preview. You toogle between preview and album
> > view using F3.
> >
> > The patch is here :
> >
> > http://digikam3rdparty.free.fr/misc.tarballs/preview.patch
> >
> > The RAW preview use the -e dcraw option to load the embedded JPEG image
> > in RAW file (used to display a RAW picture on TV screen)
> >
> > This patch separate Preview mode (F3) and the Edit mode (F4) on Image
> > menu entries. If you enable the ImageProperties sidebar, use the navigate
> > button to change the current image to preview.
> >
> > This code is simple and not finalized. For example the code :
> >
> > - don't use a cache to speed up rendering.
> > - don't use the embedded preview from JPEG/TIFF/PNG files available in
> > Makernote metadata. Canon, Nikon, Minolta, etc, record a small preview
> > image in Camera Settings. This is must be used instead to load the whole
> > image. In fact, Exiv2 need to be improved for that. i'm currently working
> > with Andreas about this subject.
> > - use QImage, not Dimg.
> > - don't load the preview using a separate thread to unfreeze ther GUI
> > (Image Editor do it). We can use a new KIO slave for that but not sure
> > (Marcel, your viewpoint ?)
> I am wondering if the following is true:
> The image histogram can use (if found in cache)
> 1. The dcraw loaded image
> 2. The dcraw loaded image with halfSizeColor
> 3. The preview image??
> The preview can use (if found in cache)
> 1. The dcraw loaded image
> 2. The embedded preview image
> The image editor can use (if found in cache)
> 1. The dcraw loaded image
> The image histogram will load
> the dcraw loaded image with halfSizeColor
> The preview will load
> the embedded preview image
> The image editor will load
> the dcraw loaded image
> I'm not familiar with some important facts here, so please correct me.
> If we can create a hierarchy like the one above, we can implement this in
> the LoadingCache. I just yesterday began to write something similar to
> integrate the halfSizeColor images (I know I wrote I'd fix it "till
> tomorrow", but it's football world cup)

It's can be complex to trying to mix loading whole image using DImg and only a 
preview. The implementation is different. Why not using a KIO slave like with 
thumb generator ?

> > Please don't ask me to create a very advanced new feature for 0.9.0. I
> > have not commited this code in svn because i'm not sure if this is the
> > right way to implement an image previewing. Also to finalize properlly
> > this code, we need more time, and i would delay this implementation later
> > 0.9.0.
> If I had enough time I'd anyway love to write a really cool
> grandma-compatible highly integrated presentation mode (tm), think of KPDF,
> optimized for viewing. Talking about advanced features.
> If your current solution works, i.e. it shows images properly and nothing
> else, that's IMO a good and pragmatic solution for 0.9.[0,1].

in fact with this implementation we can kill these 3 B.K.O files :


The code to load image is embedded in GUI thread. It's fast with RAW file, but 
can take a while with JPEG, PNG, TIFF (QImage loading the whole image).


More information about the Digikam-devel mailing list