New log2_96(x) function

lapser

1093

Re: New log2_96(x) function

« Reply #10 on: 04 / December / 2012, 22:23:49 »

Advertisements

Well I put the log2 code back in and did my exposure test, and it was wrong again. I figured something else must be going on. I think I figured it out.

I'm using shoot_full_only to take the shots, to avoid metering each shot. As soon as get_exposure_count() changes, I call my routine to get the log2 of the sum of the pixels. I added a volatile variable that so I can tell when I'm in build_shot_histogram, and discovered that I'm calling my routine BEFORE it's over, or rather right as it's finishing.

So the faster log2 routine is picking up the sum of the pixels before build_shot_histogram has finished adding them up! It sounds weird, but I'm pretty sure that's what's happening. When I delayed until the volatile variable shows the build is done, the results from log2 are correct. I'll start a new thread to discuss the timing issues.

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

philmoz

3332

Re: New log2_96(x) function

« Reply #11 on: 05 / December / 2012, 02:50:14 »

Quote from: lapser on 04 / December / 2012, 20:09:36

int isum=(int)(log10(hsum-bl)*318.9050971091867+0.5); //log2(hsum-bl)*96

hsum is the sum of all the sampled pixel values
bl = (CAM_BLACK_LEVEL)*(total number of pixel samples)

The existing build_shot_histogram code only uses the top 10 bits of each raw value.
It shifts the value right by 2 bits (for 12 bit sensors) or 4 bits (for 14 bit sensors).

Shouldn't the 'bl' value also be scaled by the same amount?

Phil.

Logged

CHDK ports:
sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
g12 (1.00c, 1.00e, 1.00f & 1.00g)
sx130is (1.01d & 1.01f)
ixus310hs (1.00a & 1.01a)
sx40hs (1.00d, 1.00g & 1.00i)
g1x (1.00e, 1.00f & 1.00g)
g5x (1.00c, 1.01a, 1.01b)
g7x2 (1.01a, 1.01b, 1.10b)

lapser

1093

Re: New log2_96(x) function

« Reply #12 on: 05 / December / 2012, 03:17:37 »

Quote from: philmoz on 05 / December / 2012, 02:50:14

The existing build_shot_histogram code only uses the top 10 bits of each raw value.
It shifts the value right by 2 bits (for 12 bit sensors) or 4 bits (for 14 bit sensors).

Shouldn't the 'bl' value also be scaled by the same amount?

Good point. I add the full value of the pixel to get the sum, before the bit shift. That should be a lot more accurate, particularly at low light levels. I compute the total pixels in set_shot_histo(1), so I took npix++ out of the loop too. And instead of subtracting the black level from each pixel in the inner loop (~6000 times), I just subtract npix*black level when I'm returning the final result.

Code: [Select]

      p=get_raw_pixel(x,y);
      set_raw_pixel(x,y,CAM_WHITE_LEVEL); //*********testing - shows sample area as dots in picture
      hsum+=p; //subtract black level later
      // > 10bpp compatibility: discard the lowest N bits
      #if CAM_SENSOR_BITS_PER_PIXEL > 10
      p >>= CAM_SENSOR_BITS_PER_PIXEL-10;
      #endif
      shot_histogram[p]++;

Logged

EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos