supplierdeeply

proposal - script shooting hooks

  • 290 Replies
  • 35069 Views
*

Offline reyalp

  • ******
  • 11514
Re: proposal - script shooting hooks
« Reply #40 on: 11 / January / 2015, 19:38:46 »
Advertisements
Updated scripts for trunk r1911 param changes.  Also includes a few other minor changes.

both scripts:
Also changed the defaults for over and under ev ranges based on test results.

rawopint:
Added options to set canon image resolution and CHDK raw for duration of the script.
Reduce EV change if sign flipped.

contae:
Buffer log until burst is done.

Pretty sunset:
http://youtu.be/87Sj8nzbmas

Edit:
Oops, I was supposed to attach a file here, wasn't I?
« Last Edit: 12 / January / 2015, 02:04:44 by reyalp »
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 11514
Re: proposal - script shooting hooks
« Reply #41 on: 21 / January / 2015, 00:33:49 »
1) The way shift is specified isn't clear. It should probably specify an absolute number of bits.
2) I will probably change the bit depth to be specified in update, with the memory (re-)allocated if needed. This would also allow optimizing to use shorts if the number of samples is sufficiently low, and only holding on to the memory during the actual use.
I did this in trunk 3939.

The functions are now

histo=rawop.create_histogram()
Creates a new histogram object. All other histogram operations are done on the object, like histo:foo() rather than from rawop. Memory used by this object, and any histogram data will be garbage collected like other lua values.
(I incorrectly documented this as new_histogram before, but it was named create_histogram from the start)

histo:update(top,left,width,height,xstep,ystep,bits)
Builds a histogram of the specified area and bit depth. You can use the CFA offsets to build R, G, B histograms.
Bits must be >=1 and <= sensor bit depth. Memory for the histogram is allocated based on the bit depth.
This must be called before the histogram can be queried with histo:range() or histo:total_pixels()

frac=histo:range(min,max[,'count'])
return number of values in range, either as a fraction in parts per 1000, or total count

total=histo:total_pixels()
returns total number of pixels sampled

histo:free()
Immediately free any histogram data. histo:update() must be called before the histogram can be queried again. This is not required, the data will be garbage collected normally. This function just gives you the option of explicitly freeing the data as soon as you are done with it.

Updated versions of rawopint and contae are attached. The only update is for compatibility with the API changes.

Sunrise:
http://youtu.be/tkIVDoslzK4
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 11514
Re: proposal - script shooting hooks
« Reply #42 on: 08 / February / 2015, 18:24:04 »
Updated scripts
* Fixed under exposure protection. In some previous versions, it always used black level rather than the Underexp -Ev value.
* Meter area is now specified as percentages of sensor active area width and height
* Histogram uses jpeg area rather than active area, to avoid possible dark borders
* The first exposure (start of timelapse for rawopint, start of burst for contae) now applies the same Tv/ISO/ND limits as metered exposures. It currently does not use Ev shift.
* Initial ND support. The "ND Tv Sec/10000" value sets the shutter speed at which the ND is put in (0 disables) This only works for cameras without an adjustable aperture, and the exposure value for the ND will only be accurate if the Canon firmware would have used the ND in the first shot.
* Some changes to the log format and drawing code.

Storm clouds:
http://youtu.be/pOBCfgiNqTw

The shifting exposure as the sun moves through the tree and clouds in the meter area is as designed, but not very nice looking.

Attached plot shows the exposure (tv96, everything else was constant), scene brightness l (shifted to = tv when meter matches target), meter value (1/2 stop ev shift was in effect, also affected by over/under protection) and over and under protection weights.
Don't forget what the H stands for.

Re: proposal - script shooting hooks
« Reply #43 on: 08 / February / 2015, 18:29:17 »
I'll insert a post here to say "very nice work - watching this with great interest".  As I'm sure several other people are (and more will once they realize what you have here)!
Ported :   A1200    SD940   G10    Powershot N    G16


*

Offline ahull

  • *****
  • 634
Re: proposal - script shooting hooks
« Reply #44 on: 09 / February / 2015, 06:32:58 »
I am most impressed with the results there.. and am also watching this thread with much interest.

Re: proposal - script shooting hooks
« Reply #45 on: 19 / February / 2015, 20:44:44 »
Updated scripts
* ....
reyalp :  all versions of these script have had a note in the readme file that says :

"Doesn't handle aperture adjustments yet."

Which is pretty much self-explanatory.   

If I understand the effect of this correctly, on cameras with an adjustable aperture,  the f-stop value used is locked at the "half press'" by the Canon firmware and as the script cycles through shooting images,  that value is held and the exposure calculations work because that was the f-stop used when the exposure was checked after the half-press?

tl:dr : cameras with adjustable apertures will use the f-stop value selected during the half-press?
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 11514
Re: proposal - script shooting hooks
« Reply #46 on: 19 / February / 2015, 21:47:08 »
tl:dr : cameras with adjustable apertures will use the f-stop value selected during the half-press?
Exactly.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 11514
Re: proposal - script shooting hooks
« Reply #47 on: 22 / February / 2015, 23:39:54 »
Mostly had my head buried in the keyboard code, but here's a sunset with ev shift and over exposure protection working.
http://youtu.be/JebE_jawnJc

