[Digikam-devel] raw speed in gqview

[Arnd Baecker]

Hi,

before using digikam I used gqview
(http://gqview.sourceforge.net/) a lot.
Recent versions have quite a few interesting features,
in particular it can display the jpeg embedded in several
camera raw image formats.
It turns out that this is fast, i.e. noticeably faster than F3 in digikam.
E.g. for EOS 350D .cr2 files it takes digikam
a bit above 2s whereas gqview takes around 1s on my machine.
Moreover, changing back and forth between two images is instantaneous
(so obviously some caching is used for this.)

Don't get me wrong, I really think that digikam is great,
but the comparison with gqview shows (at least on my machine)
that the speed of display of both raw images and also jpg's
can be improved...
(I don't know the internals, but is it maybe
the interfacing with dcraw which eats up time
compared to gqview, which does not seem to make use of dcraw?)

Installation of gqview is straightforward and only takes a few minutes.
Just get
GQview 2.1.4 (development version) and go for
  mkdir /tmp/tst
  ./configure --prefix=/tmp/tst ;  make ; make install
  /tmp/tst/bin/gqview

Best,

Arnd


P.S.: http://bugs.kde.org/ seems down,
      """The connection has timed out. The server at bugs.kde.org
         is taking too long to respond."""
      This occurs to me already for a quite a while,
      and makes BKO unusable for finding out about previous wishes etc.


P.P.S: Other interesting features of gqview are the
       - nice pan-view mode,
           http://gqview.sourceforge.net/progress21.html
         (type  CTRL-J in a folder with many images ...)
       - quite flexible window layout
           http://gqview.sourceforge.net/view-shot.html
       - customization of the exif side-bar
           http://gqview.sourceforge.net/docs/7_1_exif.html
         (I think there was a B.K.O entry on this ....)



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

[Gilles Caulier-2]

On Wednesday 08 November 2006 09:35, Arnd Baecker wrote:

> Hi,
>
> before using digikam I used gqview
> (http://gqview.sourceforge.net/) a lot.
> Recent versions have quite a few interesting features,
> in particular it can display the jpeg embedded in several
> camera raw image formats.
> It turns out that this is fast, i.e. noticeably faster than F3 in digikam.
> E.g. for EOS 350D .cr2 files it takes digikam
> a bit above 2s whereas gqview takes around 1s on my machine.
> Moreover, changing back and forth between two images is instantaneous
> (so obviously some caching is used for this.)

This is the same way : dcraw extraction. In fact the method used by both
programs is the same.

The diference can be explained like this :

- digiKam use a kioslave, and this can be slowest than to use a direct loading
on the main app thread.
- digiKam use an embedded dcraw implemention witch is compiled with the same
option than digiKam. If you is in debug, dcraw will do it too.
- digiKam do not use a cache mecanism. This is the real problem than we will
fix in the future.

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

[Arnd Baecker]

On Wed, 8 Nov 2006, Gilles Caulier wrote:

> On Wednesday 08 November 2006 09:35, Arnd Baecker wrote:
> > Hi,
> >
> > before using digikam I used gqview
> > (http://gqview.sourceforge.net/) a lot.
> > Recent versions have quite a few interesting features,
> > in particular it can display the jpeg embedded in several
> > camera raw image formats.
> > It turns out that this is fast, i.e. noticeably faster than F3 in digikam.
> > E.g. for EOS 350D .cr2 files it takes digikam
> > a bit above 2s whereas gqview takes around 1s on my machine.
> > Moreover, changing back and forth between two images is instantaneous
> > (so obviously some caching is used for this.)
>
> This is the same way : dcraw extraction. In fact the method used by both
> programs is the same.

Looking at gqview's source:
format_canon.c was a patch by D.M. German,
  and a link to http://turingmachine.org/~dmg/libdcraw/gqview/
is given.
For format_fuji.c, format_nikon.c and format_raw.c
it is stated that
"Original version 2005 Lars Ellenberg, base on dcraw by David coffin."

But since then it seems (at least according to the CVS history)
no direct transfer of from David Coffins dcraw has happened.
So this code-base has been developed separately from then on.
(I.e.: if newer versions of dcraw are much slower than
the one around 2005, this might explain also part of the speed difference)


> The diference can be explained like this :
>
> - digiKam use a kioslave, and this can be slowest than to use a direct loading
> on the main app thread.

So this could be the main reason for the approx. factor of
2 speed difference.
Hmm, if this is true, another reason to go for the
"libkdcraw" library you suggested?

> - digiKam use an embedded dcraw implemention witch is compiled with the same
> option than digiKam. If you is in debug, dcraw will do it too.

I just checked my installation log and all I find is "-O2",
(in contrast, the gqview I compiled had:  "-g -O2")

> - digiKam do not use a cache mecanism. This is the real problem than we will
> fix in the future.

That would indeed be great!

I think there was a B.K.O entry on this ...
Whom could one ask to get BKO working again (or is it just me having
problems??). I can successfully ping to bugs.kde.org, but no http
requests work.

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

[Gilles Caulier-2]

On Wednesday 08 November 2006 10:23, Arnd Baecker wrote:

> On Wed, 8 Nov 2006, Gilles Caulier wrote:
> > On Wednesday 08 November 2006 09:35, Arnd Baecker wrote:
> > > Hi,
> > >
> > > before using digikam I used gqview
> > > (http://gqview.sourceforge.net/) a lot.
> > > Recent versions have quite a few interesting features,
> > > in particular it can display the jpeg embedded in several
> > > camera raw image formats.
> > > It turns out that this is fast, i.e. noticeably faster than F3 in
> > > digikam. E.g. for EOS 350D .cr2 files it takes digikam
> > > a bit above 2s whereas gqview takes around 1s on my machine.
> > > Moreover, changing back and forth between two images is instantaneous
> > > (so obviously some caching is used for this.)
> >
> > This is the same way : dcraw extraction. In fact the method used by both
> > programs is the same.
>
> Looking at gqview's source:
> format_canon.c was a patch by D.M. German,
>   and a link to http://turingmachine.org/~dmg/libdcraw/gqview/
> is given.
> For format_fuji.c, format_nikon.c and format_raw.c
> it is stated that
> "Original version 2005 Lars Ellenberg, base on dcraw by David coffin."
>
> But since then it seems (at least according to the CVS history)
> no direct transfer of from David Coffins dcraw has happened.
> So this code-base has been developed separately from then on.
> (I.e.: if newer versions of dcraw are much slower than
> the one around 2005, this might explain also part of the speed difference)

Perhaps, but the last dcraw release support more RAW files preview extraction,
ARW from Sony for example. For that i prefert used the dcraw extraction witch
support all new RAW file format very quickly.

>
> > The diference can be explained like this :
> >
> > - digiKam use a kioslave, and this can be slowest than to use a direct
> > loading on the main app thread.
>
> So this could be the main reason for the approx. factor of
> 2 speed difference.
> Hmm, if this is true, another reason to go for the
> "libkdcraw" library you suggested?

yes, using a Qthread to unfrezze the GUI.

>
> > - digiKam use an embedded dcraw implemention witch is compiled with the
> > same option than digiKam. If you is in debug, dcraw will do it too.
>
> I just checked my installation log and all I find is "-O2",
> (in contrast, the gqview I compiled had:  "-g -O2")
>
> > - digiKam do not use a cache mecanism. This is the real problem than we
> > will fix in the future.
>
> That would indeed be great!

yes, and this will the first way to do.

>
> I think there was a B.K.O entry on this ...

yes, there is.

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