Canon vs CHDK histograms - page 4 - General Help and Assistance on using CHDK stable releases - CHDK Forum supplierdeeply
« previous next »
Pages: 1 2 3 [4] 5 6 7 8 9   Go Down

Canon vs CHDK histograms

  • 88 Replies
  • 13206 Views
*

Offline pigeonhill

  • *****
  • 1155
Re: Canon vs CHDK histograms
« Reply #30 on: 10 / May / 2021, 16:08:40 »
Advertisements
Quote
Just to be sure, CHDK histogram is still in "linear" not "log"?

Yup, linear I’m afraid  ;)
Logged
*

Offline reyalp

  • ******
  • 14080
Re: Canon vs CHDK histograms
« Reply #31 on: 10 / May / 2021, 23:31:11 »
Some code notes for anyone interested. I thought about starting a new thread in the dev section, but I'm just going to put it all here.

Main problem I found stems from the logic around viewport_step_size, which assumes viewport width (viewport_width_proper, meaning image  pixels, not buffer) is either 720 or 960. In current CHDK, this doesn't hold for a lot of cases: Aspect ratios that aren't full screen width, digic 6 cams that are 4:3, old cameras where the real used viewport is 704 instead of 720, stitch. viewport_width_proper is also assumed to be evenly divisible by 24, which also doesn't hold.

If actual width doesn't fit the assumptions, then the code that reads pixel values can get out of alignment, so the wrong bytes are used for the YUV components. Additionally, the check to skip over unused letterboxing can fail, causing 0 or garbage values to be sampled, as well as sampling many more pixels than it should.

Another issue is that the total pixels sampled should be less than 64k (since shorts are used to count) which wouldn't hold for FHD HDMI and possibly OVF.

When the assumptions are met, the current code samples every 8th pixel in vertical columns, skipping every other row if vid_get_viewport_yscale is 2.

My current plan for this issue is to get rid of the optimization around viewport_step_size, and use a nested loop to step over the desired rows, with the x step set to meet the alignment requirements and avoid exceeding 64k samples.

