KronTalk
Chronos => Software Dev => Topic started by: Tabatha_Hughes on September 27, 2018, 11:39:38 AM
-
Update: 0.3.1 has been moved to release candidate, please see this thread (http://forum.krontech.ca/index.php?topic=434.0) for the latest software update.
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 [email protected].
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.
-
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?
-
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 :-\
-
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!
-
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
-
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!
-
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 ;)
-
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?
-
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.
-
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 (https://www.monoprice.com/product?p_id=8492) or Amazon (https://www.amazon.com/UGREEN-Power-Esata-eSATAp-Cable/dp/B00HL87BQK/)
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.
-
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.
-
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
-
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)
-
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 (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.
$ 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
-
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 (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 (https://github.com/krontech/chronos-utils/blob/master/python_raw2dng/pyraw2dng.py#L328) 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 (https://www.adobe.com/content/dam/acom/en/products/photoshop/pdfs/dng_spec_1.4.0.0.pdf) 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.
$ 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.
-
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
Thanks for the bug report, unfortunately we are not having much luck in attempting to replicate the issue. We suspect that it might have something to do with your SmallHD monitor. It would be interesting to know if you get the same problem when you have the camera connected via HDMI to a different monitor (or TV).
-
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.
The standard is now more than 2 years old, so it's not a really cutting edge feature. I therefore looked around and imagemagick indeed does not support the "new" tags yet. I therefore created an initial pull-request to add those tags. I have now idea if it will work or if it will be accepted, but at least I tried ;D
-
Any plans to support Touch Screen HDMI Monitors?
-
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.
The standard is now more than 2 years old, so it's not a really cutting edge feature. I therefore looked around and imagemagick indeed does not support the "new" tags yet. I therefore created an initial pull-request to add those tags. I have now idea if it will work or if it will be accepted, but at least I tried ;D
My pull-request actually got accepted and merged, so the next imagemagick version might support the "new" Tags. I'd say keep them for now!
-
I am trying to update one of my cameras and I can't get the update to be found on the USB drive. I have the USB formatted to FAT32 and I am able to save videos to the USB but if I try to eject the USB I get an error and every time I try to update it gives me a message saying can't find
Serial number 00146
Application rev 0.2
FPGA rev 2
Do I need to upgrade to a different rev first? I was able to get the update to work on one of our newer cameras
-
I am trying to update one of my cameras and I can't get the update to be found on the USB drive. I have the USB formatted to FAT32 and I am able to save videos to the USB but if I try to eject the USB I get an error and every time I try to update it gives me a message saying can't find
Serial number 00146
Application rev 0.2
FPGA rev 2
Do I need to upgrade to a different rev first? I was able to get the update to work on one of our newer cameras
You should be able to upgrade from any version from 0.2 and newer using the update package. However the application can sometimes be rather finicky of where it expects to find the update. It is looking for a folder at /media/sda1/camUpdate, but depending on the formatting of your USB drive it might sometimes be mounted at /media/sda/camUpdate if you formatted the USB drive without a partition table.
One way to check is to record some footage, insert the USB drive and go to the Save Settings menu on the Playback screen. If the USB drive appears in the dropdown menu as '/media/sda' then it hasn't been formatted correctly.
-
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 (https://www.monoprice.com/product?p_id=8492) or Amazon (https://www.amazon.com/UGREEN-Power-Esata-eSATAp-Cable/dp/B00HL87BQK/)
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.
I have a question Foobar. I tried to do everything that you specified in order to save raw files to SSD via eSata, but I can not manage to make the chronos camera detect the SSD.
I bought 120GB kingston SSD, esata+power cable (exactly as in the amazon link you sent) and I have the 0.3.1 beta version installed.
Can someone point me out how can I make the Chronos recognize the SSD?
Thanks!
-
Did you format the drive?
If yes, which file system did you chose?
-
Hi,
I agree with BiduleOhm. I got a similar problem both on USB key of large capacity and on a SD card of large capacity also. They were exFAT formatted which is the current format for windows. To be recognized you need to use either FAT32 format if you get a PC computer (you can find a freeware able to do this as current PC with windows 7 and higher only use exFAT for large capacity support) or format in ext2 or ext3 if you are a Linux user.
Hope this help
Bernard
-
Did you format the drive?
If yes, which file system did you chose?
Oh I forgot to mention that. I formatted it in Ext3 as was suggested before. I also tried the Ntfs, Fat32 and Exfat without success.
-
By the way, big thank to David and his team. The last improvements in the software are really amazing and being able to shoot RAW almost converts Chronos 1.4 in another camera (much better one). Keep the great work!
-
Nikon1 and I did quite a bit of testing together today and I think we found some more bugs. I'm going to try again sometime this week and post details then.
We also shot some amazing footage, expect some of it to show up on the forums here ;)
-
Very glad, that we finaly made it happen, will post some of that soon here.
Thanks
-
I have a question Foobar. I tried to do everything that you specified in order to save raw files to SSD via eSata, but I can not manage to make the chronos camera detect the SSD.
I bought 120GB kingston SSD, esata+power cable (exactly as in the amazon link you sent) and I have the 0.3.1 beta version installed.
Can someone point me out how can I make the Chronos recognize the SSD?
Unfortunately it's a little hard to diagnose why the Chronos isn't recognizing your SSD remotely. If you can open an SSH connection to the camera there are some useful diagnostics that we can run. But first, here are some details of what has worked well for me in the past. The Chronos should accept either a DOS or a GPT partition table, and my SSDs have a partition table as follows:
root@dm814x-evm:~# fdisk -l /dev/sda
Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
/dev/sda1 1 9729 78148161 83 Linux
Then we can unmount, and reformat the drive as FAT32, and then remount it as follows:
root@dm814x-evm:~# umount /dev/sda1
root@dm814x-evm:~# mkfs.vfat -n TESTSSD /dev/sda1
mkfs.vfat 2.11 (12 Mar 2005)
root@dm814x-evm:~# mount -t auto /dev/sda1 /media/sda1
To do the same with an Ext3 filesystem, we would instead use the following commands:
root@dm814x-evm:~# umount /dev/sda1
root@dm814x-evm:~# mkfs.ext3 -L TESTSSD /dev/sda1
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=TESTSSD
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
4890624 inodes, 19537040 blocks
976852 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=0
597 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 26 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
root@dm814x-evm:~# mount -t auto /dev/sda1 /media/sda1
-
Ok now the "new" issues I found:
- The FPS and Frame Time input fields in the Record settings behave erratically. If you enter any FPS and leave with "close", the field remains at that entered value, but does not update the "Sec" field. When then recording the old FPS value is used. If you instead change the lower "Sec" field and leave with close, the recording actually uses that corresponding framerate without updating the FPS field in the UI.
- If you use the (kind of hidden) "Apply" button on either input field, the other one changes correctly. However it sometimes changes the order of magnitude (for example 1000 FPS to 1000000 mFPS) which is not only confusing, but also inconvenient since the magnitude "letter" is not selected for new inputs if you click on the field and has to be deleted manually.
- If you lower the FPS rate below the current one, exposure time also gets lowered in the same rate. For example 1500 FPS to 1000 FPS lowers the exposure from 1000 µS to 660 µS. This is is done "quietly" and therefore easy to miss.
- Not really something changeable, but the red "Low Battery" indication looks a lot like the "recording" light, especially in the dark. We lost one shot that way but luckily the experiment was easy to redo. And you can argue it was user error ;)
- This might not actually be a camera/sw bug, but the produced DNGs can't be opened by my Photoshop (CS5 with CameraRaw 6.7.1). As far as I can tell it basically complains (understandably) that it is has now idea about the used Camera Model – I was however able to open the DNGs with UFRaw, so maybe there are just a few settings missing in the files or Photoshop can't actually display DNGS from "unknown" cameras at all. Probably related to the Error mentioned by JamesB
Some general improvement ideas for a possible future hardware version which surfaced during the last testing:
- a hinged display which can be "detached" and swiveled around would be really handy
- the recording indicator could also be useful on the front in addition to the top and back
- while the cs mount is a great choice for size and available lenses, changing lenses via screwing is not nearly as nice (or quick) as using some form of bayonet-coupling
-
- This might not actually be a camera/sw bug, but the produced DNGs can't be opened by my Photoshop (CS5 with CameraRaw 6.7.1). As far as I can tell it basically complains (understandably) that it is has now idea about the used Camera Model – I was however able to open the DNGs with UFRaw, so maybe there are just a few settings missing in the files or Photoshop can't actually display DNGS from "unknown" cameras at all.
.
The DNG´s directly from the camera also wont open with none of my Software: Photoshop CS2, Photoshop CS6 Extended or AfterEffects CS6.
But someone uploaded DNG´s here in the Forum, which presumeably where generated by that pyton-Tool, those open just fine with my software (not tested on PS CS2...).
So there should be some way to get DNG´s directly out of camera which would be able to be opened with common Software i guess. Would most likely just be some small problem there, but i honestly have no idea how exactly those Files/ Container-Formats/ Tags on the Files work.
-
The DNG Read problem for Adobe software is being worked on, some tags were missing or modified. Once that update is ready I will resume testing. Should be a breeze to shoot DNG Sequences outright and it also makes it possible to save much longer clips as file size limits do not interfere as each image is under 2MB and you can basically fill the card to the brim. :D
-
any info on faster saving time with the Cinema DNG?
-
Thanks so much for the excellent feedback! We've tried to fix the reported issues with an updated the beta, please see the first post for a link to the updated camUpdate-v0.3.1-beta-9-geb319ea.zip installer package. To give a brief description of what has changed since the beta-4 package:
Notable Features:
- Redesign of the white balance window, including a new dialog to edit the color matrix.
Minutiae:
- 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.
Fixed Bugs:
- 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 (not mentioned in changelog.txt):
- Monochrome TIFF now pads the pixel values with least-significant zeroes.
- H.264 bitrate setting was being ignored and defaulting to 0.25 bpp.
-
Thanks so much for the excellent feedback! We've tried to fix the reported issues with an updated the beta, please see the first post for a link to the updated camUpdate-v0.3.1-beta-9-geb319ea.zip installer package. To give a brief description of what has changed since the beta-4 package:
Notable Features:
- Redesign of the white balance window, including a new dialog to edit the color matrix.
Minutiae:
- 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.
Fixed Bugs:
- 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 (not mentioned in changelog.txt):
- Monochrome TIFF now pads the pixel values with least-significant zeroes.
- H.264 bitrate setting was being ignored and defaulting to 0.25 bpp.
Nice! I did a really quick test. the updateprocess went smooth, the new features are there and the colored highlight really helps to select stuff with the jogwheel.
Will test it thoroughly sometime this week, especially the color stuff.
-
Will test the Beta .9 soon, thank you for the update and bug fixes!
-
Thanks so much for the excellent feedback! We've tried to fix the reported issues with an updated the beta, please see the first post for a link to the updated camUpdate-v0.3.1-beta-9-geb319ea.zip installer package. To give a brief description of what has changed since the beta-4 package:
Notable Features:
- Redesign of the white balance window, including a new dialog to edit the color matrix.
Minutiae:
- 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.
Fixed Bugs:
- 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 (not mentioned in changelog.txt):
- Monochrome TIFF now pads the pixel values with least-significant zeroes.
- H.264 bitrate setting was being ignored and defaulting to 0.25 bpp.
Is there something else missing from the CinemaDNG tags? Even Photoshop cannot open the files. No previews in macOS.
-
Is there something else missing from the CinemaDNG tags? Even Photoshop cannot open the files. No previews in macOS.
I'm having no trouble with the new beta 9 and Photoshop CS5 now.
-
Is there something else missing from the CinemaDNG tags? Even Photoshop cannot open the files. No previews in macOS.
I'm having no trouble with the new beta 9 and Photoshop CS5 now.
TIFF files open with no issues. CinemaDNG does not open in Davinci Resolve or in Photoshop CC 2019. Even Lightroom CC 2015 does not want them.
And yes I'm using beta 9.
-
Is there something else missing from the CinemaDNG tags? Even Photoshop cannot open the files. No previews in macOS.
I'm having no trouble with the new beta 9 and Photoshop CS5 now.
TIFF files open with no issues. CinemaDNG does not open in Davinci Resolve or in Photoshop CC 2019. Even Lightroom CC 2015 does not want them.
And yes I'm using beta 9.
Could you upload a problem DNG file here so we can investigate?
-
Hello, the new Software seems to be very interesting! I would like to test it too - in particular, I would like to connect an external monitor via hdmi, but I am not able to install it yet. That's why I ask for help: I use an adapter cable from usb mini male to usb A female, so I can connect an usb-stick directly to the usb-otg-connection socket of chronos 1.4. The used stick offers otg-functionality. but I have not succeeded so far that the stick is recognized as a usb drive! I also can't save the calibration data to the usb drive; the display shows always the message: "Error: no device is mounted to /media/sda1". What can I do?
Thank you for helpful answers!
Winfried
-
Just plug the USB stick in the USB (A) port of the camera (same port as the eSATA port actually), no need for OTG cable or other things.
-
Thank you so much! :) So easy updating - and it work's - great!
-
DNG capture works great, usable on the latest CC no problems. I found a bug that some 1st frames would come out blank but it is only on some clips not all of them, wonder if it has to do with the memory buffer? CinemaDNG is now my one stop for the Chronos, it is just a breeze to use and the post abilities and increased resolution compared to H.264 make the Gigabytes of files worth it. Next stop HDMI testing!
The camera has really grown since the early days, love the ability to see shutter degrees as well much appreciated! Is there a 1/sec option buried somewhere? Degrees is fine but fractions of a second make it much easier to freeze blur without converting degrees. I have found that 1/4000 works very well on the Chronos for freezing and obliterating most day to day objects that are much slower than a bullet.
-
I am trying to update from 0.2, but it seems it can't find the update. When I try to backup the calibration data, it says "Error: no device is mounted to /media/sda" and if I try to update it says "No software update found".
In the Save settings it says the save Location is "/media/mmcblk1p1 (SD Card Partition 1)". I can save clips just fine to the card and they show up in the root directory.
The card was formatted in FAT32. The update file was extracted to the root of that card.
What am I doing wrong here?
-
I have several USB sticks (all sandisk) and only one of them works for updating but all of them work for saving video. Maybe try another stick and see if that works.
-
I am trying to update from 0.2, but it seems it can't find the update. When I try to backup the calibration data, it says "Error: no device is mounted to /media/sda" and if I try to update it says "No software update found".
In the Save settings it says the save Location is "/media/mmcblk1p1 (SD Card Partition 1)". I can save clips just fine to the card and they show up in the root directory.
The card was formatted in FAT32. The update file was extracted to the root of that card.
What am I doing wrong here?
Seems like you are trying to update from a SD Card. This is not supported (yet).
You have to use the USB-Port on the side using a FAT32 formatted Stick. As mentioned above several users had issues so far. You might have to try more than one USB Stick.
Also: Don't try to use the USB-OTG port (the smaller one) – use the USB / E-SATA combined one instead.
-
re.
- Standalone daemon to operate the video system, with DBus API.
Does that mean we will get a QT app soon that runs on the PC to control the camera?
-
re.
- Standalone daemon to operate the video system, with DBus API.
Does that mean we will get a QT app soon that runs on the PC to control the camera?
yes but not a qt app. it will be a webinterface as I understand it
-
Is there something else missing from the CinemaDNG tags? Even Photoshop cannot open the files. No previews in macOS.
I'm having no trouble with the new beta 9 and Photoshop CS5 now.
TIFF files open with no issues. CinemaDNG does not open in Davinci Resolve or in Photoshop CC 2019. Even Lightroom CC 2015 does not want them.
And yes I'm using beta 9.
Could you upload a problem DNG file here so we can investigate?
Sorry for the wait. Did not have my camera with me on my trip.
Here is one CinemaDNG and one TIFF.
These are straight from the camera.
-
Is there something else missing from the CinemaDNG tags? Even Photoshop cannot open the files. No previews in macOS.
I'm having no trouble with the new beta 9 and Photoshop CS5 now.
TIFF files open with no issues. CinemaDNG does not open in Davinci Resolve or in Photoshop CC 2019. Even Lightroom CC 2015 does not want them.
And yes I'm using beta 9.
Could you upload a problem DNG file here so we can investigate?
Have the same problem... I can't open the .dng from the camera... not with lightroom, not with photoshop... with nothing :( attached one dng
-
Is there something else missing from the CinemaDNG tags? Even Photoshop cannot open the files. No previews in macOS.
I'm having no trouble with the new beta 9 and Photoshop CS5 now.
TIFF files open with no issues. CinemaDNG does not open in Davinci Resolve or in Photoshop CC 2019. Even Lightroom CC 2015 does not want them.
And yes I'm using beta 9.
Could you upload a problem DNG file here so we can investigate?
Have the same problem... I can't open the .dng from the camera... not with lightroom, not with photoshop... with nothing :( attached one dng
try the new v9 beta i think thats fixed now
-
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!
-
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.
-
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"
-
Hey Dan,
This is a known issue with the beta-9 release, we recommend that you try out the release candidate software instead (see this thread (http://forum.krontech.ca/index.php?topic=434.0)). If that doesn't work, please let us know if there are issues with the 0.3.1-rc1 update.
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"
-
Thanks - 0.3.1-rc1 is working fine for me now :-)