dcraw compiled for X-Trans sensor with OpenMP options


Posting rules: It shouldn't need saying, but... play nice. Please keep your discussions civil. You can disagree, just don't be disagreeable. And, of course, all of the usual stuff like no spamming. Tex adds: I'll be rigorously enforcing this as we go along. We're probably going to be a small community in a little lifeboat, so we can't have members at each others' throats. This is for the sake of the project as a whole. So when you post, pretend you're speaking in person with your very wealthy auntie who has always treated you wonderfully and currently lists you prominently in her will. I won't be tossing anyone out of the forums because we are all in this together (except spammers: immediate membership cancelation), but I'll delete suspect posts right away.


9 posts / 0 new
Last post
ymartel
dcraw compiled for X-Trans sensor with OpenMP options

Hello,

I have succesfully compiled dcraw, patched for Lightzone, with the addition of a few OpenMP pragmas to parallelize some of the loops in the X-Trans specific portions of dcraw.c. I am not at the final story, but I already have dcraw running on my PC for an X100s image at 8 sec down from 11 sec.

If anybody is interested, please tell me, I can provide the patch file from standard dcraw.c.

The same technique can probably apply to the other decoding engines, but I have not yet tried it.

ktgw0316
Interesting. :)

Interesting. :)

Although I added OpenMP support in v4.1.0beta8 (http://lightzoneproject.org/lorum/openmp-multithreading), the xtrans_interpolate() have not been parallelized yet. Could you upload the patch somewhere I can access? Or, if you have github account, could you send me (@ktgw0316) a pull request?

 

Masahiro from dev-team

ymartel
Just sent a pull request

I have just sent a pull request, but I might not have sent it to the right destination - I have forked the main LightZone Aries85 repository and not the ktgw0316.

In case this is a problem, please find here the patch between v4.1.0~beta8 dcraw and my modified version: https://www.dropbox.com/s/9dmnud7sbhf1dz3/openmp_xtrans.dcraw.patch .

ymartel
dcraw still further optimized

Now on my i7, I get a timing for the full conversion of an X100s file:

- 11 sec on stock Lightzone dcraw

- 6.6 sec on optimized single-thread non OpenMP dcraw

- 2.6 sec on OpenMP dcraw (8 threads)

 

krist8
It took my i7 920 (oc @3.8GHz

It took my i7 920 (oc @3.8GHz) 32.10 seconds to open my X-E1 RAF file. Something wrong with my installation?  I am using LZ 4.1 beta 8 on Linux Debian jessie.  My video card is old AMD Radeon HD4850.  

ktgw0316
4.1.0beta8 have not include

4.1.0beta8 have not include this change yet. It will be available in beta9.

krist8
V4.1b9

Upgraded to beta9.  All 8 threads of my cpu are used, and it took only 8 seconds (vs 32 seconds defore).  Thanks to the team.

SFA
I have just tried the new

I have just tried the new beta9 with 2 of the sample  X-T1 files  - one from a test report on a web site and the other the problem "green cast" image recently discussed on another thread.

 

3 observations so far.

 

Speed is improved significantly although my smaller Canon raw files are much faster.

 

The Test site RAW file now looks very good after opening in LZ. Contrast seems different to the embedded jpg but that is not unsual and what I have seen to far as a general view looks very usable - which was in no way true for beta 8. I assume the nes DCRaw build is the main change on that.

 

The "Green cast" file will not open at all and reports an incompatible file message. I would assume that DCRaw(?) will need some additional analysis and development before it can properly deal with the file but at least now it LZ is able to report being unable to work with the file at this time rather than producing something that is of no  use.

 

My observations so far.

 

 

Grant

 

 

Photonoxx
As an X-E2 owner, I'm

As an X-E2 owner, I'm impatient to try that (may be in the next beta).