Replace dcraw with faster raw decoder (libraw?)

[Beep6581]

Originally reported on Google Code with ID 594

This is an enhancement suggestion.

dcraw is not optimized for speed, which shows as rather slow loading times of RAW files
compared to the competition. When working with RawTherapee, I think the slow loading
times is disturbing so it would be valuable with an improvement.

libraw is based on dcraw and does (so far) not provide much speed improvement.

It seems like Klaus Post's RawSpeed library could be a good alternative though, currently
used in RawStudio and Darktable.

A quick test made on my workstation showed that a .CR2 (canon RAW) that took 1800 ms
to unpack (only unpacking measured, no post-processing) with dcraw took 580 ms with
RawSpeed. A .NEF (Nikon RAW) file that took 1370 ms to unpack with dcraw took 680 ms
with RawSpeed. That is 2 - 3 times faster, and the difference between 1,8 and 0,6 seconds
load time is certainly noticed by the user.

The drawback with RawSpeed is that it does not support all formats, so you need to
have a solution where you combine that and dcraw/libraw, which Darktable currently
does.

Reported by torger@ludd.ltu.se on 2011-03-23 15:04:12

[Beep6581]

Changed tagging

Reported by oduis@hotmail.com on 2011-03-27 22:03:28

• Labels added: Type-Enhancement
• Labels removed: Type-Defect

[Beep6581]

I think this is a great idea! RawStudio certainly loads raw files a lot faster than
RawTherapee.

Reported by borissimo86 on 2011-05-07 01:27:53

[Beep6581]

I try to clean our bug-tracker a bit: What's the status here?

Is it 'WontFix' or is somebody willing to implement this? I'll close it 'WontFix' in
a week if nobody complains.

Reported by rinni@gmx.net on 2013-01-28 22:42:34

[Beep6581]

Nothing done on this AFAIK. Dcraw is still slow, and it is still possible to integrate
rawspeed. However, in terms of a cleanup I think it is ok to set it to wontfix, we
can return to it later sometime when someone feels the urge to make performance improvements.

However, do we need to close these issues? Isn't keeping them at low priority enhancements
a good enough filter? I won't protest if you close it though :-)

Reported by torger@ludd.ltu.se on 2013-01-29 08:49:08

[Beep6581]

I'd prefer to keep low priority issues opened. I've updated the labels accordingly.

Reported by natureh.510 on 2013-01-29 15:01:46

• Status changed: Accepted
• Labels added: OpSys-All, Performance, Maintainability

[Beep6581]

May be a better solution would be Libraw. It already embeds Rawspeed and the user can
toggle between Rawspeed and Dcraw engine, useful for some formats that are not supported
by Rawspeed.

I think it would be a good thing two active and accessible (unlike Dave)open source
teams to join forces.  

Reported by iliasgiarimis on 2013-01-29 15:56:18

[Beep6581]

Yes, I think Libraw[1] would be the option to go as it's a library with stable API whereas
Rawspeed[2] is not a separate library and we would have similar issues as with dcraw
(besides the speed).

[1] http://www.libraw.org
[2] http://rawstudio.org/blog/?p=800

Reported by rinni@gmx.net on 2013-02-04 20:51:31

[Beep6581]

1. Would libraw offer any speed improvements vs dcraw?
2. If we use libraw, can RT still use its internal demosaicing?

Reported by michaelezra000 on 2013-02-04 21:12:15

[Beep6581]

3. With libraw, could we still use custom camera matrices, or the only way to use them
would be custom DCP profiles?

Reported by michaelezra000 on 2013-02-04 21:13:47