Compile dcraw into CHDK? - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: [1]   Go Down

Compile dcraw into CHDK?

  • 6 Replies
  • 4703 Views
*

Offline jwlanf2

  • *
  • 2
Compile dcraw into CHDK?
« on: 05 / March / 2009, 00:40:42 »
Advertisements
Hi everyone,

I'm an EE student working on an image processing project which computes a depth map onboard a Canon camera via the CHDK, and I need to be able to convert the jpgs or raw files into something more manageable for image processing, like ppm.  Since dcraw is open source C, I figured it may be a good choice.  Has anyone tried compiling dcraw into the CHDK?  If so, I'd be very appreciative if you could give me a run down of the easiest way to do it.  If not, where should I start?

I've already figured out how to add a new function to the ubasic scripting language, so it seems like I should be able to copy the necessary code over from dcraw, re-compile, and viola! dcraw running on the camera.  Is it really that easy?

Thanks
Logged
*

Offline whim

  • ******
  • 2046
  • A495/590/620/630 ixus70/115/220/230/300/870 S95
Re: Compile dcraw into CHDK?
« Reply #1 on: 05 / March / 2009, 06:35:21 »
Hi, and welcome to the forum !

I haven't studied dcraw sources, but since it was meant to run on PC's, an unmodified compile
might cause memory problems - CHDK only has 0.2 - 0.5 Mb free memory (depending on cam type),
easily 1000x less than a PC ...

It may be a good idea to take a look at ewavr's RAW -> DNG implementation in CHDK (core/dng.c)
to get an idea of what is possible, memory-wise ...

just my 2c,

wim



Logged
*

Online reyalp

  • ******
  • 14080
Re: Compile dcraw into CHDK?
« Reply #2 on: 05 / March / 2009, 21:53:21 »
Porting random code to CHDK is non-trivial, even for vanilla ANSI C. In addition to the very tight memory limitation, CHDK doesn't have access to anything close to a standard libc. For example, lua is very portable ANSI, but still required significant hacking to compile.

Porting dcraw would be somewhere between difficult and impossible. In general, doing image processing on the camera is a bad idea, because the CPU is slow, memory is limited, and IO is slow. If you can reverse engineer the DSP side of DIGIC, this might be a different story ;)
Logged
Don't forget what the H stands for.
*

Offline fbonomi

  • ****
  • 469
  • A570IS SD1100/Ixus80
    • Francesco Bonomi
Re: Compile dcraw into CHDK?
« Reply #3 on: 06 / March / 2009, 03:48:57 »
yes, this is something that is frequently overlooked.

Our cameras are computers, but they are are SMALL and SLOW computers.

They are only able to process large images because they have a DSP that does the hard work for the CPU.

The problem is, the DSP has never been hacked and probably will never be, as it's much more proprietary and "hidden" inside the camera....

Quote
which computes a depth map

would you like to elaborate more?

I would love to be proven worng :-)

Logged
*

Offline whim

  • ******
  • 2046
  • A495/590/620/630 ixus70/115/220/230/300/870 S95
Re: Compile dcraw into CHDK?
« Reply #4 on: 06 / March / 2009, 06:19:14 »
@jwlanf2

this does not mean that you can't do in-camera post processing, take a look at this:

http://chdk.setepontos.com/index.php/topic,520.msg26832.html#msg26832


wim
Logged
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: Compile dcraw into CHDK?
« Reply #5 on: 06 / March / 2009, 07:19:35 »
Quote from: fbonomi on 06 / March / 2009, 03:48:57
which computes a depth map

Quote
would you like to elaborate more?
I would love to be proven worng :-)

To compute a depth-map you need two separate views.
As two cameras cannot communicate that information you would have to take two images with a single camera.

As the buffer resolution is low, the depth-map would be crude.

Maybe it is based on Hiker John's anaglyph code ?
Logged
*

Offline jwlanf2

  • *
  • 2
Re: Compile dcraw into CHDK?
« Reply #6 on: 09 / March / 2009, 15:27:43 »
@Microfunguy

Were using depth from focus.  A simple psuedocode would be:

1. Take several pictures at different focus points (the more focus points the better the quality of the depth map)
2. For each pixel in each picture, measure the contrast/sharpness relative to surrounding pixels.
3. For each pixel's contrast value, select the maximum.  We know which picture this came from, and we know the focal distance of that picture, so we therefore know an approximate distance from the camera.
4. Create the depth map by assigning different colors to pixels based on distance.

@whim
Thanks for the link.  That might be very helpful.  I didn't even think about using the image buffer directly.   It might be do-able for us to work directly with the raw data.  We don't expect to have perfect depth maps, so our algorithms shouldn't be very complex nor should they need much memory.

Thanks for the input... and keep it coming.
Logged
Pages: [1]   Go Up
« previous next »
 

Related Topics