rawopint.lua: Fast, accurate intervalometer with raw exposure metering

c_joerg

1248

Re: rawopint.lua: Fast, accurate intervalometer with raw exposure metering

« Reply #130 on: 10 / October / 2020, 04:43:49 »

Advertisements

Quote from: reyalp on 09 / October / 2020, 13:36:50

I guess something about the way CHDK hooks work doesn't allow it to run at the full continuous speed.

Not only that. I once took a simple test script.
The quick mode is faster than the continuous mode.

Quick Mode => 0.53s
Continuous Mode => 0.65s

This is only the case with the M100. With all my other cameras the continuous mode is faster or the same as the quick mode.

TestFast.lua (0.86 kB - downloaded 15 times.)

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

reyalp

14082

Re: rawopint.lua: Fast, accurate intervalometer with raw exposure metering

« Reply #131 on: 10 / October / 2020, 21:48:13 »

Quote from: c_joerg on 10 / October / 2020, 04:43:49

Not only that. I once took a simple test script.
The quick mode is faster than the continuous mode.

Quick Mode => 0.53s
Continuous Mode => 0.65s

This is only the case with the M100. With all my other cameras the continuous mode is faster or the same as the quick mode.

Two general possibilities:
1) The hooks aren't placed equivalently to where they are in other ports, making the cont technique not work equivalently
2) Digic 7 is different in a way that makes the technique not work equivalently.

It might be possible to distinguish between them with reverse engineering, but either way, it likely has more to do with the port than the script.

Or, the cause could be something totally unexpected

Logged

Don't forget what the H stands for.

c_joerg

1248

Re: rawopint.lua: Fast, accurate intervalometer with raw exposure metering

« Reply #132 on: 11 / October / 2020, 07:16:43 »

Quote from: reyalp on 10 / October / 2020, 21:48:13

it likely has more to do with the port than the script.

I understand that ...

I am also not unhappy with a 0.8s interval. I wouldn't expect my camera to do this for long either.

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

c_joerg

1248

Re: rawopint.lua: Fast, accurate intervalometer with raw exposure metering

« Reply #133 on: 16 / March / 2021, 05:34:47 »

I'm just thinking about an interval ramping.
With a starry sky you need an interval of about 30s (with Tv = 25s). At this interval, however, the sunset becomes too fast.

My idea:
If Tv Max > interval, the interval ramping should be active.

If the current exposure time > (interval - 2s), then the interval should start ramping.
The interval should then increase continuously up to Tv Max + 2s.
Once started, the ramping should only go in one direction (e.g. with 0.1s per recording).
The other direction (reduction) is only started when the maximum interval has been active for a certain time and the exposure time is below the start interval.

If I've seen that correctly, then you can increase the interval in the following loop, right?

Code: [Select]

for i=1,ui_shots do

What do you do with the following command before the loop? Set on the maximum interval?

Code: [Select]

hook_shoot.set(2000+interval)
I would deactivate interval_warn_led and interval_warn_beep in this case.

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

reyalp

14082

Re: rawopint.lua: Fast, accurate intervalometer with raw exposure metering

« Reply #134 on: 16 / March / 2021, 12:49:18 »

Quote from: c_joerg on 16 / March / 2021, 05:34:47

If I've seen that correctly, then you can increase the interval in the following loop, right?
Code: [Select]
for i=1,ui_shots do

Yes, I think that should be fine.

Quote

What do you do with the following command before the loop? Set on the maximum interval?
Code: [Select]
hook_shoot.set(2000+interval)

That's just to avoid timeouts waiting in the hooks, so it should be fine. You could also set it inside the loop (after hook_shoot.continue()), but there shouldn't be any need.

Logged

Don't forget what the H stands for.

c_joerg

1248

Re: rawopint.lua: Fast, accurate intervalometer with raw exposure metering

« Reply #135 on: 29 / April / 2021, 13:34:34 »

I now had a situation where the script really started swinging. I couldn't even fix that in Lightroom anymore.

rawopint.csv (32.05 kB - downloaded 17 times.)

rawopint20210429T192418.png (46.02 kB, 2400x1801 - viewed 33 times.)

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

Caefix

945
Sorry, busy deleting test shots...

Re: rawopint.lua: Fast, accurate intervalometer with raw exposure metering

« Reply #136 on: 29 / April / 2021, 14:37:35 »

Maybe something like "lens flare corruption" ?

Logged

All lifetime is a loan from eternity.

reyalp

14082

Re: rawopint.lua: Fast, accurate intervalometer with raw exposure metering

« Reply #137 on: 29 / April / 2021, 18:22:25 »

Quote from: c_joerg on 29 / April / 2021, 13:34:34

I now had a situation where the script really started swinging. I couldn't even fix that in Lightroom anymore.

It seems like it's driven over exposure. Starting at row 111 (exp 1043), over_frac is 0.9, so overall exposure is pushed below the normal target (meter96 is negative)
Next frame it's 0, and d_ev is +17 (because meter is below target, and over exposure is no longer balancing), next frame, over_frac is still 0, d_ev is +21. Next frame, over_frac is 1.6, d_ev is 0

Same pattern repeats a few times.

Why did over-exposure drop to 0? I don't know, would probably have to look at the individual frames. But from the scene, there could have been quite rapid real changes in overexposure.

I'm not sure what settings would mitigate this. Setting the ev range considered over exposure wider (Overexp Ev range) and allowing a larger fraction might smooth the apparent changes.

Or maybe the code should be changed to smooth more aggressively.

Logged

Don't forget what the H stands for.

c_joerg

1248

Re: rawopint.lua: Fast, accurate intervalometer with raw exposure metering

« Reply #138 on: 30 / April / 2021, 09:20:20 »

Quote from: reyalp on 29 / April / 2021, 18:22:25

Why did over-exposure drop to 0? I don't know, would probably have to look at the individua frames.

I could upload RAW if you want...
I have now marked all parts of the image in red, where the RAW values are> 15000. As you can see, there is a large plateau there. Small EV changes ensure that the area is sometimes overexposed and sometimes not. Maybe ev_change_max = 32 was too big.

Overview.jpg (142.77 kB, 1302x927 - viewed 26 times.)

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

reyalp

14082

Re: rawopint.lua: Fast, accurate intervalometer with raw exposure metering

« Reply #139 on: 30 / April / 2021, 14:11:58 »

Quote from: c_joerg on 30 / April / 2021, 09:20:20

I have now marked all parts of the image in red, where the RAW values are> 15000. As you can see, there is a large plateau there. Small EV changes ensure that the area is sometimes overexposed and sometimes not.

Yeah, that seems likely to be the explanation.

Quote

Maybe ev_change_max = 32 was too big.

IIRC, I didn't pick that as the default based on any real analysis, it was a guess and it seemed to work most of the time. The minimum does need to be big enough to keep up with the fastest sustained change, and obviously smaller will make it react more slowly to real changes.

That said, I think the script has always had a tendency to get into oscillations in cases like this, and probably needs different logic to handle it well. In fact, I see a comment

Code: [Select]

-- TODO
-- to avoid flapping as limits approached over / under weights

Perhaps a way to deal with this would be to account for the fraction near over exposure somehow or apply varying weight depending how deep into exp_over_margin it is, effectively dividing the "overexposed" bucket in the histogram into multiple buckets with different weight. Or perhaps the "smoothing" should give more weight to the longer term trend, but I think this problem is specific to how the histogram based limits work.

As always, adding more complexity will make it harder to test.

An idle thought: With something like the chdkptp remoteshoot glue, it would be possible to create a GUI that lets you visualize what the script is doing and change settings in real time.

Logged

Don't forget what the H stands for.