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

[Arnd Baecker]

Hi,

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

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?

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?
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

>
> 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?
Gilles is much familiar with dcraw, I am not.

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

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

Marcel

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

[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
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

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

You are right, something is wrong...Some images are not cached...
TODO list is growing, time is rare :-(

>
> > 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?)

The cache size is fixed, 40MB or 60MB, don't know. Took that number from some
older implementation from Renchi.

>
> Just some dreams of a happy end-user ;-),
>
> Many thanks for all your great work,
>
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-2]

Le Lundi 31 Juillet 2006 10:39 PM, Marcel Wiesweg a écrit :
> What happens if we remove the "-2"? It seems it was the default, so it is
> not really needed for <8.27?
> Gilles is much familiar with dcraw, I am not.

Yes Marcel, We can remove dcraw '-2' option everywhere. With all dcraw
version, 8 bits RAW decoding is the default mode if we don't use this option.

But, this is a main problem if the dcraw author don't repect a compatibility
with all options between eatch dcraw versions...

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