Project

General

Profile

Feature #8336

Please implement AMaZE / DCB demosaicing algorithms to dt core

Added by Krzysztof Pijarski - over 8 years ago. Updated over 8 years ago.

Status:
Fixed
Priority:
High
Assignee:
-
Category:
-
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Affected Version:
System:
bitness:
64-bit
hardware architecture:
amd64/x86

Description

I am immensely impressed by the massive speedup caused by porting the ppg to dt and using rawspeed / opencl. On the other hand, PPG is very much inferior to DCB and especially AMaZE, that seems to be the best algorithm out there ATM.
In comparison to those two, PPG is handicapped as to the handling of high frequency detail and color artifacts and sharpness in general. When you look at the attached details, you will see how much better AMaZE handles the inscription on the door, and the wire fence, also note the general absence of color artifacts. (And I did use automatic chroma abberation correction in dt - it already made the problem a bit better.) In both samples (developed with RawTherapee 3.0 freshly compiled from mercurial), I used 2 false color suppresion steps, and one iteration + enhancement step in the case of DCB. In all the samples I applied a comparable amount of USM.

You will find the samples here: http://www.dropbox.com/gallery/544347/1/demosaic?h=9b7403

History

#1 Updated by André Reinald over 8 years ago

I have been following DarkTable for over 2 months now, updating it from GIT and building it daily. I even bought a modern PC to be able to use it fully as DarkTable is very RAM hungry.

But I agree with the point above : although the accelerated PPG algo is an impressive usability improvement, it gives UNACCEPTABLE results in many cases. I gave up RawStudio a while ago for the same reasons : maze patterns and color artifacts in the converted images.

Now it seems only RawTherapee implements DCB, EAHD and AMaZE, which most people (including me) consider the best algorithms. But its interface is far behind DarkTable's.

To make long talks short : PLEASE, put back the traditional algos from LibRaw, and give the user the option to choose between LibRaw and RawSpeed for demosaicing.

#2 Updated by Johannes Hanika over 8 years ago

hey,

okay, about demosaicing again. we pulled in demosaic from libraw into dt
for the following reasons:

- it's now possible to load images with the much faster rawspeed lib, which
doesn't do demosaicing at all.

