rawopint.lua: Fast, accurate intervalometer with raw exposure metering - page 14 - Completed and Working Scripts - CHDK Forum supplierdeeply

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

  • 182 Replies
  • 42124 Views
*

Offline c_joerg

  • *****
  • 1129
Re: rawopint.lua: Fast, accurate intervalometer with raw exposure metering
« Reply #130 on: 10 / October / 2020, 04:43:49 »
Advertisements
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.

M100 100a, M3 101a, 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

  • ******
  • 13357
Re: rawopint.lua: Fast, accurate intervalometer with raw exposure metering
« Reply #131 on: 10 / October / 2020, 21:48:13 »
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 ;)



Don't forget what the H stands for.

*

Offline c_joerg

  • *****
  • 1129
Re: rawopint.lua: Fast, accurate intervalometer with raw exposure metering
« Reply #132 on: 11 / October / 2020, 07:16:43 »
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.
M100 100a, M3 101a, 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 c_joerg

  • *****
  • 1129
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. 



M100 100a, M3 101a, 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

  • ******
  • 13357
Re: rawopint.lua: Fast, accurate intervalometer with raw exposure metering
« Reply #134 on: 16 / March / 2021, 12:49:18 »
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.
Don't forget what the H stands for.

*

Offline c_joerg

  • *****
  • 1129
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.

M100 100a, M3 101a, 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 Caefix

  • *****
  • 564
  • Sorry, busy deleting test shots...
Re: rawopint.lua: Fast, accurate intervalometer with raw exposure metering
« Reply #136 on: 29 / April / 2021, 14:37:35 »
 :blink: Maybe something like "lens flare corruption" ?
All lifetime is a loan from eternity.

*

Offline reyalp

  • ******
  • 13357
Re: rawopint.lua: Fast, accurate intervalometer with raw exposure metering
« Reply #137 on: 29 / April / 2021, 18:22:25 »
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.
Don't forget what the H stands for.


*

Offline c_joerg

  • *****
  • 1129
Re: rawopint.lua: Fast, accurate intervalometer with raw exposure metering
« Reply #138 on: 30 / April / 2021, 09:20:20 »
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.
M100 100a, M3 101a, 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

  • ******
  • 13357
Re: rawopint.lua: Fast, accurate intervalometer with raw exposure metering
« Reply #139 on: 30 / April / 2021, 14:11:58 »
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.
Don't forget what the H stands for.

 

Related Topics