360 camera rig for milky way timelapse - Creative Uses of CHDK - CHDK Forum supplierdeeply
« previous next »
Pages: [1]   Go Down

360 camera rig for milky way timelapse

  • 8 Replies
  • 2164 Views
*

Offline R0m1R

  • *
  • 3
360 camera rig for milky way timelapse
« on: 13 / February / 2023, 17:35:17 »
Advertisements
Hello there,

I've been following this forum for 3 years now in hope to get my little canon m100 compatible with CHDK.
Indeed, 3 years ago, I've bought 4 canon m100 to make a camera rig in order to capture 360 timelapse of the wilky way during my trekkings.
I've chosen these cameras since they were recent and not too expensive with a "ok" APS-C sensor.
But unfortunatly it's a entry level camera and timelaspse feature is inexistant / second bad news was the fact the camera was not supported by chdk  :'(
First experiments with continuous shooting and a rubber band on the trigger to get long exposure shot continuously ^^ not really accurate.
Second experiment, with a rasberry pi and Gphoto2 to trigger camera and pass settings. Triggering 4 cameras at the same time was tricky due too usb pid changing at every start....but I tried my best and it was working ok for 1 hour !
BUT at one moment I  don't really know when, one camera shut down and I couldn't restart it...it got fried I think  :blink:

So I decide to abandon this project (it's a personal project) and buy a 360 camera instead of trying to do mine. :-[

Later this summer I've stumbled upon a browser bookmark ...link to the m100 port on CHDK forum !
Surprise ! Someone has made a successful test of chdk on the canon M100 !!!
I've tried and it worked like a charm  8)

I've got some problems with the 256giga SDcard that wouldn't format in fat32 but after many try I've use aomei partition assistant that was the only tool able to do the formatting.

Then I've test Raw Meter Intervalometer, but I didn't quite understand the settings and I've always got blows out sunset and sunrise but correct exposure during the night sky.

Is there anyone able to help or willing to share a script that could correctly do exposure ramping for sunset and sunrise ?

I've tried another script that is sunset by yass but unfortunately, I wasn't able to make the power-saving mode work on my canon m100.
This last one was great for the exposure but quickly discharge my battery (50000mAh but for 4 cameras and a whole night).

Anyways, for now this project is a great learning lesson for :
  • learning Blender to make a 3D model of the rig
  • 3D printing ! dozen of prototypes and failed iterations
  • stiching photos into 360 videos and get correct distorsion parameters
  • making timelapse with not too much flickering
  • making holy grail timelapse from sunset to sunrise (no there yet)
  • learning some basic electronics to trigger camera and power them

I still have to figure out if there is a better way to synchronize the cameras and get better exposure across them.
It would be preferable to calculate an average exposure value from the 4 cameras and be able to pass the setting to all of them and get also a simultaneous trigger. this might not be doable with CHDK running independently on each camera...and for that I would need to go back to raspberry pi even but I'm afraid to fry another one.
Anyone here has experimented with 360 timelapse?


here are some photos of the project and some WIP timelapse.







https://photos.app.goo.gl/uKc8vJQ28nAJMB6WA
https://photos.app.goo.gl/o4b9XnCbCoadGT3p6




« Last Edit: 14 / February / 2023, 02:39:01 by R0m1R »
Logged
*

Offline reyalp

  • ******
  • 14082
Re: 360 camera rig for milky way timelapse
« Reply #1 on: 13 / February / 2023, 18:51:28 »
Hello and welcome,
Quote from: R0m1R on 13 / February / 2023, 17:35:17
Second experiment, with a rasberry pi and Gphoto2 to trigger camera and pass settings. Then I've test Raw Meter Intervalometer, but I didn't quite understand the settings and I've always got blows out sunset and sunrise but correct exposure during the night sky.
If you post an example log, I can probably explain what's happening.

Quote
Is there anyone able to help or willing to share a script that could correctly do exposure ramping for sunset and sunrise ?
rawopint certainly *can* do that, but as you've noticed, it has a lot of complicated settings. I'd be happy to make suggestions. Another possibility is that CHDK exposure control is broken in the M100 port in some cases, since it's not a finished port.

Quote
It would be preferable to calculate an average exposure value from the 4 cameras and be able to pass the setting to all of them and get also a simultaneous trigger. this might not be doable with CHDK running independently on each camera...and for that I would need to go back to raspberry pi even but I'm afraid to fry another one.
I be quite surprised just being connected to a raspberry pi was the root cause, though of course there could be an electrical fault related to the particular setup. There are also some cases where a camera looks dead, but actually starts, notices some error and shuts down again before displaying anything. It might be worth trying a CHDK build that just blinks at boot.

FWIW, if you do decide to go with USB control, chdkptp (https://app.assembla.com/spaces/chdkptp/wiki) would allow to read exposure values from the cameras and control them as you please, though you'd need to write some Lua code to do it. multicam.lua would potentially be a starting point.

Quote
here are some photos of the project and some WIP timelapse.
That first 360 of the night sky really shows the potential. Nice :)
Logged
Don't forget what the H stands for.
*

Offline c_joerg

  • *****
  • 1248
Re: 360 camera rig for milky way timelapse
« Reply #2 on: 14 / February / 2023, 01:34:53 »
Quote from: R0m1R on 13 / February / 2023, 17:35:17
Then I've test Raw Meter Intervalometer, but I didn't quite understand the settings and I've always got blows out sunset and sunrise but correct exposure during the night sky.

On my m100 rawopint works fine. Notice there is only a port for m100-100a.

https://chdk.setepontos.com/index.php?topic=12761.msg147263#msg147263
In the log file you will find the setting.
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 R0m1R

  • *
  • 3
Re: 360 camera rig for milky way timelapse
« Reply #3 on: 14 / February / 2023, 15:33:03 »
Quote from: reyalp on 13 / February / 2023, 18:51:28
If you post an example log, I can probably explain what's happening.
Unfortunately I've erased the CSV from my SD card... too many experiments.
Quote from: reyalp on 13 / February / 2023, 18:51:28
rawopint certainly *can* do that, but as you've noticed, it has a lot of complicated settings. I'd be happy to make suggestions. Another possibility is that CHDK exposure control is broken in the M100 port in some cases, since it's not a finished port.
thank you here are my actual setting that is saved as a preset:
reading at them I'm not sure of what they mean but when settings them I was carefully reading https://chdk.fandom.com/wiki/Lua/Scripts:_Raw_Meter_Intervalometer but tried to keep default settings:
Code: [Select]
init:ev_change_max=32
ev_shift=0
ev_use_initial=false
bv_ev_shift_pct=0
bv_ev_shift_base_bv=false
tv96_long_limit=0
tv96_short_limit=1276
tv96_sv_thresh=192
tv96_nd_thresh=1276
nd_value=288
nd_hysteresis=48
sv96_max=768
sv96_target=449
meter_width_pct=90
meter_height_pct=90
meter_step=15
meter_high_thresh=96
meter_high_limit=168
meter_high_limit_weight=200
meter_low_thresh=-168
meter_low_limit=-264
meter_low_limit_weight=200
over_margin_ev=24
over_thresh_frac=30000
under_margin_ev=384
under_thresh_frac=100000
over_weight_max=200
under_weight_max=200
over_prio=0
under_prio=0
histo_step=15
do_draw=false
draw_meter=none
draw_gauge_y_pct=0
smooth=true
meter_top=238
meter_left=566
meter_width=5420
meter_height=3616
meter_x_count=361
meter_y_count=241
histo_samples=106400
interval:2000
tv over long:511

the main idea for me is to get iso as low as possible and push iso when the exposure time is more than 25s and then push iso to maximum 3200 iso if it's underexposed. But at night the camera is using a correct exposure value since it's dark and you should see nothing. At this moment when exposure of the whole image is dropping, I want to brighten the image so you can see in the dark. It likes if you lock the exposure at sunset and you need that exposure value during nighttime.
I now holy grail timelapse requires putting the camera in manual mode and then every hour to get back to the camera to overexposed during night and then underexposed during sunset and sunrise.on yass (yet another sunset script) what I understood is that you define sunset and sunrise time and then the script handle the exposure ramping in a lapse of time after/before the sunset/sunrise.
But I'm sure rawopint can handle that without the timing :)

Quote from: reyalp on 13 / February / 2023, 18:51:28
I be quite surprised just being connected to a raspberry pi was the root cause, though of course there could be an electrical fault related to the particular setup. There are also some cases where a camera looks dead, but actually starts, notices some error and shuts down again before displaying anything. It might be worth trying a CHDK build that just blinks at boot.

interesting to you have a script to share ? because for now that camera is in the drawer and replaced by a secondhand camera I got for 100€
Quote from: reyalp on 13 / February / 2023, 18:51:28
FWIW, if you do decide to go with USB control, chdkptp (https://app.assembla.com/spaces/chdkptp/wiki) would allow to read exposure values from the cameras and control them as you please, though you'd need to write some Lua code to do it. multicam.lua would potentially be a starting point.
i've read this in the past but doesn't it require a PC connected to all teh cameras ? I would like to hike as light as possible and use a low amount of power so I can do a whole night timelapse. I'm already carrying a backpack of 30 kilos so every grams count ^^
 
Quote from: reyalp on 13 / February / 2023, 18:51:28
That first 360 of the night sky really shows the potential. Nice :)

thank you ! and ofc thx for the script ;) I hope to be able to use it correctly and show some good 360 videos ;)
for know it's a lot of work in post production to deflicker everything and synchronized frames

