supplierdeeply

Lapser Script Development

  • 44 Replies
  • 1471 Views
*

Offline lapser

  • *****
  • 1080
Re: Lapser Script Development
« Reply #40 on: 12 / September / 2017, 10:38:57 »
Advertisements
Theoretically:
If you would calculate a histogram with 16384 cells, then you would find Pmax1 and Pmax2 also in the histogram. Right?
Not sure how much you lose, if you calculate the histogram for 1024 cells and uses Pmax1 and Pmax2 from this histogram.
Yes, that's exactly what I do in my original, Tlapser.lua script. You can find pmax1 by finding the largest non-zero histogram array index.

The advantage of the extra precision is with underexposed images, when pmax2 tells you how much to increase the exposure on the next shot. But i don't think that's very important in practice, so 10 bit images would work almost as well.
If I understand you correctly, even at time-lapse in the sun you exposure to the right with no overexposure at all?

I do the same with rawopint with moon time-lapse by setting the Overexposure threshold to 0.005%. That gives me nearly ETTR.

If I use these parameters for the sun, I got massive underexposed pictures. On my G1x (at focal length 28mm) I set Overexposure threshold to 1%. In this case, approximately only the core of the sun is overexposed. I’m not sure how much EV steps between 0.005%. and 1%.

I’m thinking about of additional logging Pmax1 and Pmax2 in rawopint. In cases of overexposed scene of 1%, Pmax1 and Pmax2 would be always white correct? To see how much there are floating, I have to use a scene with no overexposure or I have set Overexposure threshold to 0.005%.
I think the "overexposure threshold" sets a limit to how many pixels can be overexposed at the top of the histogram. I tried it that way in Tlapser.lua, but it was difficult to hit that number accurately. For the Sun and Moon, the overexposure threshold depends on their size in the frame.

I ended up using a parameter that sets a limit to how much pmax2 can reduce the exposure below the mean. For sunsets, I usually use 2.5 ev. But even with no limit, it's not possible to get to ETTR with the Sun without a solar filter. You always hit the minimum exposure.

If you define overexposed as having totally white pixels, then pmax1, and pmax2 will be white. That's why I also counted the number of white pixels in my changes to rawop_meter. It's a measurement of how badly overexposed the image is, without having to calculate the entire histogram.

By the way, in addition to finding pmax1 and pmax2 from the histogram, you could also find the mean from it, eliminating the need to call rawop_meter. But computing pmax2 in rawop_meter eliminates the need for a histogram, which is better yet.
===
Many thanks for doing those tests, especially checking that rawopint works with my build. Would you mind running the massively overexposed test again, but this time check the box that says "Overflow Test?" That sets the step size to 1, which takes 10 seconds or so for each shot (be patient).

I added a 2 variable 64 bit accumulator to add up all the pixels in the image for computing the mean in rawop_meter.  That eliminates the possibility of overflow, allowing you to use a smaller step size. That will be useful, say, when the Moon is in a wide angle shot, where its width is smaller than the normal step size.
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

Re: Lapser Script Development
« Reply #41 on: 12 / September / 2017, 12:09:25 »
Thank you for the Explanation  :)

Would you mind running the massively overexposed test again, but this time check the box that says "Overflow Test?" That sets the step size to 1, which takes 10 seconds or so for each shot (be patient).

No Problem, 2 logs attached...
EOS M3 101a, 2*G1x (101a,100e), S110 (103a), SX50 (100c), SX230 (101a), IXUS160 (100a), IXUS30 (100k), 2*S45,
Flickr https://www.flickr.com/photos/[email protected]/albums
YouTube https://www.youtube.com/channel/UCrTH0tHy9OYTVDzWIvXEMlw/videos?shelf_id=0&view=0&sort=dd

*

Offline lapser

  • *****
  • 1080
Re: Lapser Script Development
« Reply #42 on: 12 / September / 2017, 12:58:10 »
No Problem, 2 logs attached...
Thanks! The metering values came out correct with no overflow. The number of white pixels (nwhite) was so large that the script overlowed trying to compute the percentage (no big deal).

pwhite=(nwhite*100)/nsteps -- pwhite<0 means overflow
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

*

Offline lapser

  • *****
  • 1080
Re: Lapser Script Development - Out of range error fixed
« Reply #43 on: 12 / September / 2017, 15:30:27 »
I discovered the reason I was getting out of range errors from rawop_meter using 100% of the jpg area. Here's the relevant code from rawop_meter:
Code: [Select]
    unsigned x_max = x1 + x_step * x_count;
    unsigned y_max = y1 + y_step * y_count;
    // x out of range
    if(x_max >= (unsigned)camera_sensor.raw_rowpix) { //lapser x_max > changed to >=
        return 0;
    }
    // y out of range
    if(y_max >= (unsigned)camera_sensor.raw_rows) { //lapser y_max > changed to >=
        return 0;
    }
...
   for(y = y1; y <= y_max; y += y_step) {  //lapser y < changed to <=
        for(x = x1; x <= x_max; x += x_step) { //lapser x < changed to <=
         //t+=get_raw_pixel(x,y);
         p=get_raw_pixel(x,y); //lapser   
         set_raw_pixel(x,y,(short)camera_sensor.white_level); //*****TEST*****
...
The "for" statement end test doesn't match the actual range when you use y<y_max and x<x_max. You end up doing one less step than you should, typically around 30 to 40 pixels.

The last set_raw_pixel(x,y) statement allows me to see the actual metering range, which is how I discovered that it was one STEP less than it should be. Adding one extra step in the script fixed the problem, but gave the erroneous out of range error when metering the full jpeg area.

[EDIT] I realized that when I change x<x_max to x<=x_max in the "for" statement I also have to change to >= in the range tests:
    // x out of range
    if(x_max >= (unsigned)camera_sensor.raw_rowpix) { //lapser x_max > changed to >=
        return 0;
    }
« Last Edit: 13 / September / 2017, 14:16:04 by lapser »
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos


*

Offline lapser

  • *****
  • 1080
Re: Lapser Script Development
« Reply #44 on: 14 / September / 2017, 23:48:31 »

After experimenting with the changes in my last message, I realized that adding an extra step by changing "<" to "<=" complicates the script code too much, and is confusing. The actual problem is in the range check. Here's how I corrected it:
Code: [Select]
    unsigned x_max = x1 + x_step * x_count;
    unsigned y_max = y1 + y_step * y_count;
    // x out of range
//    if(x_max > (unsigned)camera_sensor.raw_rowpix) {
    if((x_max-x_step) >= (unsigned)camera_sensor.raw_rowpix) { //lapser
        return 0;
    }
    // y out of range
//    if(y_max > (unsigned)camera_sensor.raw_rows) {
    if((y_max-y_step) >= (unsigned)camera_sensor.raw_rows) { //lapser out of range correction
        return 0;
    }
...
   for(y = y1; y < y_max; y += y_step) {
        for(x = x1; x < x_max; x += x_step) {
Because the "for" statements at the bottom use "y < y_max" the maximum value of y is "y_max-y_step". Thus, the out of range test should use "y_max-y_step". Also raw_rows and raw_rowpix are 1 greater than the allowed range, since the index starts at 0. That is, if raw_rows is 1, the maximum value of y is 0. So the range test should use >= instead of >.
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos

 

Related Topics