Author Topic: Software V0.3 Beta - Updated May 3 2018  (Read 66716 times)

Loial

  • Krontech
  • Newbie
  • *****
  • Posts: 24
    • View Profile
Re: Software V0.3 Beta
« Reply #30 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?

gyppor

  • Newbie
  • *
  • Posts: 49
    • View Profile
Re: Software V0.3 Beta
« Reply #31 on: December 25, 2017, 03:45:53 PM »
I'm trying to reproduce the issue right now but no deal. The camera was cold (10 degrees) at the time I originally had the issue. I was just messing with the camera so I didn't get any footage. I'll try to put it in the garage for a while and let it cool down, and see if it does the same thing when cold.

On another note, is reducing minimum vertical resolution below 96 pixels on the docket for the next update?

CR0M3

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: Software V0.3 Beta
« Reply #32 on: December 29, 2017, 04:25:48 AM »
Today i upgraded my 8GB Cam to 32GB by using amazon.de/gp/product/B01LFQH95Q/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1
and after changing the record time to max. everything works perfect.

patrickrebstock

  • Full Member
  • ***
  • Posts: 114
  • playing camera
    • View Profile
    • patrickrebstock.com
Re: Software V0.3 Beta
« Reply #33 on: December 31, 2017, 06:48:45 AM »
Hmm I had never run into this problem before this firmware and had shot tons of footage on one card , the same card intact. So we can only use 8gb? I think this needs to be solved because what seemed to work before now kinda make the camera unusable for me. I need to br able to keep shooting
i have run into a few issues where it wont save to card because it says there is not enough space but i checked the card and there was 100gigs of space, once removed sd card i could not get it to recognize again in the playback and settings menu with the refresh button, just had to loose the clip and reboot

Yeah, I've had the same issue with losing access to the SD card slot after an out of space error until I reboot. I think the SD drive fails to be properly unmounted so inserting a new SD card won't work because the mountpoint is 'busy'. The USB ports don't seem to have this problem - if you use an SD card reader in the USB port you may have better luck.
hmm im not saving raw just h264

I think the out of space error is happening because (a) the software can't seem to write past the first 8 gb of a fat32 partition and (b) fat32 has a 4gb file size limit - you can hit that easily when saving RAW. I found a temporary workaround to be to format your drive for Linux ie. ext3.  You just have to install some 3rd party software on mac/windows to read the files off. Another way around might be to partition to the drive into lots of 8gb fat32 segments, which would probably give faster saving, although you'll still get hit with the 4gb file size limit and it'll be a pain to use.  Devs can correct this if I am mistaken.

CR0M3

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: Software V0.3 Beta
« Reply #34 on: December 31, 2017, 04:04:00 PM »
Same here today. I use a 64GB SD-Card fat32 and after 3,39GB of PixelStuff the  Camera said nope. Enough is enough.
But i got all my Firework-Stuff on Video so i dont really care c:

Dan D

  • Newbie
  • *
  • Posts: 19
    • View Profile
Re: Software V0.3 Beta
« Reply #35 on: January 01, 2018, 03:26:36 AM »
Hi guys

can you confirm the ordering that bytes are written out for greyscale 12-bit packed RAW images?  I'm writing code to unpack them and it only works for certain resolutions, which is really weird. Not sure if bug in camera, or my mistake.

I'm reading chunks of 3 bytes at a time from my file, and converting this into a pair of pixel values.  Most of the time it works, but when I change the frame rate & resolution, on occasion I'm getting complete garbage out, even though the on screen display looks good. RAW decoding works reliably at full resolution.

hexdump shows that the data in the unreadable file is somewhat correct (dark regions mostly zeros and bright regions have higher values at the correct points in the file given what I know about the lighting level) but decoding the pixel values in the same way that works at full res. just returns static.  Total length of file is correct. As a wild guess, I've tried putting an offset or a bit shift into the start point for reading the file, but this doesn't seem to help. Any suggestions? Can provide sample RAW files (good & bad) which are movies of the same thing, if necessary.

Cheers,
Dan.

NoDak

  • Jr. Member
  • **
  • Posts: 58
    • View Profile
Re: Software V0.3 Beta
« Reply #36 on: January 01, 2018, 07:36:35 PM »
Same here today. I use a 64GB SD-Card fat32 and after 3,39GB of PixelStuff the  Camera said nope. Enough is enough.
But i got all my Firework-Stuff on Video so i dont really care c:
Yea, finally got around to updating my camera.

