Black and White RAW counting routine for HDR purpose - page 2 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 [2]   Go Down

Black and White RAW counting routine for HDR purpose

  • 18 Replies
  • 5653 Views
*

Offline Bernd R

  • ****
  • 430
Re: Black and White RAW counting routine for HDR purpose
« Reply #10 on: 22 / May / 2011, 09:51:15 »
Advertisements
thanks for explain more.

You use this defines

Code: [Select]
#define CAM_MASKED_AREA_X1 12
    #define CAM_MASKED_AREA_Y1 14
    #define CAM_MASKED_AREA_X2 48
    #define CAM_MASKED_AREA_Y2 3030

and CAM_MASKED_AREA_Y2 is 3030

then CAM_MASKED_AREA_X2 is only 48, should this not larger as 3000  ?

Logged
Ixus 1000 HS
*

Offline Lebeau

  • ***
  • 187
Re: Black and White RAW counting routine for HDR purpose
« Reply #11 on: 22 / May / 2011, 15:55:37 »
A post relative to Canon masked area
http://chdk.setepontos.com/index.php?topic=6114.msg61418#msg61418

Look at these defines:
Code: [Select]
    #define CAM_RAW_ROWPIX 4104
    #define CAM_RAW_ROWS 3048

    #define CAM_ACTIVE_AREA_X1 52
    #define CAM_ACTIVE_AREA_Y1 14
    #define CAM_ACTIVE_AREA_X2 4076
    #define CAM_ACTIVE_AREA_Y2 3030

    #define CAM_MASKED_AREA_X1 12
    #define CAM_MASKED_AREA_Y1 14
    #define CAM_MASKED_AREA_X2 48
    #define CAM_MASKED_AREA_Y2 3030

    #define CAM_JPEG_WIDTH 4000
    #define CAM_JPEG_HEIGHT 3000
The first two specify the overall dimension of the sensor, 4104 x 3048, and used to compute raw memory buffer.
The last two specify the final jpeg dimension, 4000 x 3000

What's up with these 104 x 48 lost(?) pixels ?
Some, all around the final jpeg area, are used to effectively compute demosaicking around the jpeg limits. That's give the active area which surround the jpeg area.

Q: But where masked area is coming from ?
A: A drawing is simpler than words :) See the attached document !)
Note: masked area is at the left, and as high, of active area. Incline Upper left corner point to an enlargement of the upper left corner (presented over the CAM_JPEG_... area)

By the way, I added these defines in camera.h
Code: [Select]
// lebeau
#define CAM_RAW_ROWLEN ( ( CAM_RAW_ROWPIX * CAM_SENSOR_BITS_PER_PIXEL ) >> 3 )
#define CAM_RAW_SIZE      ( ( CAM_RAW_ROWPIX * CAM_RAW_ROWS * CAM_SENSOR_BITS_PER_PIXEL ) >> 3 )
Logged
*

Offline Bernd R

  • ****
  • 430
Re: Black and White RAW counting routine for HDR purpose
« Reply #12 on: 24 / May / 2011, 03:41:50 »
ok, thanks now i understand, the mask area is only the left side gap.
Is then on right side no mask area ?

In the IX1000 Port the active have same size as the jpg and its center from the full area.Then this seem wrong, because there need on left side more Gap.here it have on right side more gap.

#define CAM_ACTIVE_AREA_X1         42
      #define CAM_ACTIVE_AREA_Y1         24
      #define CAM_ACTIVE_AREA_X2         3816-126
      #define CAM_ACTIVE_AREA_Y2         2784-24

I have not verify these area values, because images look ok and they are in jpg size , but maybe i should do a testbuild to see whats happen
Logged
Ixus 1000 HS
*

Offline Lebeau

  • ***
  • 187
Re: Black and White RAW counting routine for HDR purpose
« Reply #13 on: 24 / May / 2011, 10:43:27 »
Happy that you understand :)

Concerning the masked area location, I would consider active_area AND cam_raw_rowpix /cam_raw_rows values to estimate where this area could be.

In my A650 case, here is the estimation process:
    #define CAM_RAW_ROWPIX      4104
    #define CAM_RAW_ROWS         3048
    #define CAM_ACTIVE_AREA_X1 52
    #define CAM_ACTIVE_AREA_Y1 14
    #define CAM_ACTIVE_AREA_X2 4076
    #define CAM_ACTIVE_AREA_Y2 3030

Active area values are expressed in CAM_RAW_... coordinate therefore ...
 - in horizontal coordinate (easier to start @ 1)
1 ... 52 active 4076 ... 4104
then left gap is 52 and right gap is 28
then more space at left so consider
1 ... 12 masked 48 ... 52 active 4076 ... 4104
(note: could be lower than 12 but ... arbitraly ...)

 - in vertical coordinate
1 ... 14 active 3030 ... 3048
then centrally positioned

Arbitraly choose masked area coordinate:
 - in H: 12 to 48 (at the left of active area)
 - in V: same as active
    #define CAM_MASKED_AREA_X1 12
    #define CAM_MASKED_AREA_Y1 14
    #define CAM_MASKED_AREA_X2 48
    #define CAM_MASKED_AREA_Y2 3030


In your case (IX1000), I would suspect the right side to hide a nice masked area :)
Logged
*

Offline Lebeau

  • ***
  • 187
Re: Black and White RAW counting routine for HDR purpose
« Reply #14 on: 27 / May / 2011, 17:32:34 »
Well, since performance is an issue (for me), I decide to implement under/over exposed counts onto little-endian raw data (I only use DNG, or jpg for stop motion).

I will totalize, irrelevant to CFA, only over-saturated cells (over half white level) and under-saturated cells (under twice black level) after reverse byte ordering. I would have to learn ARM assembly code but it will be beneficial on the long run.

By the way, I am so oriented toward performance that, in my personal version, I comment out
Code: [Select]
if ( conf.save_raw
// && ( ! ( shooting_get_prop ( PROPCASE_RESOLUTION ) == 5 ) ) // hires
to shot on any jpg format and add code to temporarely reduce jpg size/quality, restoring previous setup within "raw_postprocess", in supplement to skip inverse byte reordering. That's give "bizarroidal" jpeg but it's always useless jpeg, for me, when saving DNG files.

Well ! Speed ! Speed ! Speed !  8)

I'll be back !
Logged
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Black and White RAW counting routine for HDR purpose
« Reply #15 on: 29 / May / 2011, 06:16:34 »
You may want to experiment with your camera's burst shooting speed versus jpeg settings to find out what really results in fastest jpeg write speed. At least on a570 and it's models it age, scaling takes a significant amount of time. Consequently full resolution is actually faster than low resolution unless SD card write speed is poor (or jpeg size difference is dramatic, and it may be at highest quality full resolution compared to lowest resolution lowest quality).

The fastest burst speed is available with cropped image (digital tele extension feature at its maximum setting) with resolution to match the crop (to prevent both upscaling and downscaling) and jpeg quality at its lowest setting. The camera might still have the full frame RAW in its buffer...?
Logged
*

Offline Lebeau

  • ***
  • 187
Re: Black and White RAW counting routine for HDR purpose
« Reply #16 on: 31 / May / 2011, 09:57:26 »
fudgey, I will do some tests and come back.

For now, my tries to implement over-under exposure check within reverse_byte are conclusives. Impossible.

reverse_byte little-endiannese the hole raw data memory, overscoping active area and misaligned 4 pixels in group of 5 bytes, therefore will really slow down reversing bytes.

For over-under exposure, I already use viewport via motion_detection, but using raw data, I now opt to modify the current shot_histogram to ramdomly read pixel sets (RGGB) to retreive colored data stats.

Keep in touch, I will come back ...
Logged
*

Offline Lebeau

  • ***
  • 187
Re: Black and White RAW counting routine for HDR purpose
« Reply #17 on: 08 / June / 2011, 11:33:14 »
Well, I just complete my raw histogram version.

I reuse shot_histogram module, adding sampling over raw active area.

When Lua enable shot histogram, the parameter indicates the number of samples that build_shot_histogram will extract all over the raw active area. In fact, the parameter value will be multiplied by 1024, therefore a parameter value of 10 will effectively sample 10240 CFA  pixel sets.

Doing so, the cost in time consume to sample raw data would be proportional to the parameter and would proportional to the precision required. Also, for a 12 Mpixels sensor, a parameter value of 2930 will over sample the raw data [ (2930 * 4 pixels per CFA * 1024 ) > 12Mp ]

Here is the mods:
 - shot_histogram.c
 - shot_histogram.h
 - shot_histogram.lua

Logged
*

Offline Lebeau

  • ***
  • 187
Re: Black and White RAW counting routine for HDR purpose
« Reply #18 on: 09 / June / 2011, 09:37:34 »
I HAVE TO UNDERLINE

 - "from" and "to" are based on 10bits raw cell values, from 0 to 1023

 - as per demonstrate in my post Masked area statistics and interpretation, 10bits raw cell value between 0 and 32, and upto statistically 57, represent non-exposed cell values. Therefore, calling "get_histo_range (0, 57)" will report percentage of statistically non-exposed sampled cells.

 - cell values are not gamma corrected, therefore, the histogram tends to be more (less) populated in the black (white) sector. Therefore, logarithmic scale would represent better uniformity. For example, using 32, 64, 128, 256, 512, 1024 as range value would be more comparable in normal circomstances.

 - Within shot_histogram.c, I multiply the count_samples by 1024. Therefore, a count value of 300 is equivalent to 640x480 sampling.
Logged
Pages: 1 [2]   Go Up
« previous next »
 

Related Topics