Author Topic: Chronos V0.3.1 Beta - Updated Oct 15 2018 with beta-9  (Read 2319 times)

Tabatha_Hughes

  • Krontech
  • Newbie
  • *****
  • Posts: 6
  • Operations Manager
    • View Profile
Chronos V0.3.1 Beta - Updated Oct 15 2018 with beta-9
« on: September 27, 2018, 11:39:38 AM »
Hey guys,
EDITED. Please note the changes to Features, Minutiae, and Fixed Bugs.

Here is the V0.3.1 beta-9. Remember, do not use this software version if you are capturing something that is not easily replicated. Here are the notes on the update:
    +----------------------------------+
  ++                                          ++
    |   Chronos V0.3.1.9 Changelog   |
  ++                                          ++
    +----------------------------------+

Notable Changes:
 - New Demosaic algorithm based on AHD, which should improve color reproduction and reduce edge noise.
 - Standalone daemon to operate the video system, with DBus API.
 - External HDMI displays are supported at 1080p and 720p resolutions.
 - Recording speed improvements.
 - Add CinemaDNG and TIFF as save file formats.
 - Deprecate Raw 16-bit right-justified save format in favor of CinemaDNG.
 - Add a demo mode to replay a section of recorded video in a loop.
 - Add option to overlay frame statistics onto processed video formats (H.264 and TIFF).
 - Jog wheel can be used to adjust the exposure, and navigate the settings menus.
 - New video memory recovery tool to download video (slowly) in the event of a software crash.
- Redesign of the white balance window, including a new dialog to edit the color matrix.

Minutiae:
 - Add whitebalance preset for 3200K/Tungsten lighting.
 - Adjust highlighting of text when selecting text boxes.
 - Auto-record and auto-save modes independant of one another.
 - Improved algorithm to estimate framerate during file save.
 - Date format in the Utility window changed to shorten the Month string.
 - Display separate version strings for both the Application and Filesystem/Release.

Fixed Bugs:
 - Crash causing the video to freeze after approximately 45 recording attempts.
 - Trigger delays would scale incorrectly when using segmented recording mode.
 - Abort recordings when the free space drops below 20MB to avoid crashing when the disk is full.
 - UI bug causing the selected save location to always select the first mounted disk.
 - First frame of a raw recording would contain corrupted NV12 image data.
 - First pixel of a Raw 12-bit packed frame was sometimes being dropped.
 - Corrupted pixels at the end of a Raw 12-bit packed frame.
  - Add crosshairs to the white balance window.
  - Add Qt stylesheet to improve focus visibility.
  - Main window exposure now shown in microseconds and shutter angle.
  - Jog wheel now adjusts exposure logarithmically, or by degrees when pressed.
  - The 'close' button on the soft keyboard now applies the entered text.
  - Reorganization of the soft keyboard to include a negative key.
 - Black ares of the UI become transparent after an HDMI hotplug.
  - HDMI hotplug while on the playback window would revert to live display.
  - Add missing ColorMatrix1 and CalibrationIlluminant1 tags to CinemaDNG files.
  - Fix possible crash of the video system when aborting a file save.
  - Fix possible carsh of the UI when rapidly aborting and re-starting a file save.
  - Fix color correction math so that saturating the image sensor tends towards white.
Also, some bugs that were introduced in beta-4 but now fixed:
  - Monochrome TIFF now pads the pixel values with least-significant zeroes.
  - H.264 bitrate setting was being ignored and defaulting to 0.25 bpp.

Compatibility Issues:
 - The pixel packing order in Raw 12-bit mode has been changed for the v0.3.1 release.
   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)

Known Bugs:
 - The first frame of an H.264 recording is erroneously copied from the display buffer before the recording starts.

Please let us know what you think of the updates. And most importantly, let us know the bugs and things you do not like about the update. If there are any serious issues, please email support@krontech.ca.

Updating Your Camera
-Extract the .zip file into the root directory of a FAT32 formatted USB drive.
-Turn on your camera and insert the USB drive.
-From the main window, tap the Util button to open the utility window.
-As a precaution, tap the Backup Calibration Data button on the utility window before starting the update.
-When the backup is completed, a pop-up window will be displayed.
-Tap the Done button to close the pop-up window.
-From the utility window, tap the Apply Software Update button to begin the software update.
-A warning message will be displayed, tap the Yes button to confirm and begin the update.
-During the update, the screen will go blank and an Applying Update message will be displayed.
-After approximately 60 seconds, the update will be complete and the camera will restart.
« Last Edit: October 15, 2018, 05:32:34 PM by tesla500 »

Johnny

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: Chronos V0.3.1 Beta
« Reply #1 on: September 27, 2018, 12:42:46 PM »
Nice update!
For some reason the CinemaDNG does not build previews on my Mac. DaVinci Resolve and Adobe Camera Raw cannot read them.
Is there something I'm missing here?

JamesB

  • Newbie
  • *
  • Posts: 41
    • View Profile
Re: Chronos V0.3.1 Beta
« Reply #2 on: September 27, 2018, 07:03:31 PM »
I can see the thumbnail previews but both Photoshop and After Effects give import errors on Windows.

Really hope the files are not useless because I just spent 2hrs shooting them  :-\

DDR

  • Krontech
  • Jr. Member
  • *****
  • Posts: 96
    • View Profile
    • Krontech
Re: Chronos V0.3.1 Beta
« Reply #3 on: September 27, 2018, 08:01:04 PM »
I think it should be a matter of adding some tags to the non-loading files. We've figured out what tags are needed, but we're still getting things sorted here. Sorry about that!

patrickrebstock

  • Full Member
  • ***
  • Posts: 102
  • playing camera
    • View Profile
    • patrickrebstock.com