Other issues:
On digic 6, the range of Y values is less than the 0-255 (on g7x, I saw 16 to 235. Need to review https://en.wikipedia.org/wiki/YCbCr to figure out how to deal with it), so the EV grid is wrong, especially toward the edges, and over / under warning don't work correctly

The EV grid is drawn at a fixed scale, so it's meaningless if auto-magnify is enabled. (edit: incorrect, auto magnify is in the other axis, so should be ok)
« Last Edit: 02 / June / 2021, 00:22:27 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline c_joerg

  • *****
  • 1248
Re: Canon vs CHDK histograms
« Reply #32 on: 11 / May / 2021, 01:18:17 »
Interesting. Of course, that explains a lot ...
Logged
M100 100a, M3 121a, G9x II (1.00c), 2*G1x (101a,100e), S110 (103a), SX50 (100c), SX230 (101a), S45,
Flickr https://www.flickr.com/photos/136329431@N06/albums
YouTube https://www.youtube.com/channel/UCrTH0tHy9OYTVDzWIvXEMlw/videos?shelf_id=0&view=0&sort=dd
*

Offline pigeonhill

  • *****
  • 1155
Re: Canon vs CHDK histograms
« Reply #33 on: 11 / May / 2021, 01:24:01 »
@reyalp

Many thanks for the explanation.

One thought I had: do your findings impact the histogram function in Lua?
Logged
*

Offline c_joerg

  • *****
  • 1248
Re: Canon vs CHDK histograms
« Reply #34 on: 11 / May / 2021, 02:13:20 »
Quote from: pigeonhill on 11 / May / 2021, 01:24:01
One thought I had: do your findings impact the histogram function in Lua?
I've asked myself about that...
I hope not the rawoplib because this is a RAW Histogram....
Logged
M100 100a, M3 121a, G9x II (1.00c), 2*G1x (101a,100e), S110 (103a), SX50 (100c), SX230 (101a), S45,
Flickr https://www.flickr.com/photos/136329431@N06/albums
YouTube https://www.youtube.com/channel/UCrTH0tHy9OYTVDzWIvXEMlw/videos?shelf_id=0&view=0&sort=dd
*

Offline reyalp

  • ******
  • 14080
Re: Canon vs CHDK histograms
« Reply #35 on: 11 / May / 2021, 12:25:16 »
Quote from: pigeonhill on 11 / May / 2021, 01:24:01
One thought I had: do your findings impact the histogram function in Lua?
shot_histogram and rawop histo operate on raw data after a shot is taken, and so are completely unrelated.

get_live_histo uses the viewport, but uses a straightforward loop instead of the viewport_step_size logic, so it isn't affected by the width dependent issues. It does look like it could theoretically overflow for FHD, but only if nearly all pixels were in the same bin.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14080
Re: Canon vs CHDK histograms
« Reply #36 on: 14 / May / 2021, 02:14:29 »
Wrote some code to handle arbitrary viewport sizes. The attached WIP sets step sizes to keep total samples under 64K, with minimum steps of 4 pixels in x and 2 in y.

From my testing it seems to work, but I started wondering what a reasonable number of samples is.
One obvious question is how much CPU time it takes, so I added some timing using the 0xc0242014 usec timer. Results for both the previous code and my test code in attached CSV.

It turns out that reading the viewport values is *quite* expensive. With the old code, each "stage" for a full screen viewport takes ~13ms on elph180 (digic 4+), ~23ms on sx710 (digic 6) and ~30ms on a540 (digic II).

This works out to about 500 pixels/ms for elph180 and sx710, and about 250 for a540.

Times are ~20% better in playback mode, unsurprising since there's much less going on in the rest of the system.

Given how much faster the Digic 6 CPU is, it seemed odd the speed was so close. One possible explanation is that it's dominated by memory access, reading uncached viewport buffer byte by byte.

I tested this by clearing the uncached bit on the viewport address. Digic 6 performance nearly doubles. Older cams gain less, but still significantly.

The next question is, does using the cached address give correct results?
The answer appears to be yes: Testing RGB histogram on various solid colors gives the expected results. This makes sense, given the large volume of viewport data and multiple 20ms sleeps between revisiting the same pixel, it would be quite unlikely for stale values to remain in cache.

It might seem odd that caching helps much, since each pixel is read sequentially once per cycle, but the first fetch gets the entire line, and we saw this before with DNG processing.

This also means it's better to sample more densely in X than Y axis, since it increases the chance more than one pixel will be in the same cache line.

It's possible that optimized assembly could give similar gains, without knocking other data out of the cache.

I also benchmarked the other stages of the histogram process. They are mostly negligible. On a540 in rec mode, stage 0 takes ~0.2ms, 4 and 5 take 0.4ms and 1.2ms respectively. Drawing blended RGB takes 11. The other cameras are proportionally faster as you'd expect, except that digic 6 drawing takes ~17ms (not a surprise, given previous observations).

tl;dr
My takeaways:
The sample strategy should probably aim to keep the total time in the 10-20ms range.
Using the cached address is probably worthwhile, and would likely also benefit zebra and edge overlay.
Except possibly for drawing, optimizing the other stages would have limited value.
Logged
Don't forget what the H stands for.
*

Offline pigeonhill

  • *****
  • 1155
Re: Canon vs CHDK histograms
« Reply #37 on: 14 / May / 2021, 04:02:32 »
@reyalp

Very interesting, especially the Digic 6 vs others.

I would welcome testing on my M3 if you had the time to create a build for me  ;)

Cheers

Garry
Logged
*

Offline reyalp

  • ******
  • 14080
Re: Canon vs CHDK histograms
« Reply #38 on: 14 / May / 2021, 15:50:11 »
Quote from: pigeonhill on 14 / May / 2021, 04:02:32
I would welcome testing on my M3 if you had the time to create a build for me  ;)
Here's a test build from the ximr_draw_rgba branch. I think it should work, but I haven't added support for the new drawing method on any of my cams, so I haven't tested it.

Note this only address the incorrect sampling at some viewport sizes, it does not yet address the over/under exposure warnings on d6, except that you shouldn't get bogus warnings triggered by incorrect sampling.
Logged
Don't forget what the H stands for.
*

Offline pigeonhill

  • *****
  • 1155
Re: Canon vs CHDK histograms
« Reply #39 on: 14 / May / 2021, 16:14:20 »
@reyalp

I'm afraid that build is not very good.

The histogram, which I had on linear and blend, but tried with log and other display options, is unstable and jumps around all over the place.

It doesn't match the Canon histo.

Logged
Pages: 1 2 3 [4] 5 6 7 8 9   Go Up
« previous next »
 

Related Topics