Results 1 to 3 of 3

Thread: Speeding up SARAW_ReadRAW ?

  1. #1
    Join Date
    May 2011

    Default Speeding up SARAW_ReadRAW ?

    Hi there,

    Following on from my recent post (the response to which I am very grateful), I have another question about what options are available for speeding up a call to SARAW_ReadRAW,. With a Nikon D90 camera, the image size is around 10MB, which isn't massive so reading the data from the file would be fast. However, the reconstruction of the RGB colour data seems to take a long time, with all of the options available.

    I haven't explicitly timed this function as I do accept that a lot is going on and this all takes time, but what I did notice was that this function appears to run on a single thread and does not make use of the ImgSource thread pool. So I guess my question is how feasible would it be to make this conversion stage within SARAW_ReadRAW "parallel"?

    Many thanks,

  2. #2
    Join Date
    Mar 2006

    Default Re: Speeding up SARAW_ReadRAW ?

    that's a tough one...

    SARAW is based on dcraw ( from time to time, we grab the latest dcraw and work it into the SARAW/ImgSource framework. but, we try to make as few changes as possible to the dcraw code when we do this because a) it's quite complex and b) carrying our changes over from previous versions can be quite a challenge (because the dcraw functions themselves often change, to accommodate new cameras or processing options).

    so, i'm reluctant to change any of the really low level dcraw stuff because there's a good chance our changes will end up turning into a merge nightmare down the road.

    but, i'll look around in there to see if there are any obvious and clean ways to add some multi-threading.

  3. #3
    Join Date
    May 2011

    Default Re: Speeding up SARAW_ReadRAW ?


    I thought that you'd say something like that and if I am honest, I totally agree with you. Having looked at dcraw and it's source code, I would not want to risk a potentially damaging change to a 3rd party component. If you know the owner and have a good relationship with them, maybe, but in general I would say leave it as it is.

    I am designing a system that needs to analyse many images in parallel and as such there are various ways I can choose to slice the problem up. I would like to have as many options available to me before I start, but I am more than happy to accept this as a restriction. It's just that I will need to read a lot of images and when I have spare cores, I'd like to make use of them. However, it's not a deal-breaker and I suspect my client will live with it.

    If you can spot any way to improve it's performance without compromising, reliability and/or maintainability then please go for it - if not, I'd say leave it as-is.

    Many thanks again,

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts