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

c_joerg

Mlapse
The interval was 30 sec, so i can't imagine that is quick enough to heat it up that much.

It does not matter which interval you take. The sensor is heated by the constant reading of the sensor. Even if you do not take pictures, the sensor gets hot.
https://chdk.setepontos.com/d/13319

Mlapse

thanks

reyalp

Mlapse
maybe I'm mistaken and it is normal for an aps-c sensor, but the log i posted a while back had tsens of over 50C, the log from a few days back still had 45C. although iso was only 200.
The interval was 30 sec, so i can't imagine that is quick enough to heat it up that much.

FWIW, I wouldn't be surprised to see >50c in warm ambient conditions with a script like rawopint. (lack of surprise should not be taken as any judgement on whether it's healthy or not 😉)

A user reported problems around 80c https://chdk.setepontos.com/d/13501 with cameras in an enclosure.

Mlapse

FWIW, I wouldn't be surprised to see >50c in warm ambient conditions with a script like rawopint. (lack of surprise should not be taken as any judgement on whether it's healthy or not 😉)

I have logs from past summer stating that for another cam, so i wouldn't be either. but it is winter overhere and my other cams are all below 30C. So i'll just keep an eye on it and hope for the best.

c_joerg

Just for info:
My SX50 crashes with rawopint when I attach a LED lamp in the hot shoe. This happens only with an interval > 10s.

ROMLOG.LOG

3.24KB

srsa_4c

c_joerg
My SX50 crashes with rawopint when I attach a LED lamp in the hot shoe. This happens only with an interval > 10s.

I would not be surprised if that turned out to be a firmware bug. Try reproducing it without CHDK, if you're interested.

You might be able to work it around by enabling hotshoe override in the enhanced photo operations menu.

c_joerg

srsa_4c
Try reproducing it without CHDK, if you're interested.

How?
A simple interval script or one that stays in Half Press has no problems with 20s interval.

srsa_4cYou might be able to work it around by enabling hotshoe override in the enhanced photo operations menu.

It works. Thanksâ€¦

c_joerg

On my EOS M100 I can shoot in continuous mode with an interval from 0.1s (up to 20 images).
After 20 images it goes down to 0.35s.
With rawopint the maximum interval is only 0.7s.
I try to optimize the parameter but that didnâ€™t help.

Any idea where the time remains?

M100_rawopint.csv

7.38KB

reyalp

c_joerg
On my EOS M100 I can shoot in continuous mode with an interval from 0.1s (up to 20 images).
After 20 images it goes down to 0.35s.
With rawopint the maximum interval is only 0.7s.
I try to optimize the parameter but that didnâ€™t help.

Any idea where the time remains?

Not really. Unless you've accidentally enabled CHDK raw (the script option only controls CHDK raw, not native Canon raw), I guess something about the way CHDK hooks work doesn't allow it to run at the full continuous speed.

If you haven't already, you could try "quick" mode. Normally it's slower, but if cont isn't getting the full speed who knows...

c_joerg

reyalpUnless you've accidentally enabled CHDK raw (the script option only controls CHDK raw, not native Canon raw),

CHDK RAW is disabled 😉

reyalpIf you haven't already, you could try "quick" mode. Normally it's slower, but if cont isn't getting the full speed who knows...

It is nearly the sameâ€¦

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

It looks like that.
The M3 is usually significantly slower. Also only has a buffer for 3 RAW. But M3 manages the 3 RAWs in 0.3s

M100_Quick_rawopint.csv

14.85KB

M3_fast2020_rawopint.csv

6.64KB

c_joerg

reyalpI 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

881b

reyalp

c_joerg
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 😉

c_joerg

reyalp
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.

c_joerg

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?

for i=1,ui_shots do

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

hook_shoot.set(2000+interval)

I would deactivate interval_warn_led and interval_warn_beep in this case.

reyalp

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

Yes, I think that should be fine.

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

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.

c_joerg

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

rawopint.csv

32.05KB

Caefix

😐: Maybe something like "lens flare corruption" ?

reyalp

c_joerg
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.

c_joerg

reyalp
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.

reyalp

c_joerg
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.

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

-- 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.

« Previous Page Next Page »