Messages

1

Chronos User Discussion / Re: Time tagging

« on: October 31, 2022, 02:09:15 PM »

I solved that by using an external trigger signal and GPS receiver with interrupt input. Specifically the https://github.com/UniversalScientificTechnologies/TIMESTAMPBOX01
But there are trouble logging metadata to recordings because the raw file format does not contain any information about the trigger position.

Therefore the more sophisticated variant of that use case is still unsolved https://forum.krontech.ca/index.php?topic=738.0

2

Software Dev / Re: How the darkframe substraction procedure is implemented?

« on: September 11, 2022, 01:59:47 PM »

 .
 Other Option would be to ask Krontech via their Support. I highly doubt that there is an option to just straight up turn off all Image Processing via the Camera GUI, but maybe there is some Quick Modification you can do to the Firmware via Console or something, like this Mod here:
 https://forum.krontech.ca/index.php?topic=661.msg4585#msg4585
 That way, if it works, you could save yourself a bunch of actual Coding.
 .

I had ask Kronech and hope they will reply in some time.  But there will be a huge help if there will be someone who knows where calibration data are stored in the camera and what neutral calibration data looks like. In that situation calibration files could be replaced by neutral, which effectively disables the image processing pipeline. (But unfortunately does not save the processing time, because the image processing happens, but does not modify the image)

3

Software Dev / Re: How the darkframe substraction procedure is implemented?

« on: September 11, 2022, 01:05:18 PM »

Read a little more about these Cameras, seems like they (or at least some of them) are thermoelectrically cooled, and you can fully control Sensor Temperature?
 That is a Nice Feature, have to say.
 If you happen to own one of these, what kind of Sensor Temperature would you typically want to run these at?
 Also how much of an issue is Condensation, and if Condensation is Happening, what to do against it?

A will reply to private messages, to keep the focus on the actual topic there.

4

Software Dev / Re: How the darkframe substraction procedure is implemented?

« on: September 11, 2022, 02:43:12 AM »

