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

Pages: [1] 2
Chronos User Discussion / Re: Maze artifact with 1.4
« on: June 21, 2019, 07:27:31 PM »
It looks like the data being saved in raw is off by one pixel or line. This was caused by some pixels or lines being lost while saving the video which in turn makes the demosaic in the DNG viewer/editor software fail.

What version of camApp and, if it shows it in the util menu, what FPGA version?

As for recovering, there's a way but it's a bit involved and technical.

If your comfortable with a hex editor you can use The GIMP to open the raw file as type 'data' to find the offset needed then remove those bytes from the top of the file. In the options while opening the 'data' file you select greyscale-16bit, set the horizontal and vertical size to match what you shot, then use the offset entry to skip forward a few frames then offset until the image is lined up. Once you have that offset figured out, remove that many bytes from the top of the RAW file and retry running the script and viewing the result. If it still has artifacts, add or remove two bytes until it looks correct. If it looks extremely corrupt, remove only one byte.

A much better option is to save DNG directly using one of the newer software releases. DNG saving is far more reliable than the older RAW mode and gives the added benefit of saving some metadata such as the resolution, whiteballance, etc.

I hope this helps, let me know if you need further details.

Good news - I was able to reproduce the issue in simulation and easily tracked down the variables that were causing issues. I've fixed them but the changes need to make their way back into the main code. We should be able to make an update that removes this artifact in the next couple days.

take a look at the image issues on high contrast moving water with the new firmware, pretty funky stuff going on, can this be worked on?
focus still off its biased too close

Oh, ya, sorry - I'm currently working on it. It was a problem I noticed a few weeks ago right after releasing the new demosaic update but I had no way to actually reproduce it without sunlight against water and even then it was just only barely noticeable (the above video is no longer barely noticeable and is a great representation of the issue).

Today I just found a way to recreate it in the office and am working on where the issue is within the demosaic - use a non-white light and saturate the sensor.

The new demosaic for initial testing showed better single-pixel white lite handling than most others I tested; rather proud of that. The problem shown above is a situation where some of the math within the FPGA is corrupted, probably due to a rollover of a variable used in the demosaic.

Thanks very much for the example and as soon as I have a fix we'll release an update with it.

Chronos User Discussion / Re: Serial numbers.
« on: July 31, 2018, 07:40:08 PM »
I'm all 1337 and do haxors. I have 00000

Chronos User Discussion / Re: transfer video to computer via code
« on: July 31, 2018, 07:35:44 PM »
Here's the script as it stands. It requires a few libraries and needs to be run on a computer connected to the camera via USB.

The libraries it needs are: plumbum, parimoko

EDIT: This is now obsolete, use the script attached to the 2nd post in this thread.

Chronos User Discussion / Re: External hard drive not recognized
« on: July 28, 2018, 04:51:48 AM »
Another thing this may be caused by is using a different partition table type than the old MBR type.

A way to find out what's happening is to SSH into the camera by connecting a computer to the USB-mini port. The camera will show up at with the user root with no password. You can then run 'dmesg' after plugging in the drive.

Chronos User Discussion / Re: External hard drive not recognized
« on: July 26, 2018, 07:58:03 PM »
One of the most important details: How big is the drive in total? If it's larger than 2TB it's not currently supported even if the individual partitions are less than this.

The camera supports FAT32 as well as EXT2/3 and doesn't support NTFS. It should autodetect those and offer them for saving to.

Software Dev / Re: Raw video format
« on: January 27, 2018, 04:42:42 PM »
While I don’t yet have a dog in this race, I would just like to mention that the filmmaking community would really appreciate colour and monochromaic CinemaDNG support. Although we’re not strangers to converting esoteric formats in to something more usable, support for DNG (uncompressed and JPEG92 lossless) is well entrenched thanks to companies like Blackmagic Design.

Thanks for all the hard work! Looking forward to using one of these cameras some day soon. :)

Thanks! I've been trying to track down which software supports JPEG92 lossless and I've been at a loss for it. This is the format I'd really like to implement as it will give the best save-speed while still keeping a full lossless format.

Software Dev / Re: raw video data
« on: January 27, 2018, 04:36:43 PM »
Hello. I also use the camera in a research environment and normally analyse high speed camera pictures (in TIFF or Jpg or bmp) in Matlab. I have tried various saving options in this camera but none seems to have high enough resolution to be of any use in my contour-detection code. I see the fuzzy object boundaries, which I think is down to compression. Can anybody please suggest appropriate saving options to reduce compression? Thanks a lot! I have the colour version. 

