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
1
Software Dev / Re: Building Qt-creator
« on: November 22, 2018, 11:41:40 AM »
usr/lib/libOMX_Core.so should actually just be a symlink to usr/lib/libtiomx.so.5.2

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: libfoo.so.1.2.3), and create a symlink from the unversioned library to the versioned one (eg libfoo.so is linked to libfoo.so.1.2.3). If your targetfs was missing all its symlinks, then Qt would have a very difficult time trying to find any of its dependencies.


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

3
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 -l:libxml2.so.2
/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?

4
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
/home/osk/Work/chronos-sdk/targetfs/usr/include/tslib.h
/home/osk/Work/chronos-sdk/targetfs/usr/lib/opkg/info/tslib-conf.list
/home/osk/Work/chronos-sdk/targetfs/usr/lib/opkg/info/qt4-embedded-plugin-mousedriver-tslib.list
/home/osk/Work/chronos-sdk/targetfs/usr/lib/opkg/info/tslib-calibrate.control
/home/osk/Work/chronos-sdk/targetfs/usr/lib/opkg/info/qt4-embedded-plugin-mousedriver-tslib.control
/home/osk/Work/chronos-sdk/targetfs/usr/lib/opkg/info/tslib-conf.control
/home/osk/Work/chronos-sdk/targetfs/usr/lib/opkg/info/tslib-tests.list
/home/osk/Work/chronos-sdk/targetfs/usr/lib/opkg/info/tslib-calibrate.list
/home/osk/Work/chronos-sdk/targetfs/usr/lib/opkg/info/tslib-tests.control
/home/osk/Work/chronos-sdk/targetfs/usr/lib/directfb-1.4-5/inputdrivers/libdirectfb_tslib.so
/home/osk/Work/chronos-sdk/targetfs/usr/lib/pkgconfig/tslib.pc
/home/osk/Work/chronos-sdk/targetfs/usr/lib/pkgconfig/tslib-1.0.pc
/home/osk/Work/chronos-sdk/targetfs/usr/lib/qtopia/plugins/mousedrivers/libqtslibmousedriver.so

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/libts.so

5
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
dependencies
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 qtconfig.sh 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 qtconfig.sh 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 qtconfig.sh 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 qtconfig.sh 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.

6
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/

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

8
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

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

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

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

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

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

14
The HDMI port will be enabled in the 0.4 release when the networking control support is added.

Part of the work to get the networking control working has involved a rewrite of the OMX and gstreamer video pipelines. During that rewrite we have added HDMI support and it works reasonably well - with some caveats. Due to internal limitations on the OMX components from TI, the HDMI port will only work in 720p and 1080p modes. Fortunately this covers most displays on the market, but some oddball displays may not work.

15
Software Dev / Re: Chronos Cam App open source build discussion
« on: December 27, 2017, 11:50:37 AM »
The failure in the Deploy step sounds very similar to some of the issues I encountered when trying to get QT creator working on Ubuntu 17.04, what I found was that newer versions of QT were getting some paths wrong and trying to find the free space of a directory that didn't exist on the target. Rather than trying to figure out why, I simply switched my development machine back to Ubuntu 16.04 LTS, which seemed to work just fine. Can you check which version of Ubuntu and QT creator you're using?

Pages: [1] 2