Quote from: c_joerg on 14 / February / 2023, 01:34:53
On my m100 rawopint works fine. Notice there is only a port for m100-100a.
https://chdk.setepontos.com/index.php?topic=12761.msg147263#msg147263
In the log file you will find the setting.
I've been digging your videos on youtube ! really nice work  :o
here is the difference between our settings.
I need to try yours to see the differences. I will try tomorrow because sunset is already finished here  :'(


my guess is also that using circular fisheye the camera is seeing a lot of dark and bright part since it's cover nearly half of a sphere and maybe setting a correct exposure value is tricky.
I was thinking of building a light meter that could set the same shutter speed/iso for all cameras but using chdk I'm not sure how to proceed.
I want to keep the system really plug and play with the less power consumption.
here is the light meter I was looking:

Logged
*

Offline reyalp

  • ******
  • 14082
Re: 360 camera rig for milky way timelapse
« Reply #4 on: 14 / February / 2023, 22:56:18 »
Quote from: R0m1R on 14 / February / 2023, 15:33:03
reading at them I'm not sure of what they mean but when settings them I was carefully reading
In the above
tv96_long_limit=0 means longest exposure is 1s
tv96_short_limit=1276 means shortest exposure is 1/10000s
tv96_sv_thresh=192  means ISO will start to increase at 1/4s
sv96_max=768 sets max ISO to 800
sv96_target=449 sets target ISO to 80