Almost wish I'd turned off the debug displays...
Don't forget what the H stands for.


Re: proposal - script shooting hooks
« Reply #48 on: 25 / February / 2015, 06:15:31 »
Hallo,

my name is Joerg and first I must say I’m am really impressed what you are doing.

My intention is to make flicker free (glitch free) time laps, special in the wadden sea (mudflat, tideland). I´m using the S110 and G1X

http://youtu.be/ZyOeVs3Ha6g

I hope my English is not too bad and you can understand me.

What I learned after 50000 shots was:
1) Do not use the automatic exposure of the camera
2) Underexposure can be better corrected in post processing than Overexposure
3) Closed aperture makes bad flicker in time laps

https://www.youtube.com/watch?v=PVnqd4f3Kmk

What I did before:
I always make time laps with open aperture to avoid aperture flicker.
Then I wrote my own Script with a Tv gain control. I got the Tv Value witch the camera calculated after half press and analyzed this value. Then I overwrite the Tv camera value with my Tv value. I tried to keep my Tv value in an area from +- 1/3 Ev of the camera Tv value. When the Tv value from the camera was outside this values, I start a counter. When the value was inside, I set the counter to zero. After a specified counter value, I changed my Tv value in 1/3 Ev steps. Of course, I have to run it with –Ev to avoid Overexposure. I also planned, to use the histogram to avoid Overexposure. This algorithm is very easy and works very well.

What I really miss are long Tv values to smooth the waves. When I close the aperture with my script, the camera always opens the aperture for measure, which makes bad flicker.

No I found your script rawopint, which have for me the advantage, that the camera does not change the aperture. It was not easy to find it with a title like ‘proposal - script shooting hooks’. I have not known was hooks before….

Yesterday a tried to run the script. Well I have not really understand every parameter yet (which effect has a larger meter area), so I run mostly with defaults. I make a Test against the sun. Basically the result was Ok.

The first thing, which I was wondering was, that the script change the ISO after first shoot from ISO 80 to ISO 160. The Tv values where around 1/30s. Any idea?

Then all pictures had too much Overexposure. Ok the default was 3%. That’s already a lot. I analyzed the pictures (values = 255) and find more the 4%. The different was, I take pictures in 16:9. The JPG includes fewer pixels. This is also the reason, why I can’t see the bar in the debug info near the top.

Next time I will run it with 1% Overexposure. But why I can’t set Overexposure to zero? Especially for time laps with the moon it should be a nice option to have no Overexposure and see structures is the moon. I tried it with my script but unfortunately the moon was less than 0.5% of the picture and the normal histogram delivers only steps in 1%.

What would be also nice to have?

ui_shots=0 for endless shoots.

And a safety mode for the auto focuses like:

get_focus_state() == 0 ->  set_focus(get_dofinfo().hyp_dist) 

This help you really, when you start a night or with fog. I lost a few series because of focus problems.

I’m looking forward to make more tests with your script….

Greets Joerg.

*

Offline reyalp

  • ******
  • 11514
Re: proposal - script shooting hooks
« Reply #49 on: 25 / February / 2015, 16:53:12 »
My intention is to make flicker free (glitch free) time laps, special in the wadden sea (mudflat, tideland). I´m using the S110 and G1X

I hope my English is not too bad and you can understand me.
Very nice video, and your English is fine.
Quote
The first thing, which I was wondering was, that the script change the ISO after first shoot from ISO 80 to ISO 160. The Tv values where around 1/30s. Any idea?
Were you using G1X or S110?

It sounds like CAM_MARKET_ISO_BASE could be wrong for your camera, see http://chdk.setepontos.com/index.php?topic=12170.0
This value is not set for S110 and probably should be. It should be correct on G1x.

If you can upload the log (rawopint.csv on the root of the SD card) that may also be helpful.

The exposure calculation is only supposed to increase ISO if the shutter speed goes below "ISO adj Tv Sec/100". This value is given in 1/100ths of second, so with the default value  ISO should only increase at 1/4 second. Otherwise, it will it should be set at "target ISO".

Note that the default "Target ISO" is 80, but some cameras only go down to 100. Trying to use 80 on these cameras that only go to 100 might give incorrect results. Also, some cameras that have a minimum display value of 80 actually need the input set to ~75 to get 80 in the exif.

Quote
Then all pictures had too much Overexposure.
If your camera has the ISO base bug, it would cause bad overexposure.

Quote
Next time I will run it with 1% Overexposure. But why I can’t set Overexposure to zero? Especially for time laps with the moon it should be a nice option to have no Overexposure and see structures is the moon. I tried it with my script but unfortunately the moon was less than 0.5% of the picture and the normal histogram delivers only steps in 1%.
Zero would be hard because there's always a few hot pixels, and to smoothly adjust exposure you need need a range to blend the correction in over.

In my script, the Overexp Ev range is the range of values (in exposure stops) treated as over exposure. If you increase this, you can trigger over exposure protection before the pixels are actually saturated.

Quote
ui_shots=0 for endless shoots.
Good idea.

Quote
And a safety mode for the auto focuses like:

get_focus_state() == 0 ->  set_focus(get_dofinfo().hyp_dist) 
Yes, I want to include focus control at some point.
Don't forget what the H stands for.

 

Related Topics