Messages

1

Software Dev / Save RAW via Web interface

« on: February 16, 2022, 10:49:17 PM »

Hi,

We use a set of Chronos 1.4s cameras in scientific research labs and are very happy. The way we use the camera requires us to do a RAW 12 bit binary save format of the entire camera RAM at once. I have two questions about features we really need in order to be able to use the cameras the way we want. I don't think these are too hard to implement and would be happy to help with beta testing.

Right now, the "Save Format" drop-down in the Chronos 1.4's web interface offers only H.264, CinemaDNG, TIFF, and TIFF RAW.  Is there any way we can add 12-bit and 16-bit binary RAW formats to the web interface? They're visible in the Save Settings menu on the Chronos touch screen, just not in the browser. I imagine this is a simple thing to fix? 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.

Secondly, any plans for ExFAT support? If I want to dump the entire RAM of the camera into a single file, I can't use FAT32 due to the 4GB limit. Right now I am using an EXT3 formatted USB disk which works about half the time -- aborted saves can sometimes happen, often without a visible error message, and mounting the disk on Mac/Windows requires 3rd party software. ExFAT would really help. Would it be possible to build a kernel module that we can load in to enable it, even if it can't be baked into the system image if there are licensing issues?

Great work Krontech, keep it up!

Dan

2

Software Dev / Re: Chronos V0.3.1 Beta - Updated Oct 15 2018 with beta-9

« on: February 19, 2019, 04:36:56 AM »

Thanks - 0.3.1-rc1 is working fine for me now :-)

3

Software Dev / Re: Chronos V0.3.1 Beta - Updated Oct 15 2018 with beta-9

« on: February 11, 2019, 11:10:46 PM »

Just rolled my camera back to software 0.3.1 beta4 and the Frame Sync Out works again. Can confirm this is definitely a firmware bug and not a hardware issue.

I'm trying out the 0.3.1 Beta-9 software and I've found a major bug. Since I updated, I can't choose any IO mode other than "Record End Trigger". If I select "Frame Sync Output", "Shutter Gating" or "Exposure Trigger" modes for either IO1 or IO2 and press "OK", the UI immediately reverts to "None"

4

Software Dev / Re: Chronos V0.3.1 Beta - Updated Oct 15 2018 with beta-9

« on: February 11, 2019, 08:59:59 PM »

Hi guys

I'm trying out the 0.3.1 Beta-9 software and I've found a major bug.

Since I updated, I can't choose any IO mode other than "Record End Trigger". If I select "Frame Sync Output", "Shutter Gating" or "Exposure Trigger" modes for either IO1 or IO2 and press "OK", the UI immediately reverts to "None" no matter what recording mode I'm in.  The same thing is happening on multiple cameras.

I checked on an oscilloscope and I'm no longer getting a frame sync output signal even if I choose it and hit "Apply". This is a showstopper - I can't synchronise my strobe light source without the Frame Sync Out and will have to roll back to an earlier version of the firmware. Any suggestions?

Dan D.

5

Software Dev / Re: Chronos V0.3.1 Beta - Updated Oct 15 2018 with beta-9

« on: November 25, 2018, 09:26:03 PM »

I took a look at the pySciCam code to see how you were doing the byte unpacking and I think that our implementations agree. In the read_chronos_raw() function, you're reading the three bytes and converting them to an integer, which on a little-endian machine I think would produce a 24-bit integer of 0x23c1ab on v0.3.0, or 0xab1c23 on v0.3.1 using our example pixels of {0x123, 0xabc}.

Duh, I should have realised. That makes sense! Thanks. Nice work!

6

Chronos User Discussion / Re: Chronos 1.4 Footage Thread

« on: November 25, 2018, 09:19:41 PM »

We use the Chronos 1.4 in our Mechanical Engineering laboratories and also to perform neat classroom demos for some of our undergraduate classes.
Here's a collection of movies that we've taken using the Chronos over the last year. Enjoy!

https://youtu.be/Dl2GPjaLrdM

7

Software Dev / Re: Chronos V0.3.1 Beta

« on: October 05, 2018, 07:02:20 AM »

Hi,

I can report success with V0.3.1 beta on my camera! The live HDMI output and faster black calibration is fantastic.  I'm putting together a bunch of sample videos of what the students in our lab have been using the cameras for over the last 12 months and will hopefully get something on YouTube by the end of the year.

FYI, I've found two quirks with file saving in the new version.