AFAIK these are all defaults for the last release of the script.

Note setting the target ISO *lower* than your camera supports will mess up the exposure control. Google suggests M100 minimum ISO is 100. This might explain some problems, though without testing I'm not sure if it could contribute to the overexposure issue you mentioned. Any any case, I'd highly recommend setting this to your cameras lowest UI value if you try the script again.

over_thresh_frac=30000 sets the overexposure threshold to 30%. This means overexposure won't start pushing the exposure down until 30% of the scene is blown out (or technically, within "Overexp Ev range" stops of the maximum raw value). Something like 3% (Overexp thresh x/100k = 3000) or less would be more appropriate. This could explain the over exposure you mentioned when running the script, if, for example, a large part of the sky was blown out but the rest of the scene was relatively dark.

under_thresh_frac=100000 sets under exposure threshold to 100%. If you want to turn it off completely (which is reasonable), you can use 0.

I don't see anything else obviously amiss skimming settings, but it's much better to have a log from an actual run.

If you are able to run jupyter notebooks, the code in https://github.com/reyalpchdk/chdkscripts/tree/main/tools provides some tools for analyzing rawopint logs. The sample notebook provides some examples and explanation. Note that while the library works for the released rawpoint 0.25 on the CHDK wiki, some of the description refers to fields in latest development version of the script on github.
Quote
the main idea for me is to get iso as low as possible and push iso when the exposure time is more than 25s and then push iso to maximum 3200 iso if it's underexposed.
This should be straightforward with rawopint.
Set
"Max Tv Sec/1000" to 25000 or more
"Target ISO" to the minimum your camera supports in the Canon UI
"Set ISO adj Tv Sec/1000" to 25000
"Set Max ISO" to 3200

