Lapser Script Development - page 5 - LUA Scripting - CHDK Forum
supplierdeeply
« previous next »
Pages: 1 2 3 4 [5] 6   Go Down

Lapser Script Development

  • 50 Replies
  • 22056 Views
*

Offline lapser

  • *****
  • 1093
Re: Lapser Script Development
« Reply #40 on: 12 / September / 2017, 10:38:57 »
Advertisements
Quote from: c_joerg on 12 / September / 2017, 04:46:08
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.
Quote from: c_joerg on 12 / September / 2017, 04:46:08
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.
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline c_joerg

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

Quote from: lapser on 12 / September / 2017, 10:38:57
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...
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 lapser

  • *****
  • 1093
Re: Lapser Script Development
« Reply #42 on: 12 / September / 2017, 12:58:10 »
Quote from: c_joerg on 12 / September / 2017, 12:09:25
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
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline lapser

  • *****
  • 1093
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 »
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline lapser

  • *****
  • 1093
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 >.
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline c_joerg

  • *****
  • 1250
Re: Lapser Script Development
« Reply #45 on: 23 / September / 2017, 12:46:08 »
I used this build from here
Quote from: lapser on 22 / September / 2017, 19:43:42
Here's a link with all the camera builds: https://drive.google.com/drive/folders/0B3woLhMB_tdqVkptS0hsTGNNRVk
 
and modified rawopint so, that mean,pmax2,nwhite and pmax1 would logged. I know, mean and meter is the same value. It was just a check for me, if my changes are correct. I run rawopint against my boring test video.


It‘s interesting, that the floating of pmax in not much  more than meter (or mean).


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 lapser

  • *****
  • 1093
Re: Lapser Script Development
« Reply #46 on: 23 / September / 2017, 14:40:18 »
Quote from: c_joerg on 23 / September / 2017, 12:46:08
It‘s interesting, that the floating of pmax in not much  more than meter (or mean).
That's a very useful test video! Thanks for the link.

Since all the pixels in each frame of the video are the same value, the maximum and the average pixel value are the same.
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline c_joerg

  • *****
  • 1250
Re: Lapser Script Development
« Reply #47 on: 18 / October / 2017, 02:18:21 »
This run may be interesting for you. It is a sunset which I run with rawopint. In addition, your parameters are recorded.

I believe rawopint has adjusted the exposure reasonably. The maximum overexposure was 1%. During this time pmax1 and pmax2 are Maximum.

If, in this case, we had controlled according to pmax2, how much would the exposure be reduced?
Would not the foreground be underexposed?

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 lapser

  • *****
  • 1093
Re: Lapser Script Development
« Reply #48 on: 18 / October / 2017, 12:55:41 »
Quote from: c_joerg on 18 / October / 2017, 02:18:21
I believe rawopint has adjusted the exposure reasonably. The maximum overexposure was 1%. During this time pmax1 and pmax2 are Maximum.

If, in this case, we had controlled according to pmax2, how much would the exposure be reduced?
Would not the foreground be underexposed?
I have a parameter in my script that limits the effect of pmax2. I usually set it at 242 ev96 below the mean value, which means my script would set the exposure 2.5 ev darker in your video. That's also subject to the shutter and ISO minimums when the Sun is in the frame, so it doesn't always get that much darker.

I usually don't have a beautiful beach with beautiful people walking by in the foreground of my videos, so I mostly want to see the sky exposed correctly. Especially after the Sun sets, pmax2 avoids overexposing the sky so you can see all the color changes.

At night, using pmax2 keeps from blowing out city lights when they're in the frame. But I discovered that I sometimes need a different pmax2 limit for daytime (Sun in the frame) and night time. I'll add that to my new script if I ever get time to work on it!

I haven't forgotten the HDR script. My solar eclipse script did HDR, but it set the shutter and ISO in 1 ev increments, i.e. 1 sec, 1/2, sec, 1/4 sec, 100 ISO, 200 ISO, 400 ISO. I've read that some HDR software reads EXIF data to determine how to blend photos. I wonder if that will create a problem with 1/96 ev increments where the EXIF doesn't match the actual exposure precisely?

This is a beach sunset video I did that looks a little like your video. Since I set the minimum shutter time at 1/500, I can't make it any darker than the mean with the bright Sun in the frame.
Logged
EOS-M3_120f / SX50_100b / SX260_101a / G1X_100g / D20_100b
https://www.youtube.com/user/DrLapser/videos
*

Offline c_joerg

  • *****
  • 1250
Re: Lapser Script Development
« Reply #49 on: 19 / October / 2017, 06:01:35 »
Quote from: lapser on 18 / October / 2017, 12:55:41
I haven't forgotten the HDR script. My solar eclipse script did HDR, but it set the shutter and ISO in 1 ev increments, i.e. 1 sec, 1/2, sec, 1/4 sec, 100 ISO, 200 ISO, 400 ISO. I've read that some HDR software reads EXIF data to determine how to blend photos. I wonder if that will create a problem with 1/96 ev increments where the EXIF doesn't match the actual exposure precisely?
No rush...
"lrtimelapse" don't like wrong EXIF data. Not sure how it is with HDR software. The last Software which i used was 'HDR Efex Pro' and  'Luminance HDR'.
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
Pages: 1 2 3 4 [5] 6   Go Up
« previous next »
 

Related Topics
SimplePortal 2.3.6 © 2008-2014, SimplePortal