[Digikam-devel] dcraw v8.27, -2 option problem

[Arnd Baecker]

Hi Marcel,

thanks for your reply!

On Mon, 31 Jul 2006, Marcel Wiesweg wrote:

> >
> > I just installed digikam from cvs and also upgraded my dcraw.
> >
> > With dcraw v8.27 I get:
> >
> > digikam: /home/abaecker/Pictures/EOS350D/IMG_1940.CR2 : RAW file
> > identified
> > Warning: Directory Canon has an unhandled next pointer.
> > Warning: Size 5352 of Exif.Canon.0x4002 exceeds 4096 bytes limit. Not
> > decoded.
> > digikam: Running dcraw command
> > (dcraw,-c,-2,-w,-a,-o,1,/home/abaecker/Pictures/EOS350D/IMG_1940.CR2)
> > digikam: Dcraw StdErr: Unknown option "-2".
> > kio_digikampreview: Running dcraw command dcraw -c -e
> > '/home/abaecker/Pictures/EOS350D/IMG_1940.CR2'
> > kio_digikampreview: Using embedded RAW preview extraction
> >
> > With dcraw  v8.11 everything works (apart from the speed, see P.S.)
> >
> > The origin of the problem is that
> > the option
> > -2        Write 8-bit non-linear PPM (default)
> > does not exist in  v8.27
>
> What happens if we remove the "-2"? It seems it was the default, so it is not
> really needed for <8.27?

Sounds reasonable to me. Otherwise a version detection of dcraw
might be necessary - umpf...

> Gilles is much familiar with dcraw, I am not.

Me neither ;-)

> > Best, Arnd
> >
> >
> > P.S.: on my slow PIII, 1.2 GHz laptop, with dcraw v8.11,
> > the steps:
> > kio_digikampreview: Running dcraw command
> >    dcraw -c -e '/home/abaecker/Pictures/EOS350D/IMG_1941.CR2'
> > kio_digikampreview: Using embedded RAW preview extraction
> > digikam: Parsed PPM header: width 1157 height 1737 rgbmax 61408
> > digikam: Parsed PPM header: width 2314 height 3474 rgbmax 255
> >
> > take about 50s. Is it expected to be that slow?
>
> There is a problem wit raw files that the histogram loads the half-size
> version and IE loads the full size version concurrently. I am still thinking
> of a solution for this.
> Maybe 25 s is ok for your PIII.

I fear so ;-), raw stuff is demanding and
it is a nowadays slow machine for this types of task
(even worse, I don't have much disk space, so when "in the field"
I have to store files on an external disk, attached via USB 1.1. ;-()


> > P.P.S.: BTW, digikam really rocks - only for browsing through
> > a sequence of images I still use gqview which is quite a bit
> > faster (I think that one of the (if not *the*) main factor is
> > that gqview caches the next picture in the row).
> > Do you intend to implement caching of images/histogramms etc.
> > for 0.9, or is this a possible post 0.9 feature?
>
> We are caching images.

In what situation?
For example, if I have two 3.5 MB (8Mpx) .jpg and have the "Colors"
sidebar with the histogram open, changing back-and-forth
between these images, one gets "Loading imae" and
then "Histogram calculation in progress".

In the Image Editor it takes a bit more than 4s to move
from one image to the next (again, on my slow machine).
Going back to the previous images takes the same amount
of time.
So to me it does not *feel* as if there was any caching,
but maybe I am doing things the wrong way ...

> Currently, we do not preload. The infrastructure is
> there, it's probably only a few lines of code. I decided not to do it because
> there were some problems, don't know what exactly any more.

I see. Yes, preloading would be very nice
(maybe even something like the next n images, with n being
user-adjustable, as it depends on the amount of available RAM,
and caching of images/histograms of m previous images?)

Just some dreams of a happy end-user ;-),

Many thanks for all your great work,

Arnd