jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 33213
Joined: Sat Jul 30, 2011 7:41 pm

Re: Raspberry Pi High Quality Camera Long Exposures

Mon May 25, 2020 7:43 am

Ada Shaine wrote:
Mon May 25, 2020 4:14 am
Hey there,

I have a question. How to measure timing & synchronization of raspberry pi & on-board GPS?
Unrelated to HQ camera, please start a new thread.
Principal Software Engineer at Raspberry Pi Ltd.
Working in the Applications Team.
Meet me and the Pi team at Embedded World in Nürnberg, April 9th-11th, 2024
Hall 3A Stand 138
https://events.raspberrypi.com/official/24d5151d-dd0f-483d-88a7-a5fddaa5c554

sebastronomy
Posts: 1
Joined: Wed May 20, 2020 8:12 am

Re: Raspberry Pi High Quality Camera Long Exposures

Tue Jun 02, 2020 7:59 pm

Hi,

I was playing around with this for a bit to construct an allsky camera. With the Version of rpi-update from last week, everything looked fine, although i could not see a difference between a 30s and a 60s exposure in the night. So I updated again today with the following result:

Code: Select all

pi@allsky:~ $ time raspistill -n -bm -ex off  -st -md 3 -ISO 800 -ag 10 -t 10 -ss 55000000 -v -o test7.jpg

"raspistill" Camera App (commit 6e6a2c859a17 Tainted)

Camera Name imx477
Width 4056, Height 3040, filename test7.jpg
Using camera 0, sensor mode 3

GPS output Disabled

Quality 85, Raw no
Thumbnail enabled Yes, width 64, height 48, quality 35
Time delay 10, Timelapse 0
Link to latest frame enabled  no
Full resolution preview No
Capture method : Single capture

Preview No, Full screen Yes
Preview window 0,0,1024,768
Opacity 255
Sharpness 0, Contrast 0, Brightness 50
Saturation 0, ISO 800, Video Stabilisation No, Exposure compensation 0
Exposure Mode 'off', AWB Mode 'auto', Image Effect 'none'
Flicker Avoid Mode 'off'
Metering Mode 'average', Colour Effect Enabled No with U = 128, V = 128
Rotation 0, hflip No, vflip No
ROI x 0.000000, y 0.000000, w 1.000000 h 1.000000
Camera component done
Encoder component done
Starting component connection stage
Connecting camera preview port to video render.
Connecting camera stills port to encoder input port
Opening output file test7.jpg
Enabling encoder output port
Starting capture -1
Finished capture -1
Closing down
Close down completed, all components disconnected, disabled and destroyed


real    0m45,599s
user    0m0,007s
sys     0m0,052s

no matter what I change, raspistill doesn't run for more than 45s. EXIF shows 21.3s exposure time...

Anything I can do?

Cheers,
Sebastian

xkubazz
Posts: 39
Joined: Sun May 10, 2020 3:18 pm

Re: Raspberry Pi High Quality Camera Long Exposures

Wed Jun 03, 2020 12:07 am

sebastronomy wrote:
Tue Jun 02, 2020 7:59 pm
EXIF shows 21.3s exposure time...
Same for me, I did apt update and upgrade yesterday and now I also see that exposure time in EXIF is 21s when I tried to take longer (30s) exposures. I don't know yet if they are actually 21s or just EXIF is wrong.

edit: They seems to actually be 21 second exposures.
Astrophotography with Raspberry Pi HQ Camera
https://terramex.neocities.org/astro/

User avatar
HermannSW
Posts: 6256
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany

Re: Raspberry Pi High Quality Camera Long Exposures

Wed Jun 03, 2020 1:47 am

I have not run rpi-update lately, but it sounds that long exposures got broken.
rpi-update does bring kernel from 4.7 to 5.4.

There is a simple solution that works on Raspbian with 4.7 kernel:
https://github.com/raspberrypi/userland/
  • clone userland
  • cd userland
  • do "time ./buildme dummy" (takes less than 2min on Pi4B) in order to not overwrite shipped raspivid/raspistill
  • run "buildme/bin/raspistill"
viewtopic.php?f=43&t=273358#p1658078


Alternatively you can get up to 239s exposure with raspiraw, which does no GPU modifications of what is received from imx477 sensor via CSI-2 interface:
viewtopic.php?f=43&t=109137&p=1671859#p1670818

Testing long exposures can be done easily with a smartphone analog clock (55s exposure here):
Image


Or with 5$ diy image engineering led described in this posting (6by9 uses a 1500€ professional version):
viewtopic.php?f=43&t=273358&start=25#p1664566

Three consecutive raspiraw 237s exposures (always 1 led lit for 4s, from top to bottom, left to right => loops after 256s):
Image
https://github.com/Hermann-SW/RSA_numbers_factored
https://stamm-wilbrandt.de/GS [304+402+536fps]
https://hermann-sw.github.io/planar_graph_playground
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 15920
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raspberry Pi High Quality Camera Long Exposures

Wed Jun 03, 2020 7:01 am

Ah the joys of having multiple source trees.
The releases are built from the internal firmware tree which includes all the userland code. Almost certainly what has happened is that https://github.com/raspberrypi/userland ... be0ea6536b hasn't been merged back to the firmware tree, so it's not in the releases.

Rebuild userland manually and you should get long exposures again.
Software Engineer at Raspberry Pi Ltd. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
HermannSW
Posts: 6256
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany

Re: Raspberry Pi High Quality Camera Long Exposures

Sun Jun 28, 2020 1:49 pm

I wanted to try out something with my raspiraw fork "long_exposure" branch.
For testing the setup after initial "./camera_i2c" I did execute "time ./raspiraw 23000000" to get a "quick" 23s long exposure.
The scene was the last scene from my Raspberry microscope work last night:
viewtopic.php?f=43&t=210605&p=1686654#p1686654