Sorry about the late response.

The raw formats don't have any compression applied. They're currently not packed as TIFFs(DNGs) but it's in the works to do so.

Software Dev / Re: Software V0.3 Beta - Updated Jan 4 2018
« on: January 13, 2018, 01:42:14 PM »
Splitting this up into another post since this is unrelated to the last issue.

When "Auto Save" is selected, pressing "Stop" on the touch screen causes the camera to begin auto saving. The problem is that there is no way, that I can see, to disarm the camera when auto save is enabled. You will have to let the camera start saving and then abort the save, which is both inconvenient and puts lots of files on the memory card you never wanted to put there in the first place.

Don't know what the best solution would be, but figured I should mention it.

There's a rather undocumented method - If you go into any setting menu (io, recording, etc.) it'll give you a warning that it'll stop record and then it should go to the menu without saving.

Chronos User Discussion / Re: How to achieve fastest save times.
« on: January 02, 2018, 03:34:17 PM »
TI's implementation of Linux and the video pipeline requires a memcpy from video buffer memory into the kernel space. This saturates the CPU making the whole copy slow.

Right now we're looking into making our own gstreamer pipeline element that can use DMA to copy to the drive instead. This will be in the works as a test once we have network control at least prototyped.

Software Dev / Re: Software V0.3 Beta
« on: January 02, 2018, 03:15:37 PM »
We've experienced the same issue over the Christmas break, with the camera saying there's no free space when there clearly is enough. We'll be fixing that first thing when we go back to work tomorrow. I'll post here when we have a fix.
Thanks for the update.

Overall this is a very good update. Just one minor bug for everyone.  ;D

The packed format is the least tested one out of the new raw formats. It also uses some weird configuration to make it work correctly which is probably why the data is being messed up on the saving side. Specifically the FPGA is configured to give an image which is half the horizontal resolution. The pipeline should be correctly handling this but there's a chance it's not.

Another important thing of note is that the architecture is 32-bit and the data is 24-bit. This means it'll probably align the data either at frame boundaries or possibly line boundaries and can potentially mess up the data.

Software Dev / Re: Saving setting across reboots is BAD
« on: January 02, 2018, 03:07:47 PM »
Good to hear feedback from both sides.

We'll look into making an option that reverts settings on launch and defaults to disabled.

Software Dev / Re: Software V0.3 Beta
« on: December 24, 2017, 11:13:11 PM »
I'm having a minor issue after the update - when I use very low resolutions, especially 336x96, I get one flashing horizontal brown line near the top of the frame and one flashing blue line near the middle. These show after a black calibration. I'm assuming this has to do with the RAM temperature - I sometimes had the flashing line issue in the past running previous firmware versions but it was always resolved by performing a black calibration. Now black cal doesn't eliminate the lines.

My camera is serial #18 running software version 0.3. I do have an edited resolutions file, I'm not sure if this would cause any issues?

Do these show up in the final video as well? I'll see if I can reproduce it here. Is the shutter at maximum or at some other value?

Software Dev / Re: Software V0.3 Beta
« on: December 24, 2017, 11:10:24 PM »
Due to forum problems please remove all spaces after slashes in the following before use.

Right now you can connect a usb-mini cable to the OTG port and connect it to a computer. It'll show up as a network device and offer DHCP for 192.168.12.x. It'll be at You can then ssh into the camera with root and any password.

If you kill the camera app "killall camApp" you can then edit the settings file "/ Settings/ KronTech/ amApp.conf" and restart the camera application "/ etc/ init.d/ camera start".

By using Auto Record and Auto Save modes you can get the camera to automatically save a buffer to the SD card using an external trigger signal. When combined with the methods above you can get very rudimentary control and operation of the camera. Any settings that are not possible will default to another value so it's better to configure the camera in advance. Also there is no provision for blackcal or other functions which means that if you're on an arbitrary resolution that has not been calibrated yet, image quality will be poor.

The saved files will be under "/ media/ mmcblk1p1/ " and timestamps or file naming can be used to determine which one is the latest.

I don't have any scripts that do this directly, just one that can manipulate the files and download the latest and the like (we use this for final calibration, filesystem and os testing). When I'm back from Christmas I can get some of the source up.

Pages: [1] 2