If you want the scene to get somewhat darker as the sun sets (rather than staying at "normal" exposure until limits are hit) you can use the set Bv Ev shift % to something like 30%. If you start in daylight, Bv Ev shift base Bv can be "First". If you start in low light, it should be a daylight value (around 11 or 12)

Quote
Quote from: reyalp on 13 / February / 2023, 18:51:28
There are also some cases where a camera looks dead, but actually starts, notices some error and shuts down again before displaying anything. It might be worth trying a CHDK build that just blinks at boot.
interesting to you have a script to share ? because for now that camera is in the drawer and replaced by a secondhand camera I got for 100€
It would be a custom build rather than a script. I may be able to come up with something, but maybe @srsa_4c who did the port has a blinker build handy. Note while we have seen this scenario, I'd say it's long shot.

Quote
i've read this in the past but doesn't it require a PC connected to all teh cameras ? I would like to hike as light as possible and use a low amount of power so I can do a whole night timelapse. I'm already carrying a backpack of 30 kilos so every grams count
It needs a USB host running a "normal" Linux distro. Raspberry pi is fine, binaries are available on the site.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: 360 camera rig for milky way timelapse
« Reply #5 on: 15 / February / 2023, 17:44:43 »
Quote from: reyalp on 14 / February / 2023, 22:56:18
It would be a custom build rather than a script. I may be able to come up with something, but maybe @srsa_4c who did the port has a blinker build handy.
FWIW, the source I shared does light up the green LED in its loader, so builds based on that make that LED blink once whenever CHDK gets loaded. If there's no blink, CHDK did not load.
Logged
*

Offline R0m1R

  • *
  • 3
Re: 360 camera rig for milky way timelapse
« Reply #6 on: 23 / February / 2023, 15:22:42 »
Thank you for all these informations @reyalp !
Sorry for the late reply, I had some luck with the weather last week and I was able to make some tests but then got caught up by work and I could not process the data.

So my first experiment was to see the difference between use_ev_as_initial_target!"false" and "true"
here is the result
So here the use of initial exposure was really important and I find that it corresponds exactly to what I think is a great exposure for sunset and sunrise. I just wondering why it's so dark during sunrise, few seconds before the sun goes above the horizon.
See attached logs for this first test.

The next day I tried sunset again but this time keeping the use exposure setting but changing some other parameters to understand the differences.
:D I know... after looking at the different side by side videos and the parameters I can understand the meaning of each one ^^
But at first it was not obvious how it works. I'm also adding the logs in the attachment.

So I think I really like the use initial ev as target and then add a 20% latitude around this base value.

I wanted to test again a sunrise but it was cloudy all week here :/

Since my image is a circle in the midle of this 3:2 ratio I was also wondering if the Meter Width/Height % should be adjust. I was also thinking that since I'm having a 180° FOV, I have ground and sky and it might be interesting to only look for the top half of the image so I expose only for the sky (that should be in theory the brightest part). I'm still unsure of which setting I should use.

I've also disabled under exposure protection but My intuition is that I should enable it before sunrise to avoid having this very dark moment before sun goes above the horizon...no idea if it will resolve the problem.

Anyways, thank you in advance for your help! I can really see the power of this script! NO need for LR timelapse anymore !

Quote from: srsa_4c on 15 / February / 2023, 17:44:43
FWIW, the source I shared does light up the green LED in its loader, so builds based on that make that LED blink once whenever CHDK gets loaded. If there's no blink, CHDK did not load.

 Indeed, on all the camera the LED blink but on this one the LED stay off. Same SD used for the other cameras, same battery, ... might be dead :/

BTW, thank you for the m100 port ;)




Logged
*

Offline reyalp

  • ******
  • 14082
Re: 360 camera rig for milky way timelapse
« Reply #7 on: 24 / February / 2023, 00:24:14 »
Quote from: R0m1R on 23 / February / 2023, 15:22:42
So my first experiment was to see the difference between use_ev_as_initial_target!"false" and "true"
here is the result
So here the use of initial exposure was really important and I find that it corresponds exactly to what I think is a great exposure for sunset and sunrise.
So this is interesting. Normally, "Use initial Ev as target" shouldn't make a huge difference in normal situations, but ...