I was surprised that the shortly displayed preview after 23s was bright, although I did not turn on the 800lm led for lighting the microscope scene. Here is image captured with "raspistill -o tst.jpg", scaled down to 15% size because of forum attachment size limitation. As you can see, with only daylight in room the scene is really dark (you see (out of form) pin point of lanzet, pin point less than 10µm in size). The full 4.5MB 12MP image is here:
https://stamm-wilbrandt.de/en/forum/lon ... re/tst.jpg
tst.15%.jpg
tst.15%.jpg
tst.15%.jpg (6.92 KiB) Viewed 8818 times
I had to use bright lights for seeing anything meaningful with 0.21µm/pixel Raspberry microscope before, but using daylight for 23 seconds exposure definitely gives enough light. The full 12.5MB 12MP image is here:
https://stamm-wilbrandt.de/en/forum/lon ... .ppm.d.png
out.0001.ppm.15%.jpg
out.0001.ppm.15%.jpg
out.0001.ppm.15%.jpg (8.21 KiB) Viewed 8818 times
https://github.com/Hermann-SW/RSA_numbers_factored
https://stamm-wilbrandt.de/GS [304+402+536fps]
https://hermann-sw.github.io/planar_graph_playground
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de

User avatar
HermannSW
Posts: 6256
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany

Re: Raspberry Pi High Quality Camera Long Exposures

Sun Jun 28, 2020 3:16 pm

Now I tested the extreme, closed window shutter completely, and did turn monitors off after starting 239s long exposure (I left room, making sure that door was opened less than 2 seconds, and it was darker in floor than in my room at daylight):

Code: Select all

🍓 time long_exposure 239000000
removing /dev/shm/out.*.raw
Using i2C device /dev/i2c-0
RaspiRaw: Probing sensor ov5647 on addr 36
RaspiRaw: Probing sensor imx219 on addr 10
RaspiRaw: Probing sensor adv7282 on addr 21
RaspiRaw: Probing sensor imx477 on addr 1A
RaspiRaw: Found sensor imx477 at address 1A
RaspiRaw: Setting exposure to 8365125 from time 239000000us
RaspiRaw: Set exposure 0202 to FF
RaspiRaw: Set exposure 0203 to 48
RaspiRaw: Set vts 0340 to FF
RaspiRaw: Set vts 0341 to 48
RaspiRaw: Encoding 32314270
No AWB
mmal: Set pack to 0, unpack to 0
mmal: Timing 6/2, 2/6/0, 0/0
mmal: Create pool of 6 buffers of size 18580480
mmal: Create pool of 6 buffers of size 18580480
mmal: Now streaming...

real	4m0.843s
user	0m0.071s
sys	0m0.192s
🍓 

Captured raw Bayer frame really took 239s to capture:

Code: Select all

