Writing DNG in parallel with reversing - page 9 - General Discussion and Assistance - CHDK Forum  

Writing DNG in parallel with reversing

  • 83 Replies
  • 14094 Views
*

Offline reyalp

  • ******
  • 12725
Re: Writing DNG in parallel with reversing
« Reply #80 on: 01 / June / 2013, 18:56:19 »
Advertisements
Concerning the twin buffer, my r1054 use twin since long time ago without any prob.
I added hook_alt_raw_image_addr in trunk changeset 2823, if you can confirm this is correct, that would be appreciated.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4283
Re: Writing DNG in parallel with reversing
« Reply #81 on: 01 / June / 2013, 21:04:48 »
1) Should we have an option for the old code? I wouldn't want it in 1.2 release, but it could be useful for troubleshooting if problems show up.
Not sure what to do with the remote capture related code. create_dng_for_ptp() was based on write_dng(), and free_dng_for_ptp() may need to be adjusted too.
Quote
3) What to do with the chunk sizes? Optimal values will vary depending not just on the camera, but also the card.
There could be presets available from the UI ("slow card" / "fast card" or so, the other factors could be the sensor's pixel count, bit depth, DIGIC generation). Just an idea.

*

Offline reyalp

  • ******
  • 12725
Re: Writing DNG in parallel with reversing
« Reply #82 on: 01 / June / 2013, 21:17:03 »
Not sure what to do with the remote capture related code. create_dng_for_ptp() was based on write_dng(), and free_dng_for_ptp() may need to be adjusted too.
Yes, this will be fun again.  :( But create_dng_for_ptp is a copy, so it doesn't have to change to match the new write_dng. We could make it do swapping in parallel with sending, but I think for PTP the better solution is still to make a version that sends dng data unswapped and lets the client deal with it. There will be a few changes like I had to do in the write_dng_orig, but I think that shouldn't be too difficult.

Quote
Quote
3) What to do with the chunk sizes? Optimal values will vary depending not just on the camera, but also the card.
There could be presets available from the UI ("slow card" / "fast card" or so, the other factors could be the sensor's pixel count, bit depth, DIGIC generation). Just an idea.
Yes, this would be a possibility if someone wants to do the work. There is definitely more room for improvement, but I'd like to get a working version in the trunk sooner rather than later.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 12725
Re: Writing DNG in parallel with reversing
« Reply #83 on: 01 / June / 2013, 22:16:47 »
The no debug code version of this is now in the trunk, changeset 2826

Debug patch is attached, plus the latest version of the test script (which fixes a silly error if dng wasn't enabled in the ui)

I ran a test of the final code using the "raw save time" output on both my cameras

For D10, average DNG time over 10 shots (not counting first) was 3205ms. Average time for 10 CHDK raw was 3110ms

For a540, it was 1226ms and 1015ms.

For comparison, DNG time before the changes was around 3700ms and 1700ms respectively.

edit:
I've made a new branch from the latest trunk with the above patch applied https://tools.assembla.com/svn/chdk/branches/dng-optimization
« Last Edit: 01 / June / 2013, 22:48:40 by reyalp »
Don't forget what the H stands for.


 

Related Topics