Just two Questions:
 Are there Even Cameras that let you see / Modify the Darkframe / Sensor Calibration Data which it internally uses to process its image data, and if there are, what would anyone use that for?
 You are also aware, that there already usually is quite a bit of processing, that is happening before Cameras save an image, even in RAW format, like for example Removal of Dead Pixels and so on ( https://de.wikipedia.org/wiki/Pixelfehler#Pixelfehler_in_der_Digitalkamera ), and most likely a bunch more nobody cares about in average day to day use?
 .

Of course, there are plenty of cameras for astronomers, which are a good example of scientist which really needs raw data from the image sensor. For an example of these cameras look at: https://www.gxccd.com/

Is there an option (even in the case of modifying the camera calibration files) to completely disable the image "enhancement" pipeline in the Chronos camera?

5

Software Dev / How the darkframe substraction procedure is implemented?

« on: June 09, 2022, 03:27:35 AM »

Hello,

for the scientific application, I need to know the exact way, and how the data from the sensor are processed. We made some attempts to analyze that directly from the camera output.  Our results are:

• Camera substracts darkframe even in case of "RAW" data output
• There is no exact control of what darkframe file is actually or has been used for the substraction

Especially the first point is quite strange because the 'RAW' data are supposed to be RAW, therefore we expect unprocessed values directly from the image sensor. Is there some option to disable dark frame subtraction at the least for raw12 data output? Where is the darkframe or black calibration applied? Is there some other processing made on "RAW" data? Is there a possibility to backup the required data and process the image outside from camera?

I'm attaching the screenshot where the subtraction of intentionally incorrect dark-frame is visible in all output formats (RAW12bit, TIFF, TIFF-RAW)
   

6

Software Dev / Re: Save RAW via Web interface

« on: June 06, 2022, 11:05:20 AM »

Hello,
I will attempt to reply as another scientific user of chronos camera.

Although I understand your points. And in the beginning, we have the same requirements. I must admit that the existing currently implemented workflow is much better than these possible improvements.

The requirement

I would love to be able to save to NFS/SMB drive in 12-bit RAW via the web browser control without having to touch the camera at all.

could be perfectly solved by using the camera REST API instead of the web interface. 
It solves also much more because there could be used specific name format, which precisely corresponds to the experiment.  Then allows for minimizing mistakes introduced by the operator.

The second requirement for exFAT support does not improve anything than the file size limit. There will be still many troubles with flash disk malfunction introduced by inappropriate filesystem for flash memory and poor performance of the old-fashioned filesystem. The NFS or SMB storage is the better option even from point of transfer speed, is faster than SDcard and only slightly slower than eSATA drive.

7

Software Dev / PPS Timestamp input

« on: February 09, 2022, 11:16:48 AM »

Hello,  I am wondering if there could be possible to process the PPS signal https://en.wikipedia.org/wiki/Pulse-per-second_signal to get accurate timestamping of video frames. 
The idea is to combine the PPS signal with system time (synchronized by NTP) to get the accurate time of every video frame.





I hope that it could be an alternative to time tagging relative to the trigger.  The trigger-based time tagging has an issue that the exact time of trigger start must be known.  Therefore the control by API is not possible, because it has an unknown delay to start recording.  Accurate system time solves that, because even in case the start of video recording is unknown, the whole video shoot could be precisely aligned to data measured by other instruments based on the absolute timestamp.

I need it to study lightning where multiple cameras should be triggered on the same lightning event. Unfortunately, the multiple cameras are spread over a range of more than 15km, therefore it is not possible to trigger it by a single coaxial cable. I am only able to connect the cameras to the single ethernet-based network with relatively low latency.
 

8

Chronos User Discussion / Time tagging

« on: July 15, 2021, 02:58:31 PM »

What is the best way to capture a video, which should be possible to time-align to absolute time (e. g. UTC.)? The required precision of time alignment should be comparable to the exposure time.
I noticed that there is possible to install the ntpd to the camera OS, which is a good base for timing. But I do not know how to mark the system time precisely to the video.

Also, I noticed that there is a time in the text overlay, It seems it always shows a time of around 17xxx seconds. But It is unclear for me which time is a zero?

9

Software Dev / Re: Lightning capture - time discontinuity

« on: July 15, 2021, 02:25:12 PM »

I have modified the trigger script in a way, that minimizes a possible disturbance of the camera video system by repeated requests. The new script version checks status before action.
It seems that time discontinuities are gone.

But the relevant trouble is the question, how to immediately restart the recording without periodic checking of file saving state?  In the case of external trigger initiated recording. There is an "Auto record" option that could be set from the camera menu. It ensures that recording is started immediately after the completion of the saving procedure.  Unfortunately, this option seems to have no effect in the case of file saving started from HTTP API.

10

Software Dev / Lightning capture - time discontinuity

« on: July 11, 2021, 05:51:23 AM »

Hello,

I am trying to set up an all-sky system to capture lightning for a thunderstorm research project.  The one partially successful result is here: https://youtu.be/TS5qrMavIaQ?t=18
It has been captured manually by controlling the camera from the web interface.

Today I want to improve the setup with the prepared python script https://github.com/ODZ-UJF-AV-CR/CRREAT_cars/blob/master/chronos_camera/record_trigger.py  which I intend to use for saving the video records.
I supposed the camera should be activated by manually enabling the "Recording" from the web interface.  From the preliminary tests, this expectation looks correct.

Unfortunately in the field during a thunderstorm, I captured the following video: https://www.youtube.com/watch?v=sA-Q35_yDNA
The video contains multiple time inconsistencies which are visible on movements of raindrops and clouds. The exact time inconsistencies are on 0:14, 0:26, 0:36, 0:50, 1:01 etc.  Despite the fact, the text overlay claims the video has around 8 seconds the recorded video looks more like a timelapse of the sky during the save of video buffers (which takes several minutes).

Therefore I modified the script during the thunderstorm to stop recording before save.

Code: [Select]

+                post = requests.post('http://chronos.lan/control/stopRecording')
+                time.sleep(2)
                 post = requests.post('http://chronos.lan/control/startFilesave', json = {'format': 'h264', 'device': 'mmcblk1p1'})
                 print("Camera recording: " + post.reason)

The result is in the following video: https://www.youtube.com/watch?v=3rmiTgen3hA

Although the lightning was really captured in the middle of the video, there is at least one-time glitch on 2:21 of video time.

What is the correct workflow to capture and save few last seconds (for example latest 3seconds) of video from the video buffer by using the HTTP API?

Thanks for the quick reply in advice, the thunderstorm season is short.