🍓 stat /dev/shm/* | egrep "(File|Change)" | head -4
  File: /dev/shm/out.0000.raw
Change: 2020-06-28 16:34:44.014680972 +0200
  File: /dev/shm/out.0001.raw
Change: 2020-06-28 16:38:43.448866880 +0200
🍓 

I used the easy way to view captured frame, call raw2ogg2anim and CTRL-C after .png was created:

Code: Select all

🍓 time raw2ogg2anim i 1 1 1
removing old auxiliary files
copying /dev/shm/out.????.raw files
1     
dcraw each .raw file (to .ppm)
out.0001.raw     
.ppm -> .ppm.d
out.0001.ppm     
.ppm.d -> .ppm.d.png
out.0001.ppm.d     
now creating i.ogg
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
^Chandling interrupt.
Interrupt: Stopping pipeline ...
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
^C

real	0m32.988s
user	0m31.836s
sys	0m1.120s
🍓

I scaled the 12MP frame down to 15% size, I was surprised that the frame is that bright(!):
out.0001.ppm.d.png.15%.jpg
out.0001.ppm.d.png.15%.jpg
out.0001.ppm.d.png.15%.jpg (6.37 KiB) Viewed 8775 times
For me the few leds being on (two leds for each of the uln2003 stepper driver modules, two for the Arduino Uno, further away two leds for 10 outlets power strip and 1m away Pi4B led) looked not that bright. But taking photo in fully dark otherwise room revealed that even the few leds (shortest distance from led to lanzet seen is 14cm) provide quite some light for a smartphone camera to capture:
20200628_165256.jpg.15%.jpg
20200628_165256.jpg.15%.jpg
20200628_165256.jpg.15%.jpg (16.46 KiB) Viewed 8775 times
https://github.com/Hermann-SW/RSA_numbers_factored
https://stamm-wilbrandt.de/GS [304+402+536fps]
https://hermann-sw.github.io/planar_graph_playground
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de

CanPi
Posts: 64
Joined: Wed May 20, 2020 12:21 pm

Re: Raspberry Pi High Quality Camera Long Exposures

Sun Jun 28, 2020 9:08 pm

Hi Hermann,

I am sure that you know all this already but, in order to mitigate surprises, Exposure represents a certain amount of energy per unit area. It is proportional to Luminance from the scene and Exposure Time; and inversely proportional to the effective f-number squared.

Sensors are really photoelectron counters. So say that a'properly' exposed capture (meaning that it results in the brightest object the detail of which you would like not to be blown to be recorded just before clipping in the raw data) requires Exposure time of 1/40s and f/4 at base gain. If the illuminant of the scene (hence Luminance) is unchanged, and you want an equally exposed image, if you increase Exposure Time you need to compensate by decreasing relative aperture (increase f-number). f-number cannot be increased enough if you are going to go from 1/40s to 259s because that represents a log2(259/(1/40)) = 13.3 stops - and the lens has a minimum aperture of f/16, which is only 4 stops beyond f/4. So if you want an equally exposed capture in those conditions you are going to have to use a 9+stop neutral density filter on the lens.

I hope this reduces some of the guessing from your experiments.

User avatar
HermannSW
Posts: 6256
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany

Re: Raspberry Pi High Quality Camera Long Exposures

Sun Jun 28, 2020 9:34 pm

Thanks for the detailed information -- I only posted because I found it very surprising that light of few leds >=14cm distant is enough to get a photo.

I use an M12 180° lens mounted reversed on HQ camera as macro lens for the microscope (0.21µm/pixel with the extension ring):
viewtopic.php?f=43&t=210605&start=75#p1674471
Image

Code: Select all

Lens Specification:

    Model No: M25156H18
    Optical Format: 1/2.3”
    Focal Length: 1.56mm
    Aperture: F2
    Field of View (FOV): 180° (H)
    Mount: M12 mount
    Back Focal Length: 4.3mm
    MOD: 0.2m
    Dimension: Φ20×17.3mm
    Weight: 7g


So no aperture to change.
I am not sure which focal length applies for lens mounted reversed.

P.S:
The centers of 100 1mm micrometer divisions are 10µm apart(!), or 48 pixels at 0.21µm/pixel:
Image
https://github.com/Hermann-SW/RSA_numbers_factored
https://stamm-wilbrandt.de/GS [304+402+536fps]
https://hermann-sw.github.io/planar_graph_playground
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de

CanPi
Posts: 64
Joined: Wed May 20, 2020 12:21 pm

Re: Raspberry Pi High Quality Camera Long Exposures

Mon Jun 29, 2020 7:49 am

HermannSW wrote:
Sun Jun 28, 2020 9:34 pm
Thanks for the detailed information -- I only posted because I found it very surprising that light of few leds >=14cm distant is enough to get a photo.
I know it's counter intuitive but for a given Exposure (which remember is a density, i.e. photons/unit area) distance has little/nothing to do with the intensity of an object projected onto the sensing plane in setups like you've shown. Does your TV look a quarter as bright if you watch it from twice the distance? No, it looks equally as bright, it just takes up a smaller portion of your field of view. Likewise the image of your LED's.

The thing to keep in mind is that Exposure is proportional to the number of photons per unit area impinging on the sensor from the scene, hence to the number of photoelectrons (e-) generated by the sensor receptors (pixels) and as a consequence to the values written to the raw file (DN), assuming no processing before the data is written to file. So putting it all together with the previous posts:

Count/pixel in the linear raw data in DN (referred to as Intensity in image processing) from uniformly illuminated patch in the scene = number of photoelectrons per unit area ∝ Lt/N^2

where L = luminance from the scene (constant in your case), t = Exposure Time (shutter speed) and N = effective f-number = 1/2NA ~= f/D. The units are e-/unit area (in our case the area of one pixel) or, in the raw data, DN. A pixel can only collect so many e- before it maxes out (saturates, clips) so choose your Exposure accordingly..

As you can see distance does not figure into the equation.

User avatar
darkskyseeker
Posts: 55
Joined: Wed Sep 12, 2018 5:21 pm

Re: Raspberry Pi High Quality Camera Long Exposures

Wed Jul 08, 2020 3:13 pm

I did pretty well with these settings last night:

raspistill -t 10 -md 3 -bm -ex off -ag 1 --shutter 200000000 -st -o long_exposure_200s_c.jpg

However, I set the "ag" to 8

User avatar
HermannSW
Posts: 6256
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany

Re: Raspberry Pi High Quality Camera Long Exposures

Mon Jul 27, 2020 6:48 am

I received three 2$/pc laser pointers from aliexpress:
https://www.aliexpress.com/item/4000764344352.html
laser_pointers.jpg
laser_pointers.jpg
laser_pointers.jpg (33.11 KiB) Viewed 8383 times
They are rated 405nm±10 / 532nm±10 / 650nm±10, all with <5mW.
I am not sure whether I should trust the 5mW for the green laser based on my constant voltage power supply readings for 3V:

Code: Select all

650nm  29mA
405nm 158mA
532nm 408mA
The 2 AAA batteries will be drawn 1.2W for the green laser at least.
It is slightly longer than the other two pointers as well.
And defintely the brightness (for human eye) is much bigger than the other two.

In dark room human eye was able to see the laser beam, a little dim, but clearly.
I wanted to capture the beam, no chance with smartphone, and no chance with v2 camera.
So I did mount HQ camera on new 15$ light stand that can be extended up to 1.6m, and carry up to 1kg (later HQ camera plus Pi plus ...):
https://www.aliexpress.com/item/4000863269877.html
This was the capturing setup, HQ camera with 35mm C mount lens 0.5m distant to laser pointer clamped to drawer cabinet:
20200726_221619.15%.jpg
20200726_221619.15%.jpg
20200726_221619.15%.jpg (33.19 KiB) Viewed 8383 times

The green laser beam hitting the wall 3m distant did emit too much light. I did reduce that by painting a bit Black 3.0 that absorbs 98% of visible light on a small file card. I did use flat Lego piece under back end of green laser pointer to make sure that laser beam did hit the card in middle of part painted with Black 3.0 three times:
20200726_221708.10%.jpg
20200726_221708.10%.jpg
20200726_221708.10%.jpg (9.18 KiB) Viewed 8383 times

More on the capturing in next posting (forum limit of 3 attachments per posting)
Last edited by HermannSW on Mon Jul 27, 2020 7:33 am, edited 1 time in total.
https://github.com/Hermann-SW/RSA_numbers_factored
https://stamm-wilbrandt.de/GS [304+402+536fps]
https://hermann-sw.github.io/planar_graph_playground
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de

User avatar
HermannSW
Posts: 6256
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany

Re: Raspberry Pi High Quality Camera Long Exposures

Mon Jul 27, 2020 7:05 am

Continuation of previous long exposure setup posting.

I know that raspistill can capture long exposures up to 239s, and did that in this thread many times.
For capturing laser beam I did use my raspiraw fork "long exposure" branch because of ease of use:
viewtopic.php?f=43&t=109137&p=1671859#p1670818

For camera directed vertical to beam I got white frames converted with dcraw for single digit second exposures.
So I did place camera so that it was able to "look into" the laser pen a bit, and got this frame with only 7s exposure (dark room).
Because view is not vertical, left part of laser beam is out of focus:
7.15%.jpg
7.15%.jpg
7.15%.jpg (7.75 KiB) Viewed 8360 times

While I knew by that that capturing laser was possible, I wanted to capture vertical to laser beam and not see laser pen light. Reason was that I focused 35mm lens (with fully open 1.7 aperture) on head of laser pen with raspistill's "--focus" feature, and then turned the lens a bit so that laser pen move to right side of frame (with room light on). White frames with dcraw with 7s, and with 22s.
First successful capture was with 100s exposure time:
100.15%.jpg
100.15%.jpg
100.15%.jpg (7.79 KiB) Viewed 8360 times

Best result was achieved with 239s exposure time ("long_exposure 239000000" after "camera_i2c").
12MP (19MB) frame converted to .png here, below is scaled to 15% (dark room):
https://stamm-wilbrandt.de/en/forum/239.png
239.15%.jpg
239.15%.jpg
239.15%.jpg (9.35 KiB) Viewed 8360 times
The parts just outside of beam are dust particles hitting beam in 4 minutes exposure time.
Can be seen best when opening 100% image and viewing at 100%.

I am not sure why I and the camera can see the beam, I think the beam cannot be seen from side when passing through vacuum.
https://github.com/Hermann-SW/RSA_numbers_factored
https://stamm-wilbrandt.de/GS [304+402+536fps]
https://hermann-sw.github.io/planar_graph_playground
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de

User avatar
HermannSW
Posts: 6256
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany

Re: Raspberry Pi High Quality Camera Long Exposures

Mon Jul 27, 2020 10:48 pm

HermannSW wrote:
Mon Jul 27, 2020 6:48 am
And defintely the brightness [of the green laser] (for human eye) is much bigger than the other two.
HermannSW wrote:
Mon Jul 27, 2020 7:05 am
I am not sure why I and the camera can see the beam, I think the beam cannot be seen from side when passing through vacuum.
All explained in "Beams of Laser Pointers: Visible in Air?" article of Dr. Rüdiger Paschotta:
https://www.rp-photonics.com/spotlight_2010_01_11.html
When I take the green laser and shoot into the night sky, I very clearly see the beam in the air over a large distance. When I do that with the red laser, however, hardly anything is seen.

There are three reasons for that remarkable difference:
  • The green laser has a few milliwatts, the red one only about 1 mW.
  • The beam is visible in air only due to scattering. In clean air, that is Rayleigh scattering, the strength of which scales with the inverse fourth power of the wavelength. This means that the difference in scattering efficiency between 530 nm and 670 nm is a factor of 2.6.
  • The human eye is much more sensitive to the green light (around 530 nm) than for the red light (670 nm). Interestingly, the difference in sensitivity depends strongly on the overall brightness of the scene. Under normal daylight conditions, one has to use the photopic sensitivity curve, which tells us that the sensitivity at 530 nm is roughly 20 times higher than at 670 nm. With the eye adapted to the dark night, however, that difference becomes much stronger. The reason for this is that the eye uses different sensors. Under normal daylight conditions, it uses three types of cones for color vision, whereas in the dark it uses the rods. The latter are more sensitive for green light, but have a very poor response at 670 nm.
In combination, one should expect that the visible brightness of the scattered light from the green laser is much larger than for red light. And this perfectly fits to the experimental experience!
https://github.com/Hermann-SW/RSA_numbers_factored
https://stamm-wilbrandt.de/GS [304+402+536fps]
https://hermann-sw.github.io/planar_graph_playground
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de

User avatar
HermannSW
Posts: 6256
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany

Re: Raspberry Pi High Quality Camera Long Exposures

Sat Aug 08, 2020 9:05 pm

I don't know why it was that difficult to capture green laser beam with HQ camera (very long exposure).
Today I captured green laser beam by accident with a normal 16MP smartphone photo, as only difference in bright lighted room:
viewtopic.php?f=43&t=281646&p=1709644#p1709644
Image
https://github.com/Hermann-SW/RSA_numbers_factored
https://stamm-wilbrandt.de/GS [304+402+536fps]
https://hermann-sw.github.io/planar_graph_playground
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de

User avatar
HermannSW
Posts: 6256
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany

Re: Raspberry Pi High Quality Camera Long Exposures

Mon Oct 12, 2020 9:06 pm

Summary for HQ camera long exposure capabilities, until now raspistill and raspiraw can take long exposures of up to 239 seconds duration:
viewtopic.php?f=43&t=109137&p=1671859#p1670818

This posting is a by-product of capturing raspivid video of single HQ camera in sink mode by providing the necessary 40ns duration low pulses on HQ camera XVS pin:
viewtopic.php?f=43&t=281913&p=1741057#p1741057

What we got by this?
Arbitrarily long exposures with HQ camera!!!

This could allow astrophotographers capture circle star trail with single HQ camera several hours long exposure photo.


The by-product posting has the details on cabling, and how to trigger capturing next frame exactly when triggering 40ns long duration low pulse on XVS pin. Here I will just describe how I took the first >5min long exposure with HQ camera.

Before the details, this is animated .gif created from last 6 frames of raspivid video captured, with exposure time in milliseconds overlay. The last frame has 5:12min exposure time, quite above 239 seconds. The 1012x760 mode4 frames are scaled to 25% size for animation fitting as forum attachment. 50% size version here:
https://twitter.com/HermannSW/status/13 ... 9765224453
x.anim.gif
x.anim.gif
x.anim.gif (103.18 KiB) Viewed 7601 times

I started 10min long 1012x760 80fps raspivid capturing with these commands.
First command creates 80HZ PWM of 40ns long low pulses on XVS due to inverter.
With second command raspivid starts in background and does its normal work, capture roughly 13 frames without storing (for AWB?) and then captures frames to tst.h264 and millisecond timestamps (with microsecond precision) to tst.pts.
Third command results in XVS pin high because of used inverter:

Code: Select all

$ pigs hp 18 80 3
$ raspivid -md 4 -w 1012 -h 760 -fps 80 -o tst.h264 -pts tst.pts -p 500,22,506,380 -t 600000 & 
[1] 11553
$ pigs w 18 0
$

Then I triggered five 39ns long low pulses on XVS pin at different times:

Code: Select all

$ sudo ./nanopulse 39 1 9
1 pulses of 39 nanos with gap of 9 nanos (div=2 bits=13)
$ sudo ./nanopulse 39 1 9
1 pulses of 39 nanos with gap of 9 nanos (div=2 bits=13)
$ sudo ./nanopulse 39 1 9
1 pulses of 39 nanos with gap of 9 nanos (div=2 bits=13)
$ sudo ./nanopulse 39 1 9
1 pulses of 39 nanos with gap of 9 nanos (div=2 bits=13)
$ sudo ./nanopulse 39 1 9
1 pulses of 39 nanos with gap of 9 nanos (div=2 bits=13)
$ 

These are the last 8 timestamps from tst.pts, with delta times added.
These delta times are the exposures of the corresponding frames.
The first 3 frames are the last captured at 80fps (12.5ms delta times).
I executed the 5 low pulses after 6.8/10/20/60 and 312 seconds.
Finally I brought raspivid into foreground with "fg" command and stopped it with CTRL-C.

Code: Select all

2687.500	
2699.999	12.50
2712.502	12.50
9528.001	6815.50
19588.960	10060.96
39590.513	20001.55
99621.005	60030.49
411624.276	312003.27

The camera looks from top onto Pi4B and mini breadboard.
Only lights in dark room are Pi4B power and activity led.
With 60 seconds exposure time the tiny leds were able to light the room nicely:
frame.0222.png.jpg
frame.0222.png.jpg
frame.0222.png.jpg (84.99 KiB) Viewed 7601 times

Last 1012x760 frame with 312 seconds exposure is not completely white (eg. black USB connector):
frame.0223.png
frame.0223.png
frame.0223.png (18.84 KiB) Viewed 7601 times


Tomorrow I will leave hospital.
Then I will revive my 8x8 dot matrix led Arduino long exposure verify tool and do much longer exposure tests. At one point in time exactly one led did light for 4 seconds, from left to right, top to bottom, repeating. Animation shows three 238 seconds long exposures. Increasing time lit for led to say 1min (in Arduino sketch) would allow to verify long exposures up to 62 minutes:
Image
https://github.com/Hermann-SW/RSA_numbers_factored
https://stamm-wilbrandt.de/GS [304+402+536fps]
https://hermann-sw.github.io/planar_graph_playground
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de

PiGraham
Posts: 5383
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: Raspberry Pi High Quality Camera Long Exposures

Tue Oct 13, 2020 9:28 am

HermannSW wrote:
Mon Oct 12, 2020 9:06 pm

What we got by this?
Arbitrarily long exposures with HQ camera!!!

This could allow astrophotographers capture circle star trail with single HQ camera several hours long exposure photo.

It would be interesting to see what you get with minutes long exposures in very low light.
Your 60 second shot looks very usable with LED illumination. Do you have dark skies? Could you do the same looking at the night sky?
I doubt exposures of more than a few minutes will be usable due to accumulation of dark noise in the sensor. Stacking multiple shorter exposures will most likely give better results. It's all about getting the right balance between signal (available light) and noise (thermal noise in the pixels. If the exposures are too short there is not enough signal, too long and there is too much noise.

gordon77
Posts: 8046
Joined: Sun Aug 05, 2012 3:12 pm

Re: Raspberry Pi High Quality Camera Long Exposures

Tue Oct 13, 2020 3:53 pm

This looks very interesting for extended exposures, l look forward to a full write up :D

User avatar
HermannSW
Posts: 6256
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany

Re: Raspberry Pi High Quality Camera Long Exposures

Mon Oct 19, 2020 8:02 pm

PiGraham wrote:
Tue Oct 13, 2020 9:28 am
It would be interesting to see what you get with minutes long exposures in very low light.
See below.
I doubt exposures of more than a few minutes will be usable due to accumulation of dark noise in the sensor.
I think that is what I report about below, but I have not added any of the options needed for making this thread's "up to 239 second" long exposure working yet.
Your 60 second shot looks very usable with LED illumination.
That is what I thought as well, until I did direct 60 second comparison of the photo shot in hospital and the new 60 second illumination shown below. The "same" 4 artefacts as highlighted below, although two completely different scenes.

gordon77 wrote:
Tue Oct 13, 2020 3:53 pm
This looks very interesting for extended exposures, l look forward to a full write up :D
OK, this posting will be long, and I start with full cabling and description how to capture (new shell script long_exposure).
After that I will show all the photos taken with new approach over the last several days, compare them with each other, as well as compare same scene captured with "up to 239 second" long exposure this thread started with, as well as well "up to 239 second" raspiraw long exposure.


What you need in addition to HQ camera with cables soldered to GND and XVS pin, as well as a Pi:
  1. 74HC04N hex inverter IC
  2. four 100Ω resistors
  3. mini breadboard(s)
Connect all together according this connection diagram, more details here:
(voltage divider is needed since Pi runs on 3.3V, but HQ camera XVS pin runs on 1.8V)
viewtopic.php?f=43&t=281913&p=1742661#p1742159
Image
https://stamm-wilbrandt.de/en/forum/20201014_161619.jpg
Image


That was the hardware side, now the software.

Configure HQ camera as sync device, then reboot:

Code: Select all

pi@raspberrypi4B2:~ $ tail -4 /boot/config.txt 
# Set to 0 to disable.
# Set to 1 to act as a trigger source device on a non-CM board.
# Set to 2 to act as a trigger sync device on a non-CM board.
imx477_trigger_mode=2
pi@raspberrypi4B2:~ $

Compile pigpio library example nanopulse.c, modified for working with PIs after Pi1, with 4/3 scaling for Pi4B:
https://gist.github.com/Hermann-SW/fd06 ... 8af5c87d4f
In case you want to use on Pi different to Pi4B:
Use long_exposure bash script:
https://gist.github.com/Hermann-SW/6a33 ... g_exposure

Explanation of how the script works:

Start pigpiod if not already running, set 80Hz PWM on GPIO18 with 40ns high pulses (40ns low pulses on HQ camera XVS):

Code: Select all

#!/bin/bash
if [ ! -f /var/run/pigpio.pid ]; then sudo pigpiod -s 1; sleep 0.5; fi

pigs hp 18 80 3

Not sure why I used raspivid to capture a photo, will later replace with raspistill if possible.
Start raspivid for requested long_exposure time plus 3 seconds, wait for 2 seconds of recording, then stop capturing (GPIO18 low means HQ camera XVS pin is high due to inverter on 74HC04N):

Code: Select all

raspivid -md 4 -w 1012 -h 760 -fps 80 -o tst.h264 -pts tst.pts -p 500,22,506,380 -t $(($1*1000 + 3000)) &
pid=$!
sleep 2
pigs w 18 0

Wait for the long exposure time (in seconds) requested, send single 40ns low pulse to XVS for capturing frame, wait until raspivid has ended:

Code: Select all

sleep $1
sudo ./nanopulse 39 1 9
wait

Wait an additional 2 seconds to make sure timestamp file was written, show last 5 lines of that file:

Code: Select all

sleep 2
echo ...
tail -5 tst.pts


Now investigations done, photos captured, animations created from those.
Normally I scale images for the forum, but that would introduce problems seeing the artefacts.
Most animations are too big for forum attachments as well.
The images and animations in this posting sum up to 7.8MB size in total, but are needed for discussion.
The animations were created with "togg" and "pngs2anim" tools described here:
viewtopic.php?f=43&t=288576


A) Dark room, Pi power and activity LEDs only light, behind HQ camera

This is how 60 second long exposure was captured.
The ffmpeg command reveals the last frame number (6), which is the long exposure frame:
(I do not know of ffmpeg command that can extract the last frame only)
https://stamm-wilbrandt.de/en/forum/lexp/frame.0006.png

Code: Select all

pi@raspberrypi4B2:~ $ ./long_exposure 60
1 pulses of 39 nanos with gap of 9 nanos (div=2 bits=13)
...
962.500
975.000
987.502
1000.001
61053.442
pi@raspberrypi4B2:~ $ ffmpeg -i tst.h264 -ss 3 frame.%04d.png
frame=    6 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.24 bitrate=N/A speed=0.333x  
video:144kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
pi@raspberrypi4B2:~ $

180 second long exposure, last frame number is 3:
https://stamm-wilbrandt.de/en/forum/lexp/frame.0006.png

Code: Select all

pi@raspberrypi4B2:~ $ ./long_exposure 180
1 pulses of 39 nanos with gap of 9 nanos (div=2 bits=13)
...
925.000
937.501
950.006
962.500
181011.265
pi@raspberrypi4B2:~ $ ffmpeg -i tst.h264 -ss 3 frame.%04d.png
...
frame=    3 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.12 bitrate=N/A speed=0.154x  
video:309kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
pi@raspberrypi4B2:~ $

360 second long exposure, last frame number is 7:
https://stamm-wilbrandt.de/en/forum/lexp/frame.0007.png

Code: Select all

pi@raspberrypi4B2:~ $ ./long_exposure 360
1 pulses of 39 nanos with gap of 9 nanos (div=2 bits=13)
...
975.001
987.501
1000.000
1012.500
361062.061
pi@raspberrypi4B2:~ $ ffmpeg -i tst.h264 -ss 3 frame.%04d.png
...
frame=    7 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.28 bitrate=N/A speed=0.328x  
video:568kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
pi@raspberrypi4B2:~ $

For direct comparison I created this 0.5fps animation, for the reasons stated above in original 1012x760 size:
Image
You see artefacts, and with more exposure time, the number of artefacts increases.
Also artefacts showing for some exposure time, show up for longer exposure times as well.
So artefacts are added, but not removed for longer exposure times.

Next I cleaned the M12 130° lens front and back, as well as glass of HQ camera.
I did not bring back M12 lens in exactly same position, so the two frames captured are out of focus.

Here is 60 second long exposure captured after cleaning:
https://stamm-wilbrandt.de/en/forum/lexp/60.png
This animation just shows previous and new 60 second exposures -- the artefacts stay at same place of frame:
6_60.anim.gif
6_60.anim.gif
6_60.anim.gif (224.75 KiB) Viewed 7403 times
Here is 180 second long exposure captured after cleaning:
https://stamm-wilbrandt.de/en/forum/lexp/180.png
This animation just shows previous and new 180 second exposures -- the artefacts stay at same place of frame, again:
Image


This is more interesting, different scenes, 60 seconds exposure (link above and photo further above in this thread), different days, same HQ camera:
https://stamm-wilbrandt.de/en/forum/lexp/frame.0221.png
Image


It was the previous animation that allowed me to find 4 artefacts in the brighter photo at same locations as in new 60 seconds (dark) exposure:
frame.0221.boxes.jpg
frame.0221.boxes.jpg
frame.0221.boxes.jpg (156.27 KiB) Viewed 7403 times

Next I wanted to see what capturing with raspiraw from my long_exposure branch would look like in the same dark room (window shutter and door closed):
viewtopic.php?f=43&t=109137&p=1671859#p1670818

60 second exposure with that was "all white" because of the very low light conditions.
I used gimp threshold tool and did set threshhold to 252, seeing that even in that photo the room can be seen:
Image



Then I wanted to compare 180 second exposure with new method to the long exposure with "normal" HQ camera long exposure. Low lighting was too low for that method, photo looked "all black". Again I used gimp threshold (this time threshold 1) to see that the room can be identified:

Code: Select all

$ time ( raspistill -t 10 -md 3 -bm -ex off -ag 1 --shutter 180000000 -st -o 180.jpg )
Image


Just a kind of "record", this is a 20 minute long exposure of the room compared to 10 minute exposure seen before:
https://stamm-wilbrandt.de/en/forum/lexp/frame.0007.png
https://stamm-wilbrandt.de/en/forum/lexp/1200.png
Image


I had read that dpc (defective pixel correction) can be turned off:
viewtopic.php?f=43&t=277768
I did that and captured with 180 seconds long exposure -- and got tons more of artefacts than in the 180 seconds photos captured with new methond. Animation allows to compare (the shadow you see on left wall is from HQ camera and tripod):
Image



Summary:
For this single led lights room low light captures, defective pixel correction needs to be turned on.
HQ camera "up to 239 seconds" long exposure does not work at all (neither raspiraw nor raspistill).
No special settings for raspivid in above long_exposure bash script gives artefacts, but is surprisingly good otherwise.


I was not able to capture sky successfully sofar, besides capturing moon with 35mm and 70mm lenses.
Given the detailed description of what is needed and bash script long_exposure, I hope some of you will play with this as well.
If you get it working (eg. in dark room with Pi leds only), please try to capture night sky, and show us what can be captured with say 20 or 60 minute long exposures. Can anything similar to these images be captured with a single HQ camera frame?
https://www.google.de/search?hl=en&tbm= ... client=img
https://github.com/Hermann-SW/RSA_numbers_factored
https://stamm-wilbrandt.de/GS [304+402+536fps]
https://hermann-sw.github.io/planar_graph_playground
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de

PiGraham
Posts: 5383
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: Raspberry Pi High Quality Camera Long Exposures

Mon Oct 19, 2020 8:38 pm

HermannSW wrote:
Mon Oct 19, 2020 8:02 pm
You see artefacts, and with more exposure time, the number of artefacts increases.
Also artefacts showing for some exposure time, show up for longer exposure times as well.
So artefacts are added, but not removed for longer exposure times.

That is expected. Some pixels will have higher dark current than others and left unrest for such long exposures the dark current accumulates resulting in these bright spots.

This is characteristics of individual pixel sites so the spots stay in place and come or go according to exposure time (and temperature should have some effect as well).

If you can locate the noisier pixels you can run a median filter at that point to conceal them. That may be what the DPC is doing.
Alternatively a 3x3 kernel median filter should suppress them to some extent.

At very long exposure times the noisier pixels will saturate and may leak charge to surrounding pixels making bigger bright spots that will be harder to conceal.

Not good for stars though. It will remove any small bright dots!

Maybe there is a way to calibrate the DPC pixel list for your sensor at your max exposure.

It doesn't look like there is much scope to go longer. 3 mins is already very noisy.

PiGraham
Posts: 5383
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: Raspberry Pi High Quality Camera Long Exposures

Mon Oct 19, 2020 8:40 pm

PiGraham wrote:
Mon Oct 19, 2020 8:38 pm
HermannSW wrote:
Mon Oct 19, 2020 8:02 pm
You see artefacts, and with more exposure time, the number of artefacts increases.
Also artefacts showing for some exposure time, show up for longer exposure times as well.
So artefacts are added, but not removed for longer exposure times.

That is expected. Some pixels will have higher dark current than others and left unrest for such long exposures the dark current accumulates resulting in these bright spots.

This is characteristics of individual pixel sites so the spots stay in place and come or go according to exposure time (and temperature should have some effect as well).

If you can locate the noisier pixels you can run a median filter at that point to conceal them. That may be what the DPC is doing.
Alternatively a 3x3 kernel median filter should suppress them to some extent.

At very long exposure times the noisier pixels will saturate and may leak charge to surrounding pixels making bigger bright spots that will be harder to conceal.

Not good for stars though. It will remove any small bright dots!

Maybe there is a way to calibrate the DPC pixel list for your sensor at your max exposure.

It doesn't look like there is much scope to go longer. 3 mins is already very noisy.
Still, you have image detail in longer than standard exposures which could be used with image staking/summing. do the DPC first!

User avatar
HermannSW
Posts: 6256
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany

Re: Raspberry Pi High Quality Camera Long Exposures

Wed Oct 21, 2020 5:57 am

I wanted to prove that a 60min long exposure really took 60 minutes.
I did rebuild my diy image engineering led panel:
viewtopic.php?f=43&t=273358&p=1664566#p1664566
That posting already contained needed Arduino sketch, but I had not noted the connections of Uno pins and 8x8 dot matrix pins, added them as P.S to that posting, after some debugging last night.

First, no need for a complete dark room, a "dark box" is enough, containing tripod with HQ camera and CStoM12 adapter with Arducam M12 50° lens directed down, and camera flat ribbon cable as well as camera GND and XVS pins brought outside of the box with long breadboard cables. I did power the Arduino Uno via breadboard cables to Vin and GND from constant voltage power supply (5V, 14mA) from outside as well:
20201021_001433.15%.jpg
20201021_001433.15%.jpg
20201021_001433.15%.jpg (38.91 KiB) Viewed 7272 times

Next I did put some heavy things onto the closed box to keep it closed (small box filled with pressed newspapers as bullet catcher for next HQ camera experiment, as well as RC airplane remote control). Here you can see from left to right constant power supply, box, mini breadboards with voltage divider and 74HC04N and Pi4B:
20201021_002529.15%.jpg
20201021_002529.15%.jpg
20201021_002529.15%.jpg (44.72 KiB) Viewed 7272 times

I changed dt=60000 in Arduino sketch (used dt=3333 for 200s capturing before, and dt=4000 for 239s capturing) to let each single led light 1 minute, exactly one at each time, from left to right, top to bottom. A first experiment with only 90 seconds long exposure immediately revealed that this is by far too bright for 60 minute long exposure. Full 1012x760 frame here (for artefact details):
https://stamm-wilbrandt.de/en/forum/too_bright_90s.png
too_bright_90s.50%.jpg
too_bright_90s.50%.jpg
too_bright_90s.50%.jpg (16.77 KiB) Viewed 7272 times
https://github.com/Hermann-SW/RSA_numbers_factored
https://stamm-wilbrandt.de/GS [304+402+536fps]
https://hermann-sw.github.io/planar_graph_playground
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de

User avatar
HermannSW
Posts: 6256
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany

Re: Raspberry Pi High Quality Camera Long Exposures

Wed Oct 21, 2020 6:24 am

I added a delay of 59 seconds in the sketch where new display gets drawn the first time:

Code: Select all

$ diff sketch_may21a/sketch_may21a.ino sketch_oct20b/sketch_oct20b.ino 
7c7
< unsigned int dt=3333;
---
> unsigned int dt=60000;
32a33
>     delay(dt-1000);
$ 

That results in total led on time of 1 second for each led only, while still it takes 1 minute from lighting a led to the next. And that approach looked promising, here a 200 second long test exposure, lighting 4 leds. Full 1012x760 frame (for artefact details, and here are a lot of artefacts, this is captured with my 2nd HQ camera) here:
https://stamm-wilbrandt.de/en/forum/good_200s.png
good_200s.50%.jpg
good_200s.50%.jpg
good_200s.50%.jpg (12.76 KiB) Viewed 7248 times

Now that everything worked, I did run a 60 minutes long exposure (60:30 min for leaving only 3 of the 64 leds unlit):

Code: Select all

pi@raspberrypi4B2:~ $ ./long_exposure 3630
1 pulses of 39 nanos with gap of 9 nanos (div=2 bits=13)
...
974.999
987.499
1000.000
1012.499
3631110.784
pi@raspberrypi4B2:~ $ ffmpeg -i tst.h264 -ss 3 frame.%04d.png
...
frame=    7 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.28 bitrate=N/A speed=0.294x    
video:1389kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
pi@raspberrypi4B2:~ $ 

The resulting photo "frame.007.png" is proof that really >60 minutes were captured during that long exposure:
frame.0007.50%.jpg
frame.0007.50%.jpg
frame.0007.50%.jpg (37.34 KiB) Viewed 7248 times

Here the full 60 minute long exposure 1012x760 frame captured, without scaling. It shows a lot of artefacts discussed in my previous posting.
https://stamm-wilbrandt.de/en/forum/frame.0007.png


Changing "dt=60000" to "dt=600000" would allow to capture 10h long exposure.
Reducing brightness to 50% can be done by replacing "dt-1000" with "dt-500" in Arduino sketch.
https://github.com/Hermann-SW/RSA_numbers_factored
https://stamm-wilbrandt.de/GS [304+402+536fps]
https://hermann-sw.github.io/planar_graph_playground
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de

User avatar
HermannSW
Posts: 6256
Joined: Fri Jul 22, 2016 9:09 pm
Location: Eberbach, Germany

Re: Raspberry Pi High Quality Camera Long Exposures

Wed Oct 21, 2020 7:05 am

To complete this, I just powered off the constant voltage supply (and therefore the Arduino -- it had and has both of its leds covered with black isolation tape to have no light from the Arduino in dark box), did no other changes. Then I took a 200 second long exposure of darkness (200s corresponds to 1st photo in previous posting). Full 1012x760 frame with the artefacts (I had to convert the 295KB .png to .jpeg for forum attachment) here:
https://stamm-wilbrandt.de/en/forum/lexp/black.png

Code: Select all

$ pngtopnm black.png | pnmtojpeg > black.png.jpg
pngtopnm: warning - non-square pixels; to fix do a 'pamscale -yscale -nan'
$
black.png.jpg
black.png.jpg
black.png.jpg (19.07 KiB) Viewed 7223 times
https://github.com/Hermann-SW/RSA_numbers_factored
https://stamm-wilbrandt.de/GS [304+402+536fps]
https://hermann-sw.github.io/planar_graph_playground
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de

PiGraham
Posts: 5383
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: Raspberry Pi High Quality Camera Long Exposures

Wed Oct 21, 2020 11:17 am

"It's full of stars"

Actually that's a lot better than I was expecting.

You are capturing this with raspivid with h264 compression the splitting out a single frame?
Were you able to disable compression? If not I wonder how much noise and image detail might be lost in the compression.
I should try this. It is very interesting. some shots with raw pixel data would be the test to do.

Return to “Camera board”