New version works great, but on h264 the files now take 700 MB each. That is not a problem, always good to have max quality and edit down in post, except for the fact that I am running into the same 4GB save limit, on a 64 gb card, that others are having

tesla500

  • Krontech
  • Full Member
  • *****
  • Posts: 218
    • View Profile
    • krontech.ca
Re: Software V0.3 Beta
« Reply #37 on: January 01, 2018, 11:20:30 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.

Dan D

  • Newbie
  • *
  • Posts: 19
    • View Profile
Re: Software V0.3 Beta
« Reply #38 on: January 02, 2018, 02:55:16 AM »
Hi guys

can you confirm the ordering that bytes are written out for greyscale 12-bit packed RAW images?  I'm writing code to unpack them and it only works for certain resolutions, which is really weird. Not sure if bug in camera, or my mistake.

I'm reading chunks of 3 bytes at a time from my file, and converting this into a pair of pixel values.  Most of the time it works, but when I change the frame rate & resolution, on occasion I'm getting complete garbage out, even though the on screen display looks good. RAW decoding works reliably at full resolution.

hexdump shows that the data in the unreadable file is somewhat correct (dark regions mostly zeros and bright regions have higher values at the correct points in the file given what I know about the lighting level) but decoding the pixel values in the same way that works at full res. just returns static.  Total length of file is correct. As a wild guess, I've tried putting an offset or a bit shift into the start point for reading the file, but this doesn't seem to help. Any suggestions? Can provide sample RAW files (good & bad) which are movies of the same thing, if necessary.

Cheers,
Dan.

I did a bit of playing around with the 12-bit packed RAW format data, and I found a bug in the way the files are written out when the resolution is reduced. The data is in the file, it's just surrounded by what looks like junk bytes -it appears a buffer is overflowing during save. The images appear properly on the display so the copy in RAM is ok.

There seem to be 2 issues. The first is that the scanlines seem to be written out rounded up to the nearest 16 bytes, obviously this doesn't always play well given that the scanline is 1.5N bytes long. Depending on the size of the image there can be a couple of junk bytes between lines. The other issue, which I've not yet been able to solve, is that there can be a huge amount of junk data between frames, which looks to me like a buffer overflow. For example if I reduce down to 336 x 96 pixels images for the max possible frame rate, then I can easily have half a frames' worth of nonsense bytes between each frame. I have no idea how to figure out where each frame is about to start in the binary stream, as the length of this junk region varies from file to file, making decoding pretty much impossible. Happy to help on fixing this bug as it's a show stopper for me until we can figure it out!

Cheers
Dan.

NoDak

  • Jr. Member
  • **
  • Posts: 58
    • View Profile
Re: Software V0.3 Beta
« Reply #39 on: January 02, 2018, 05:13:31 AM »
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

Loial

  • Krontech
  • Newbie
  • *****
  • Posts: 24
    • View Profile
Re: Software V0.3 Beta
« Reply #40 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.

Dan D

  • Newbie
  • *
  • Posts: 19
    • View Profile
Re: Software V0.3 Beta
« Reply #41 on: January 04, 2018, 04:05:53 AM »
Thanks, good to know. I'm sure there's a way to unpack the files, all the data is in there somehow! :-)

tesla500

  • Krontech
  • Full Member
  • *****
  • Posts: 218
    • View Profile
    • krontech.ca
Re: Software V0.3 Beta
« Reply #42 on: January 04, 2018, 05:06:04 PM »
V0.2.5 Beta posted, see the first post.

NiNeff

  • Full Member
  • ***
  • Posts: 169
    • View Profile
Re: Software V0.3 Beta - Updated Jan 4 2018
« Reply #43 on: January 05, 2018, 01:59:10 AM »
With 0.2.5 I was now able to update my camera without issues. But I used a different USB stick, which might also have helped. On towards testing the new features ;D

patrickrebstock

  • Full Member
  • ***
  • Posts: 114
  • playing camera
    • View Profile
    • patrickrebstock.com
Re: Software V0.3 Beta - Updated Jan 4 2018
« Reply #44 on: January 05, 2018, 08:09:25 PM »
got the could not save no space bug again today, came back to my computer and saw you had the update and updated the camera and it seems to be working! thanks