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 - foobar

Pages: [1] 2
Software Dev / Re: Chronos V0.3.1 Beta - Updated Oct 15 2018 with beta-9
« on: February 12, 2019, 10:03:10 AM »
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). 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"

Chronos User Discussion / Re: Fixing corrupt files
« on: January 04, 2019, 03:43:47 PM »
After testing things out a bit, it looks like there is a bug in h.264 file saving that will lead to a crash and file corruption if the MP4 file gets longer than 2GB. This should only be possible when saving very long recordings at very high bitrates, and it should only affect h.264 files. To work around the problem, make sure that the number of frames being saved, divided by the framerate and multiplied by the h.264 bitrate is below 2GB in size.

For example, if you wanted to save 18000 frames at 60fps using the maximum bitrate of 60Mbps would give 18000 frames / 60 fps * 60Mbps = 18Gbits = 2.25GB and would cause the crash to occur.

However, reducing the bitrate to 50Mbps would be fine: 18000 frames / 60fps * 50Mbps = 15Mbit = 1.875GB, and would save without issue.

Chronos User Discussion / Re: Workflow - Time
« on: January 03, 2019, 05:15:24 PM »
Thanks Martin for the excellent post.  Just to share a couple technical details on the Camera's software, It's based on the TI Davinci DM8148 processor, and all of the storage needs to go through that CPU in order to get saved to media. On the storage end of things it supports 3Gbps SATA, SDHC, and, in the future, Gigabit Ethernet.

The maximum theoretical throughput via SDHC should be 25MB/s but in practice that is limited by the performance of your SD cards (the newer UHS standards are not supported by this CPU, but will operate at reduced speeds). SDXC cards can be made to work in the camera, but will probably need to be reformatted as FAT32 or EXT2/3/4 to work with the camera due to the lack of exFAT support on Linux.

The eSATA port is currently the fastest method for saving data, and despite the 3Gbps link, it is limited by the ability of the CPU to update the filesystem, and will hit 100% CPU utilization at around 60MB/s, so most high-performance SSDs are wasted on the Chronos, in fact most spindle drives will be able to keep up with this speed. I do recommend buying a reputable brand though - the kernel on the camera is a little too old for good TRIM support and may suffer after a couple of write cycles. The 120GB Kingston SSDs that have in our lab stock are especially bad in this regard.

The camera also supports a Gigabit Ethernet port that we hope to use for saving to network storage in a future update, but with the extra overhead of network protocols, checksums and the like we don't anticipate it to be much different from saving via eSATA to a decent SSD.

From the RAM to the Camera exists another possible bottleneck; the video port from the FPGA to the CPU operates at a 133MHz pixel clock (or 100MHz before 0.3.1-rc1). After overhead this works out to around 90fps from RAM into the CPU at 1280x1024 (or 60fps before 0.3.1-rc1). At smaller resolutions this can go as high as 250fps before the h.264 video encoder starts to drop frames, so the the software limits the video port to 230fps at all resolutions when saving.

DNG files are encoded in uncompressed RAW format, and will add a 4kB header to each frame. TIFF files are almost identical to DNG, but the pixels will be gamma-encoded 24-bit RGB on color cameras, or 8-bit greyscale on monochrome cameras.

Software Dev / Re: Building Qt-creator
« on: November 22, 2018, 11:41:40 AM »
usr/lib/ should actually just be a symlink to usr/lib/

