Chronos > Software Dev
Chronos V0.3.1 Beta - Updated Oct 15 2018 with beta-9
foobar:
--- Quote from: NiNeff on September 29, 2018, 02:53:38 AM ---Here's a video of the translucent UI: https://youtu.be/CraeQdpt9ck
Also: the Demo mode could be enabled by default and just always add the "Play" button to the "Play" Screen, but rename it to "Loop". I had to fiddle around quite a bit to realize how the demo mode works and where to find it ;)
--- End quote ---
Darn! I thought I had fixed the UI transparency bug but it has come back to haunt me! Thank you for reporting it, I'll have to do more investigation there.
patrickrebstock:
yeah saw the transparent ui on my side too,
shot some water housing and had no more crashed saves, i was saving h264 though not cinema dng
https://youtu.be/se79vSrOmPw
love this camera and its progress
ThomasYiPP:
I've set up the auto save and auto record but after the a random amount* it doesn't want to save anymore.
It jumps to the playback/save screen but jumps back immediately, if I then stop auto record-save and try to record something it only says it recorded 0 frames.
If I try to record anything and look back at it it says 0 frames.
Only a reboot can make it ok again.
*(It happened once around 5, once around 15 and once around 30 so far)
Dan D:
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:
--- Quote ---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)
--- End quote ---
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: ---$ 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.
--- End code ---
Cheers,
Dan
foobar:
--- Quote from: Dan D on October 05, 2018, 07:02:20 AM ---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:
--- Quote ---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)
--- End quote ---
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 :)
--- End quote ---
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}.
For a comparison, we updated our pyraw2dng.py tool to support the 12-bit packed files too.
So, the obvious question might be, why did we go through the trouble of changing the bit packing format for 12-bit raw mode at all? Well, I must admit that we never really tested the 12-bit packed format in enough depth to show that it generated equivalent data to the 16-bit modes. In preparing for the v0.3.1 release we finally got around to testing it and we found a number of troubling bugs:
- The video input port on the CPU has a bug where it will swap the R and B channels when reading 24-bit raw data from the camera, meaning that first and last bytes were being swapped for every pair of pixels before hitting the disk.
- The camera would randomly drop the first pixel when saving in 12-bit packed mode. This is probably not apparent when viewing monochrome video, but on a color camera will shift the resulting image relative to its bayer filter.
- The final scan line of an image would contain corrupted data.
So, the new packing order is attempting to follow the DNG specification recommendation on BitsPerSample when packing 12-bit data. Which I interpreted to mean that bytes should be arranged in little-endian order, with big-endian fill order whenever a byte has to be split between pixels.
--- Quote from: Dan D on October 05, 2018, 07:02:20 AM ---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: ---$ 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.
--- End code ---
--- End quote ---
The offending tag in this case is in the EXIF image metadata, and should be the BodySerialNumber as defined by the EXIF 2.3 standard. It looks like the version of libtiff being used by ImageMagick only supports tags up to EXIF 2.2. I guess I should make a note to remove that tag from the TIFF format if it's not widely supported by image processing software.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version