Re: Chronos V0.3.1 Beta
« Reply #4 on: September 28, 2018, 07:49:16 PM »
getting erratic behavior with the hdmi, usually doesnt work(just black feed) until i record a clip then go to playback, then it starts giving a video feed other than black pixels
Stoked to have it and see if it can get more reliable, using 502 bright small hd monitor, great to have this option thanks!

getting freezing about 6 times so far when saving in playback, with monitor plugged in, havent tried with out monitor, both in h264 but more in cinema dng, seemed like i only got sucesssful save in super short raw cinema dng clips,  camera becomes frozen and requires restart power cycle,
thats it so far will test more

NiNeff

  • Jr. Member
  • **
  • Posts: 88
    • View Profile
Re: Chronos V0.3.1 Beta
« Reply #5 on: September 29, 2018, 02:35:40 AM »
I've now had a chance to test the beta quickly.
Here are my first impresions:

 - Gernerally smooth updateprocess and it feels great to use.
 - YAY! HDMI!  :) :) :) :) Had no issues at all, recoring in different resolutions and playing back works fine!
 - maybe display the "saving" info also on the HDMI output if possible instead of a black screen
 - The Jog-Wheel select is a great addition, but it is really hard to see what is currently selected. Please make the highlight more pronounced, especially if a text-enty field is selected instead of a button, you can barely make it out.
 - The direction in which the UI elements are scrolled through with the Jog-Wheel differ from screen to screen and just feel inconsistent. If I turn the wheel to the right I'm expecting the "cursor" to go to the right in general.
 - Frame Overlay is a great addition!
 - The Preset-Resolutions are wierdly offset to the top
 - The font in the UI screens is not acually black but you can see the videofeed throuh them. I tried to take a picture of it but it really only is visible in motion. Maybe you set the alpha channel to zero by accident? It is very prominent on the Radioboxes, as they are a larger "hole" throuh the UI.
 - The Focus Aid almost always has as a solid line to the left of the screen. I guess this is inherent to it's design as the line dissapears if you're filming darker colors. This might be avoidable if you copy the left most lines to an invisible bufferzone bevore running the edge-detection. Probably not worth the hassle.
 - The whitebalace should not be set to Tungsten as default. Maybe use Average Daylight?
 - add a quit/canel button to all tabs of the Utils menu...
 - It would be really great to be able to click the wheel in the main menu to start/stop the recording!
« Last Edit: September 29, 2018, 02:38:32 AM by NiNeff »

NiNeff

  • Jr. Member
  • **
  • Posts: 88
    • View Profile
Re: Chronos V0.3.1 Beta
« Reply #6 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 ;)

Dan Kanes

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: Chronos V0.3.1 Beta
« Reply #7 on: September 30, 2018, 08:49:10 PM »
This is AWESOME!

Three crazy questions for you:

1. On your next camera can you have the main ram be based on intel Optane... Look how cheap these are:
https://amzn.to/2QlmOJ5

2. What can I do to speed up saving exports ? like will it be faster to save over Gig-E? Is ESATA working ?

3. I'm getting arouns 1fps saving to a USB 3.0 stick... does that sound right?

Dan Kanes

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: Chronos V0.3.1 Beta
« Reply #8 on: October 01, 2018, 08:51:03 AM »
Added feedback:

saving TIFFs or CinemaDNG to USB Drive results in zero byte files, and the unprompted ejection of the USB media.

both seem to work fine for me to SD Card at the moment.

foobar

  • Krontech
  • Newbie
  • *****
  • Posts: 17
    • View Profile
Re: Chronos V0.3.1 Beta
« Reply #9 on: October 01, 2018, 10:25:06 AM »
This is AWESOME!

Three crazy questions for you:

1. On your next camera can you have the main ram be based on intel Optane... Look how cheap these are:
https://amzn.to/2QlmOJ5

2. What can I do to speed up saving exports ? like will it be faster to save over Gig-E? Is ESATA working ?

3. I'm getting arouns 1fps saving to a USB 3.0 stick... does that sound right?

Hey Dan,

Right now the fastest saving method is via the eSATA port, which can typically sustain write speeds of about 60MB/s before the CPU runs out of speed, or about 25fps when saving raw at 1280x1024. To use this method you will need a 5V SATA drive (this includes almost all 2.5" drives), and an eSATA+power cable such as these available from Monoprice or Amazon

As for USB flash drives, I have quite a few cheap USB drives that exhibit absolutely terrible write performance (as low as 1fps as you have commented), as far as I can tell it seems to vary quite widely as to how well they perform under heavy write loads.

foobar

  • Krontech
  • Newbie
  • *****
  • Posts: 17
    • View Profile
Re: Chronos V0.3.1 Beta
« Reply #10 on: October 01, 2018, 10:51:46 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 ;)

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

  • Full Member
  • ***
  • Posts: 102
  • playing camera
    • View Profile
    • patrickrebstock.com
Re: Chronos V0.3.1 Beta
« Reply #11 on: October 01, 2018, 06:48:13 PM »
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

  • Newbie
  • *
  • Posts: 10
  • Digital experiences for screens & spaces
    • View Profile
    • yipp.nl
Re: Chronos V0.3.1 Beta
« Reply #12 on: October 02, 2018, 03:20:10 AM »
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

  • Newbie
  • *
  • Posts: 15
    • View Profile
Re: Chronos V0.3.1 Beta
« Reply #13 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:
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)

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
« Last Edit: October 05, 2018, 07:04:38 AM by Dan D »

foobar

  • Krontech
  • Newbie
  • *****
  • Posts: 17
    • View Profile
Re: Chronos V0.3.1 Beta
« Reply #14 on: October 05, 2018, 10:53:21 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)

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  :)

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.

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.

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.