i) The 12-bit RAW packing that I'm seeing on my camera is different to what is advertised. If anyone else is having headaches decoding raw packed data, read below.

The changelog says:

Given a pair of two 12-bit pixels in hexidecmal as (0x123, 0xabc), the bytes produced
   by the Raw 12-bit packing mode changes as follows:
     v0.3.0 and earlier: (0xab, 0xc1, 0x23)
     v0.3.1 and later: (0x23, 0x1c, 0xab)

But my test comparing the same data saved in 16 bit and 12 bit actually reveals:
Given a pair of two 12-bit pixels in hexidecmal as (0x123, 0xabc), the bytes produced
   by the Raw 12-bit packing mode are:
     v0.3.0 and earlier: (0x23, 0xc1, 0xab)
     v0.3.1 and later: (0xab, 0x1c, 0x23)

I'm building a Python module for my students to use that handles the raw read-in to a NumPy array across various formats using PythonMagick, you can see it at https://github.com/djorlando24/pySciCam. There are sample RAW images proving that the weird byte ordering above actually works, at least for the 3 cameras we have 

ii) TIFF files are being written with unusual metadata tags that ImageMagick doesn't like, would be nice to fix this so we don't see so many warnings flashing up when converting files.

Code: [Select]

$ identify test/chronos14_rgb_tiff/chronos14_rgb_001.tiff
test/chronos14_rgb_tiff/chronos14_rgb_001.tiff TIFF 1280x1024 1280x1024+0+0 8-bit sRGB 3.75391MiB 0.000u 0:00.009
identify: Unknown field with tag 42033 (0xa431) encountered.
`TIFFReadCustomDirectory' @ warning/tiff.c/TIFFWarnings/995.
Cheers,
Dan

8

Software Dev / Re: Software V0.3 Beta - Updated Jan 4 2018

« on: January 26, 2018, 02:30:29 AM »

Hey Dan, I've tried this but couldn't get it to work. I used EaseUS Partition Manager to format a USB stick Ext3, but when I put it in the Chronos it isn't recognised.

Can you reveal what utility you used to format ext3 and also what you use to read the files? I'm using PCs here.

I stuck the stick in my Mac, and used the e2fs tools (installed with Homebrew) to format it - i.e. the mkfs.ext3 command, which works the same in Linux as it does on the Mac. I read the contents off the stick either from my Linux PC, or using the Paragon ExtFS for Mac (paid) software. I've never tried to format or read a linux drive in Windows. You could try using a Linux virtual machine to do it?

9

Software Dev / Re: Software V0.3 Beta

« on: January 04, 2018, 04:05:53 AM »

Thanks, good to know. I'm sure there's a way to unpack the files, all the data is in there somehow! :-)

10

Software Dev / Re: Software V0.3 Beta

« on: January 02, 2018, 02:55:16 AM »

Hi guys

can you confirm the ordering that bytes are written out for greyscale 12-bit packed RAW images?  I'm writing code to unpack them and it only works for certain resolutions, which is really weird. Not sure if bug in camera, or my mistake.

I'm reading chunks of 3 bytes at a time from my file, and converting this into a pair of pixel values.  Most of the time it works, but when I change the frame rate & resolution, on occasion I'm getting complete garbage out, even though the on screen display looks good. RAW decoding works reliably at full resolution.

hexdump shows that the data in the unreadable file is somewhat correct (dark regions mostly zeros and bright regions have higher values at the correct points in the file given what I know about the lighting level) but decoding the pixel values in the same way that works at full res. just returns static.  Total length of file is correct. As a wild guess, I've tried putting an offset or a bit shift into the start point for reading the file, but this doesn't seem to help. Any suggestions? Can provide sample RAW files (good & bad) which are movies of the same thing, if necessary.

Cheers,
Dan.

I did a bit of playing around with the 12-bit packed RAW format data, and I found a bug in the way the files are written out when the resolution is reduced. The data is in the file, it's just surrounded by what looks like junk bytes -it appears a buffer is overflowing during save. The images appear properly on the display so the copy in RAM is ok.

There seem to be 2 issues. The first is that the scanlines seem to be written out rounded up to the nearest 16 bytes, obviously this doesn't always play well given that the scanline is 1.5N bytes long. Depending on the size of the image there can be a couple of junk bytes between lines. The other issue, which I've not yet been able to solve, is that there can be a huge amount of junk data between frames, which looks to me like a buffer overflow. For example if I reduce down to 336 x 96 pixels images for the max possible frame rate, then I can easily have half a frames' worth of nonsense bytes between each frame. I have no idea how to figure out where each frame is about to start in the binary stream, as the length of this junk region varies from file to file, making decoding pretty much impossible. Happy to help on fixing this bug as it's a show stopper for me until we can figure it out!

Cheers
Dan.

11

Software Dev / Re: Software V0.3 Beta

« on: January 01, 2018, 03:26:36 AM »

Hi guys

can you confirm the ordering that bytes are written out for greyscale 12-bit packed RAW images?  I'm writing code to unpack them and it only works for certain resolutions, which is really weird. Not sure if bug in camera, or my mistake.

I'm reading chunks of 3 bytes at a time from my file, and converting this into a pair of pixel values.  Most of the time it works, but when I change the frame rate & resolution, on occasion I'm getting complete garbage out, even though the on screen display looks good. RAW decoding works reliably at full resolution.

hexdump shows that the data in the unreadable file is somewhat correct (dark regions mostly zeros and bright regions have higher values at the correct points in the file given what I know about the lighting level) but decoding the pixel values in the same way that works at full res. just returns static.  Total length of file is correct. As a wild guess, I've tried putting an offset or a bit shift into the start point for reading the file, but this doesn't seem to help. Any suggestions? Can provide sample RAW files (good & bad) which are movies of the same thing, if necessary.

Cheers,
Dan.

12

Software Dev / Re: Raw video format

« on: December 29, 2017, 07:40:54 AM »

I've just pushed a beta version of my Python package that reads Chronos RAW files to Github.

It's part of a larger package for scientific imaging data formats that I'm working on that reads weird camera file formats into easy to use NumPy arrays which can then be exported to any format you like with about 2-3 lines of code.  I've included support for the 0.2.3 beta RAW formats 'chronos14_12bit_noheader' and 'chronos14_16bit_noheader' where the user must specify the height and width of the frame as there is no metadata / header in the file itself at this stage. The actual file reading is done in C (via cython) so it's pretty fast.  The package also handles standard formats ie. 8/16/32 bit TIFF, H.264 movies etc. using ImageMagick and FFMpeg libraries.  Tested working on MacOS, should work on Linux too.  I will test it on Ubuntu next week.

I only have monochrome cameras, so I've not incorporated colour sensor RAW support yet. If someone would like to send me sample 12 and 16 bit RAW files from a colour camera, I'd be happy to add support for it.

Once we have a header scanline added, I'll add more RAW formats to the list of supported ones.

https://github.com/djorlando24/pySciCam.git

13

Software Dev / Re: Raw video format

« on: December 24, 2017, 03:55:23 AM »

Awesome, thanks! I just finished writing a Cython library to import the 12 bit packed RAW files into 16-bit arrays for post analysis and conversion in Python. This will be useful for those of us who like to write our own post processing and image analysis tools and do fancy time-series analysis. I'll start a Github project for it eventually! Incorporating a metadata scanline will make things much more user friendly.

14

Software Dev / Re: Software V0.3 Beta

« on: December 21, 2017, 06:23:04 PM »

i have run into a few issues where it wont save to card because it says there is not enough space but i checked the card and there was 100gigs of space, once removed sd card i could not get it to recognize again in the playback and settings menu with the refresh button, just had to loose the clip and reboot

Yeah, I've had the same issue with losing access to the SD card slot after an out of space error until I reboot. I think the SD drive fails to be properly unmounted so inserting a new SD card won't work because the mountpoint is 'busy'. The USB ports don't seem to have this problem - if you use an SD card reader in the USB port you may have better luck.

I think the out of space error is happening because (a) the software can't seem to write past the first 8 gb of a fat32 partition and (b) fat32 has a 4gb file size limit - you can hit that easily when saving RAW. I found a temporary workaround to be to format your drive for Linux ie. ext3.  You just have to install some 3rd party software on mac/windows to read the files off. Another way around might be to partition to the drive into lots of 8gb fat32 segments, which would probably give faster saving, although you'll still get hit with the 4gb file size limit and it'll be a pain to use.  Devs can correct this if I am mistaken.

15

Software Dev / Re: Chronos Cam App open source build discussion

« on: December 21, 2017, 04:20:21 PM »

Outstanding! Looking forward to playing around with it