Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - LimaKilo

Pages: [1]
Could this be caused by a SD-Card thats gone bad possibly?
 Does this happen on different Memory devices in the Same Way always?

We're saving to a server with a SMB share, so this is definitely not a faulty SD card. Also regular TIFFs are fine, it's only with raw TIFFs and DNGs.

Hi, we've recently switched from saving our images in TIFF to TIFF raw to use the full 12 bit instead of 8 bit images. However, the camera often is saving the wrong frames - the first few will be fine, but then the next frames will be from a totally different time judging from what's visible. It is quite irregular when it happens and from which frame on. What's going on there? The problem doesn't seem to appear when saving regular TIFFs.

It also seems to get worse, a few days ago it was only every few videos, now it seems to happen for each video we film.

The simplest way to remove this is to simply gain up the images enough that the darkest pixels clip to white. You could also use the digital gain option on the record settings screen, but this doesn't have particularly good granularity. Doing it in postprocessing would be the most accurate.

But this means losing at least a third of dynamic range, if taking into account the first 32 columns, more than half.

Do you know what is causing this "premature clipping" and is there a way to fix it?

Also, do you know if this is just uneven clipping or if the individual pixel gains are also affected? Meaning, if I would homogenously expose the sensor with light below white threshold, would I get a homogeneous image or the same pattern as above?

Hi, we're imaging electric arcs with our Chronos 2.1 monochromatic. These are very bright and frequently overexpose the high-speed frames. However, when filtering the overexposed parts of the images, I noticed that the camera starts clipping the pixels at less than the maximum value the 12 bit depth allows and at differing levels for each pixel. Intentionally overexposing the whole image with a lamp shows the pattern in the attached image (colorcoded from blue to yellow for better visibilty).

This issue seems to begin at around 7 kfps at 640x240. In multiple overexposed frames recorded in the same recording, the pattern is exactly the same for each frame.

Is there a way around this or a way to calibrate for this?

Software Dev / Re: Please synchronize frame numbers to trigger
« on: May 13, 2020, 11:30:04 AM »
Thank you for your feedback regarding improvements to our frame timing.

Regarding the remote control of the camera via various methods:

  • The Chronos doesn't run a windowing system like X11, both the video feed and the Qt GUI are directly rendered to the frambuffer in this case.
  • We're a few weeks out from another release that should contain trigger config settings on the webpage that should work for most users' needs. Do you mind me asking what your triggering requirements are like for your setup?
  • For the time being, the best way to handle remote triggering would be with your own calls to our Python API here: (while also acknowledging that it takes some time and effort to work with our API)

Thank you for your reply. Our triggering setup is a plain 50/50 pre/post trigger. I was just using the trigger setup as an example for settings that are not yet in the webpage.

Another detail in the webpage that could be fixed: The framerate is shown as an integer, while in the camera GUI one decimal place is shown. For scientific uses like synchronising video frames to oscillograms it is important to know the interframe time precisely.

Software Dev / Re: Please synchronize frame numbers to trigger
« on: May 11, 2020, 12:46:28 AM »
did you try x11 forwarding over ssh? might work. You should also be able to install vnc servers your self from the debian repositories.

That was the first thing I had in mind, but I don't see an xserver running on the camera. I think there is no desktop and the GUI is directly "sent" to the display, so I have no idea where to start.

Software Dev / Re: Please synchronize frame numbers to trigger
« on: May 08, 2020, 12:02:07 AM »
This is already mostly possible using the webinterface and the latests camera software. Just point your browser to the cameras IP address. The video there is only about 1 FPS for preview, but a 60fps videostream is also available (view it with VLC for example)

I know, but not everything is there, e.g. no trigger settings. VNC access would expose everything you can do on the camera to network with less effort to duplicate everything for the web interface and API access, under the premise that the camera GUI can be shared like a desktop (which I don't know).

Software Dev / Please synchronize frame numbers to trigger
« on: May 07, 2020, 12:05:03 PM »
The numbers of the recorded frames in the play / save dialog and when saving should correspond to the trigger, so that frame 0 is at the time of the trigger and negative frames are before, positive after. When you record a short, fast event with a trigger, as of now you either need to search it in the recording or calculate where it should be based on your trigger settings (which you hopefully haven't changed since recording). This is especially important for scientific uses, where you often want to synchronize the video with e.g. an oscillogram.

I also have some wishes for the video overlay: It would be nice to have the time information in the playback window without having to turn on the overlay for saving. And please consider an option to add the overlay information below / next to the video frames instead of overlaid, so you get the information without losing frame content.

By the way, the network control is really nice to have! In a lab environment, it's very comfortable to be able to do all the necessary work in the web view and save to a network drive without having to touch the camera!

Would it be possible to share the whole user interface of the camera via network, like in a VNC system?

Chronos User Discussion / Re: Extracting still images
« on: May 02, 2020, 01:54:51 AM »
Is there a reason not to trust the camera when it says 1 microsecond?

Verifying the exposure time with simple equipment will be difficult, because 1 μs is just really fast. If you put a 50 mm radius disk on a rotary grinder like a Dremel, at 30k RPM the edge will only travel 0.15 mm in one μs. A bullet flying at speed of sound will travel less than 0.5 mm in one μs.

If you have an oscilloscope, you could try to get a LED to blink for 1 μs and check the pulse length with a photodiode (make sure to check that the LED doesn't phosphoresce like some white LEDs will do).

Chronos User Discussion / Re: transfer video to computer via code
« on: April 07, 2020, 01:00:07 AM »
Is it possible to control the camera from your phone using this adapter?

If you can get your phone to work with the adapter, then yes, it should work. However, it probably won't work with your phone. I have a similar adapter, which is not recognized by my android phone. But the adapter works in principle, I've used it with my laptop and camera, and controlling the camera in the phone browser via ethernet works too.

But if you go shooting, you would probably bring a laptop with you anyways, right? Directly connecting camera and laptop via ethernet or micro USB cable (which provides virtual ethernet) works fine with the right IP settings.

Chronos User Discussion / Re: Introducing Chronos 2.1 HD!
« on: March 16, 2020, 09:32:39 AM »
On our Chronos 2.1 using the new chronos-unstable-20200314.img, I was not able to set a frame size of less than 640x96, and thus no framerate of more than 24k fps.

Pages: [1]