Quote
Since my image is a circle in the midle of this 3:2 ratio I was also wondering if the Meter Width/Height % should be adjust.
Yes. I'm guessing your lens has a LOT of vignetting?

Background:
rawopint measure the scene in two ways:
1) The "meter" which is the average (mean) of a rectangle on the raw image defined by "Meter width %" and "Meter Hight %" (and in the dev version also position). On your runs, this was 90%, i.e. most of the sensor area.
2) Over and under exposure measurement which takes a histogram of essentially the entire sensor, and counts the fraction of pixels above and below the over / under thresholds.

The basic exposure algorithm tries keep the "meter" equal to a particular value. By default (if you haven't used use_ev_as_initial_target, or the ev shift or bv/ev shift options), this is an empirical "neutral" that should be relatively close to what Canon auto-exposure would use photographing a grey card. It might be off a bit, but I haven't seen it be hugely off. The meter96 value in the log will be 0 when the meter average is equal to the neutral value.

use_ev_as_initial_target tells it to use whatever value it got from the meter for the initial shot as the target instead of the neutral. That means if you used Canon auto exposure, it should try to keep the same exposure Canon used. Or if you used manual, it should try to keep the exposure like whatever you set.

So this suggests either the "neutral" value is way off on this cam, or the meter the area measured by the meter is skewed.

Looking at your sunset_sunrise_test1, on cam1, which appears over-exposed for most of the run, the meter barely reaches 0, while under_frac stays over 50% (sunset_sunrise_test1-cam1.png). Meanwhile cam4 starts with meter near -200 and keeps it there through pretty much the whole run, and under_frac is even higher (sunset_sunrise_test1-cam4.png, first part).

So my guess the meter and under exposure histogram are heavily influenced by the vignette outside the usable image area.

If this is the case, you could reduce the effect of this by reducing the meter width / height % values, though given the meter is a rectangle, this will be a compromise of how much of the circular image you include. The histogram area can't be adjusted without modifying the code, so your best bet there is to turn under exposure control off (I can point to the lines to edit, if you do want to adjust the histogram area). Over-exposure should still work, though if a significant fraction of your sensor isn't useful image data, you'll want to use lower thresholds.

Looking at a raw image shot through this setup without any lens correction should be a useful guide. If CHDK DNG works on this cam, that should give an uncorrected view of the full sensor.

Note that meter width and height are expressed in % of the sensor dimensions, so you'll have to correct for the aspect ratio to get a square. You can use the "Draw debug info" meter option to show the metered area (edit: On shot image, not the camera display).
Quote
I was also thinking that since I'm having a 180° FOV, I have ground and sky and it might be interesting to only look for the top half of the image so I expose only for the sky (that should be in theory the brightest part).
The in development version (from https://github.com/reyalpchdk/chdkscripts) lets you adjust the position of the meter. But just restricting the meter to the image area should help a lot.

Quote
I just wondering why it's so dark during sunrise, few seconds before the sun goes above the horizon.
If you mean cam 4 around 1 minute into rawopint_sunset_and_sunrise_test1, I think it's trying to keep the sky at the -2 stops of the initial meter. It brightens at the end because it ran out of shutter. See sunset_sunrise_test1-cam4.png, second part, the tv96 value goes flat around 1200, while d_ev goes to -32. That means the exposure algorithm is requesting less exposure, but has no further adjustment available.

Quote
Indeed, on all the camera the LED blink but on this one the LED stay off. Same SD used for the other cameras, same battery, ... might be dead :/
Yeah, that should confirm it's not doing the boot and shutdown thing. Could open it up and look for crispy bits ;)
« Last Edit: 24 / February / 2023, 00:36:25 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline Caefix

  • *****
  • 945
  • Sorry, busy deleting test shots...
Re: 360 camera rig for milky way timelapse
« Reply #8 on: 28 / February / 2023, 15:54:42 »
Quote from: R0m1R on 23 / February / 2023, 15:22:42
Thank you for all these informations @reyalp
 Indeed, on all the camera the LED blink but on this one the LED stay off. Same SD used for the other cameras, same battery, ... might be dead :/
:( Have You tried cleaning battery-case contacts? 
Logged
All lifetime is a loan from eternity.
Pages: [1]   Go Up
« previous next »
 

Related Topics