I am beginning to think that the problem we might have been experiencing all along is that your copy of the targetfs is missing all of its symlinks. It is traditional for a Linux system to name a shared library with its full version in the filename (eg:, and create a symlink from the unversioned library to the versioned one (eg is linked to If your targetfs was missing all its symlinks, then Qt would have a very difficult time trying to find any of its dependencies.

Software Dev / Re: Chronos V0.3.1-RC1
« on: November 20, 2018, 01:02:28 PM »
There is an option to turn upside down, only it swaps the interface, it does not swap the stream and also not the HDMI output, do you confirm?
Yes, we confirm that this is how the option should work. We feel that the orientation of the video as displayed on the LCD should match the orientation of the camera and it becomes confusing if video on the back of the camera is rotated.

I agree that it would make sense to rotate the video being output over the HDMI port when using the camera is upside down, but that is not presently implemented.

Software Dev / Re: Building Qt-creator
« on: November 19, 2018, 12:59:03 PM »
Hey Matom,
  /usr/lib/gcc-cross/arm-linux-gnueabi/5/../../../../arm-linux-gnueabi/bin/ld: cannot find -lOMX_Core
/usr/lib/gcc-cross/arm-linux-gnueabi/5/../../../../arm-linux-gnueabi/bin/ld: cannot find -lgmodule-2.0
/usr/lib/gcc-cross/arm-linux-gnueabi/5/../../../../arm-linux-gnueabi/bin/ld: cannot find -lgobject-2.0
/usr/lib/gcc-cross/arm-linux-gnueabi/5/../../../../arm-linux-gnueabi/bin/ld: cannot find
/usr/lib/gcc-cross/arm-linux-gnueabi/5/../../../../arm-linux-gnueabi/bin/ld: cannot find -lgthread-2.0
/usr/lib/gcc-cross/arm-linux-gnueabi/5/../../../../arm-linux-gnueabi/bin/ld: cannot find -lglib-2.0
/usr/lib/gcc-cross/arm-linux-gnueabi/5/../../../../arm-linux-gnueabi/bin/ld: cannot find -lgstapp-0.10

I am wondering if this is a sign that there is something completely wrong with my libraries or if there is an easy way to get all of them?

I agree, it looks like there is something wrong with your configuration of Qt creator and it's unable to find the libraries from the targetfs. They should all be present in the <path to targetfs>/usr/lib directory. Did you set the Sysroot when configuring the Kit in Qt Creator?

Software Dev / Re: Building Qt-creator
« on: November 14, 2018, 06:22:44 PM »
You might be able to find out a little more info by navigating into the "~/Work/chronos-sdk/qt4-install/config.tests/unix/tslib" folder and running "make", this should attempt to compile a test program to verify the CFLAGS and LDFLAGS necessary for building the tslib components. For example, on my Ubuntu 16.04 virtual machine, and following the v0.3.0 build instructions, I get the following output by running make:

Code: [Select]
osk@virtualbox:~/Work/chronos-sdk/qt4-build/config.tests/unix/tslib$ make
arm-linux-gnueabi-g++ -c -pipe --sysroot=/home/osk/Work/chronos-sdk/targetfs -O3 -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp
-Wall -W  -I../../../../qt-everywhere-opensource-src-4.8.7/mkspecs/qws/linux-omap2-g++ -I../../../../qt-everywhere-opensource-src-4.8.7/config.tests/unix/tslib
-I../../../../qt-everywhere-opensource-src-4.8.7/config.tests/unix/tslib -I. -o tslib.o ../../../../qt-everywhere-opensource-src-4.8.7/config.tests/unix/tslib/tslib.cpp
arm-linux-gnueabi-g++ -Wl,-O1 -o tslib tslib.o     --sysroot=/home/osk/Work/chronos-sdk/targetfs -lts

And my targetfs was created from a v0.3.0 camera, and extracting the update.tgz from the beta-9 update ontop of it. Searching for tslib in the targetfs should give the following hits:
Code: [Select]
osk@virtualbox:~/Work/chronos-sdk/qt4-build/config.tests/unix/tslib$ find /home/osk/Work/chronos-sdk/targetfs/usr | grep tslib

In order to pass the tslib functionality test, Qt needs to be able to be able to find <path to sysroot>/usr/include/tslib.h and <path to sysroot>/usr/lib/

Software Dev / Re: Building Qt-creator
« on: November 12, 2018, 05:29:15 PM »
You have not explicitly asked to use pkg-config and are cross-compiling.
pkg-config will not be used to automatically query cflag/lib parameters for
You can safely ignore this warning, since Qt creator is just letting us know that our target operating system is too simple to make use of the pkg-config tool, and we need to figure out the compiler and linker flags ourselves.

The QtDBus module cannot be enabled because libdbus-1 version 0.93 was not found.

 Turn on verbose messaging (-v) to /home/majtom/Work/chronos-sdk/qt-everywhere-opensource-src-4.8.7/configure to see the final report.
 If you believe this message is in error you may use the continue
 switch (-continue) to /home/majtom/Work/chronos-sdk/qt-everywhere-opensource-src-4.8.7/configure to continue.
This issue seems a lot more serious, and suggests that the Qt configuration tool isn't able to find our libdbus-1 libraries, and that we are likely to fail when running make. I  am also able to get this message from whenever the targetfs is lacking the v0.3.1 update.

And when I try to make from ~/Work/chronos-sdk/qt4-install/qmake I get the following error message:
make: Nothing to be done for 'first'.
If succeeded, there should be a Makefile in the qt4-build directory, and that is where you should be running "make && make install" from. The qmake subdirectory is internal to Qt and you shouldn't need to do anything from there.

I do get a bunch of dbus header files in my targetfs after extracting the update.tgz.

In <path to targetfs>/usr/include/dbus-1.0/dbus I have 22 different header files and in <path to targetfs>/usr/lib/dbus-1.0/include/dbus I only get one: dbus-arch-deps.h. The folder that is referred to in the end of the script ( <path to targetfs>/usr/lib/arm-linux-gnueabi/dbus-1.0/include) does not exist. Could this have something to do with it? Or something about the pkg-config?
Wonderful, that sounds like you have successfully applied the v0.3.1 update to your targetfs. You will probably need to run again after that to make sure that Qt is setup correctly.
The <path to targetfs>/usr/lib/arm-linux-gnueabi/dbus-1.0/include path was added to build on Debian targets, since they structure their include paths a little differently, Qt should simply ignore include paths that don't exist.

Otherwise, is there a way to deploy the camApp V0.2.5 on a camera with FPGA version 3.6?
If you want build software for FPGA version 3.6, then you will just need to check out an earlier version of the chronos-cam-app repository (I would suggest creating a branch starting from the v0.3.0 release tag as v0.2.5 is relatively old and there are some known bugs). The Qt configuration and build process should be very similar, but you won't need the extra tweaks added in v0.3.1 for libdbus. You can find the Qt setup instructions for v0.3.0 here, however, once Qt has been configured for the v0.3.1 it can also build older release of the software too.

Software Dev / Re: Building Qt-creator
« on: November 09, 2018, 12:41:19 PM »
The Qt build instructions have been going through a bit of churn lately as we've been preparing for the v0.3.1 release (which introduced the D-Bus video control API), and as we are preparing to migrate to Debian for future releases. In order for Qt to build successfully with D-Bus support, you will need to use a targetfs that includes the v0.3.1-beta update, this was due to some missing D-Bus libraries and headers that weren't present in the original Arago release.

Suggested resolutions (pick one):
  • Apply the v0.3.1-beta update to your camera, power down the camera and remove the uSD card from the bottom of the camera, then copy the contents of the ROOTFS partition to your targetfs
  • Download the v0.3.1-beta update package, and locate the update.tgz file from the camUpdate folder. Extract the contents of update.tgz onto your targetfs (eg: tar -C <path to targetfs> -xzf <path to update.tgz>)

After that, your targetfs should now  have a bunch of header files in <path to targetfs>/usr/include/dbus-1.0/dbus and <path to targetfs>/usr/lib/dbus-1.0/include/dbus/

Software Dev / Re: Chronos V0.3.1 Beta
« on: October 15, 2018, 12:19:54 PM »
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 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.

  - 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.

Software Dev / Re: Chronos V0.3.1 Beta
« on: October 11, 2018, 03:33:44 PM »
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:

Code: [Select]
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:
Code: [Select]
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:
Code: [Select]
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

Software Dev / Re: Chronos V0.3.1 Beta
« on: October 09, 2018, 10:28:37 AM »
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.

Software Dev / Re: Chronos V0.3.1 Beta
« on: October 05, 2018, 12:05:15 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

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

Software Dev / Re: Chronos V0.3.1 Beta
« 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:
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 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 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.

Software Dev / Re: Chronos V0.3.1 Beta
« on: October 01, 2018, 10:51:46 AM »
Here's a video of the translucent UI:
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.

Pages: [1] 2