- we now do demosaicing in floating point (see [http://www.libraw.org/articles/festina-lente.html] for the effect).

- we now do demosaicing only on the current region of interest (ROI), which reduces workload a lot.

- we can now only do demosaicing if zoomed in close to 1:1, which again, is a great speed improvement.

- we don't have to re-load the whole image using libraw to change demosaic params.

- the pipe got much more flexible and param storage is much clearer now. we can now have white balance done before demosaic, just for example.

- we can do demosaicing on the GPU this way, which (on a decent GPU) is the last thing to make it absolutely negligible as far as runtime is concerned.

for all these reasons, we're not going back to demosaicing in an external library (libraw for example).

i don't oppose to implementing other fancy high-end-superslow demosaicers in dt.

i just very rarely shoot images beyond the nyquist limit, so ppg (+green eq for affected cameras) gives me very reasonable results (usually i don't have mazing artifacts, and the color thing is corrected by the post-demosaic median steps you mention, not the demosaicing itself), so that i don't think several days of coding and the performance drop from a few milliseconds to several seconds are worth it.

that said, the code is in src/iop/demosaic.c and data/kernels/demosaic_ppg.cl if anybody is really interested in taking it on.

imo, the post-proc step to reduce color artifacts common to all demosaic algos might be worth implementing.

i don't agree this is a major issue, but if you insist i'll leave that. but adding more demosaic options is definitely not a defect but an enhancement.

j.

#3 Updated by André Reinald over 8 years ago

I understand and noticed most of the reasons behind your choices. Indeed, as long as there is a user behind the screen doing adjustments, having a responsive program is useful, and working with DT is indeed a pleasure.

But then comes a moment when I hit "export" and I can afford to wait 1 minute per photo because I usually do something else while the PC computes my batch. Is it an unusual workflow ?

I looked into the sources already, and I saw there was the LIBRAW_DEMOSAIC_PACK_GPL2 macro which disables the "traditional" algos.

What about implementing eahd or amaze using the GPU (ie having demosaic_eahd.cl and demosaic_amaze.cl) ?

I'll look into the algos and see if I can "translate" them from c to cl... But I know too little of GTK to risk making changes to your (beautiful) interface to bring the choice up to the user. So maybe I'll need some help on that.

#4 Updated by Johannes Hanika over 8 years ago

Replying to [comment:4 bolet]:

I understand and noticed most of the reasons behind your choices. Indeed, as long as there is a user behind the screen doing adjustments, having a responsive program is useful, and working with DT is indeed a pleasure.

But then comes a moment when I hit "export" and I can afford to wait 1 minute per photo because I usually do something else while the PC computes my batch. Is it an unusual workflow ?

the problem might be consistency between darkroom preview and export. but it's possible to check piece->pipe->type == DT_DEV_PIXELPIPE_EXPORT in process() for that matter.

I looked into the sources already, and I saw there was the LIBRAW_DEMOSAIC_PACK_GPL2 macro which disables the "traditional" algos.

What about implementing eahd or amaze using the GPU (ie having demosaic_eahd.cl and demosaic_amaze.cl) ?

I'll look into the algos and see if I can "translate" them from c to cl... But I know too little of GTK to risk making changes to your (beautiful) interface to bring the choice up to the user. So maybe I'll need some help on that.

that would be great! one problem is that we currently need both CPU+GPU implementations to be compatible with non-opencl builds :/

but if you translate the core algorithms to dt-pipe code i'm sure we can fix up a gui combobox for it (feel free to post your questions to #darktable at freenode or the dev list, if you have any).

#5 Updated by André Reinald over 8 years ago

Since my last post on this ticket, I worked a lot with both DarkTable and RawTherapee, comparing hundreds of pictures processed by both programs. The more I compared, the more I found the demosaicking algos are DT's only objectionable point : I tried any setting I could think of, including the ones you suggest, but there are still about 1/10 images (I didn't shoot them on purpose) where I can't get some details right in DT. It's a pity because everything else in DT is just fantastic.

I have a question about OpenCL : is it possible to have one demosaicking algo only implemented in C and not OpenCL ? It would just work on the CPU even if there is a GPU available.

I ask this because my GPU is an on-board chip (Radeon HD 4250) which is more than enough for my needs, but doesn't seem to support OpenCL. So I won't be able to write the OpenCL side.

#6 Updated by Johannes Hanika over 8 years ago

I have a question about OpenCL : is it possible to have one demosaicking algo only implemented in C and not OpenCL ? It would just work on the CPU even if there is a GPU available.

I ask this because my GPU is an on-board chip (Radeon HD 4250) which is more than enough for my needs, but doesn't seem to support OpenCL. So I won't be able to write the OpenCL side.

sure, that will be a start. porting stuff to the GPU is not hard in general (of course depends on how involved/non-parallel or elegant your c code will be).

#7 Updated by oivanenko - over 8 years ago

Replying to [comment:3 jhanika]:

i just very rarely shoot images beyond the nyquist limit, so ppg (+green eq for affected cameras) gives me very reasonable results (usually i don't have mazing artifacts, and the color thing is corrected by the post-demosaic median steps you mention, not the demosaicing itself), so that i don't think several days of coding and the performance drop from a few milliseconds to several seconds are worth it.

that said, the code is in src/iop/demosaic.c and data/kernels/demosaic_ppg.cl if anybody is really interested in taking it on.

imo, the post-proc step to reduce color artifacts common to all demosaic algos might be worth implementing.

i don't agree this is a major issue, but if you insist i'll leave that. but adding more demosaic options is definitely not a defect but an enhancement.

j.

I very like darktable, but I have similar concerns about PPG just like other guys.

see attached archive at http://dl.dropbox.com/u/27248819/darktable_ppg_issue.zip
IMGP1627.PEF -- Pentax raw file
IMGP1627_ahd.png -- UFRAW AHD processed file
IMGP1627_ppg.png -- darktable PPG processed file. BTW, UFRAW PPG do the same things, this is not darktable issue, but PPG.

You can see ugly square multicolored artifacts on hairs. That is not worthy of additional processing time :(

#8 Updated by Jose Carlos Garcia Sogo over 8 years ago

Implementation from Andrey Kaminsky of Amaze is in the "slow plugin" mail to mailing list from 24 April 2011.
Patch attached to the bug.

#9 Updated by Johannes Hanika over 8 years ago

  • Status changed from New to Fixed

this is now in master. opencl ignores this though, but opencl/cpu consistency should probably be a separate ticket.

Also available in: Atom PDF

Go to top