Beta release of Linux capture application

[JamesF]

I wasn't sure I'd ever get here   It's taken rather longer than planned.  Putting binary distributions together takes ages

I'm pleased to announce that the third (and beta) release of my Linux capture software is now available as both 32-bit and 64-bit x86 and ARMv6 binaries and source.

source code: http://www.openastroproject.org/wp-content/uploads/2014/02/oacapture-0.0.3-beta.tar.bz2

binaries: http://www.openastroproject.org/wp-content/uploads/2014/02/oacapture-0.0.3-beta-bin.tar.bz2

If you're building the source, please read the files in the docs directory first otherwise you're likely to get nowhere fast.

I have used this application for capturing images of Jupiter, but opportunities for "real life" testing have been few and far between this winter.

It should work with the SPC900 and many, if not all, of the ZWO ASI camera models though I've only tested against the ASI120MM and ASI120MC.  Likewise the Imaging Source CCD cameras should all work, but I have only tested with some of the DxK21 models.  The QHY5 seems to work for me but the documentation is limited and I wouldn't like to guarantee it.  Certainly it is very unreliable on the Raspberry Pi.  The Xbox and Lifecam cameras will work, but require a bit of kernel-hackery.

As well as many bugfixes this release includes support for raw colour, demosaicking, capture limits by frame, SER file format output (v2), different reticle designs, improvements in the settings window management and improvements in handling of 16-bit and binned mono.

There's more documentation here, and a user manual here.

Do let me know if you find problems.

Plans for the next release include TIFF file output (or possibly PNG), access to more of the camera controls via the user interface, support for binned colour where cameras support it, support for at least some QHY5II cameras, various usability fixes, support for SER v3, more demosaicking methods and a massive re-write of the camera API.

Finally, if you have one of the ASI cameras and you have no use for the CCTV lens at at least some were supplied with, please see my "wanted" in the classifieds.

Have fun,

James

[AlexB67]

Nice James. Nice you got there, One day I get to finish my calculator too, but it just keeps growing with ideas, features, changing/adding stuff, and mostly the weather and verification makes it a long process. investing in an SQL-M would not hurt either and be very useful for me. I'll get it done day before I have a grey beard

By all means if you want me to check anything like how easily it complies on Fedora 18 I'l give it a go over the weekend if you like. When it comes to actually using it I'll be of no use though.

Cheers

[JamesF]

Certainly would be useful to know if it compiles ok on Fedora.  Testing this sort of stuff isn't something virtual machines are particularly good for and there are only so many different versions of an OS you can install on a machine before it all gets a bit mad

James

[Eddy_J1]

Awesome stuff James, I'll see if I'm able to get this running on my RPi, you'll soon know whether I come back to this thread sobbing for help or joyful that I got it working

[JamesF]

Do let me know how you get on. If you have problems I'm sure we can get them sorted.

I have been thinking that for saving images from an all-sky camera TIFF files might make most sense, so I shall start looking into that.

James

[michael.h.f.wilkinson]

Very nice. I will have a look at that once I get an annoying little problem in my Linux install sorted

[SnakeyJ]

I'm dusting the Pi off ready - just going to play with the Xbox live cam (with hacks)

typed on my mobile with Tapatalk

[JamesF]

The Xbox camera should work, but the UVC driver needs a bit of hackery to get there.  One issue is that the default timeout in the driver for responses to USB commands is too short and needs to be made configurable so it can be changed to suit the camera.  I can't recall the other off the top of my head.  I think it might be something to do with the driver and camera not agreeing on whether some value should be signed or unsigned.

Considering that it's supposed to be a standard, it's amazing how many not-exactly-compliant UVC cameras there are

James

[SnakeyJ]

Thanks James - I've literally dusted off the Pi, with a paint brush, as it had been sat on top of a wardrobe gathering!     Just imaging the SD card with a more up to date Raspian - a very nice thing to play with during my convalescence, though not sure I can handle an additional week off work.

[cgarry]

Hi James,

I just had a quick play with this latest version and my ASI120MM, looking good so far.  A few comments:

(1) You don't need to select ROI to change to a ROI.

(2) For a 640 x 480 ROI I was only able to get a FPS of less than 50 FPS - am I missing a USB traffic slider somewhere to increase this?

(3) AVI file claimed a FPS value of 100 even though only 2620 frames were recorded in 60 seconds.

(3) SER timestamps seem to be very broken (see attached file).  Though this could always be a bug in my analysing code!

Cheers,

Chris

oaCapture-20140207-103914_info.zip

[JamesF]

Hi James,

I just had a quick play with this latest version and my ASI120MM, looking good so far.  A few comments:

(1) You don't need to select ROI to change to a ROI.

(2) For a 640 x 480 ROI I was only able to get a FPS of less than 50 FPS - am I missing a USB traffic slider somewhere to increase this?

(3) AVI file claimed a FPS value of 100 even though only 2620 frames were recorded in 60 seconds.

(3) SER timestamps seem to be very broken (see attached file).  Though this could always be a bug in my analysing code!

Thanks for the details, Chris.

1) I do need to tidy that up.  Radio buttons aren't the best choice there I think.  It should probably be "max size" or "ROI" or something that isn't either.

2) The USB traffic control will be implemented in the next release, once I've redone the camera API.  I've been sticking my head in the sand a bit over that because I didn't want to write even more code that would need changing later.

3) I think I must have lost the actual FPS figure somewhere.  Do you know if the theoretical frame rate was 100fps in this instance?

4) That's very odd.  They definitely looked good when I checked them.  I'll have another look.

James

[cgarry]

3) I think I must have lost the actual FPS figure somewhere.  Do you know if the theoretical frame rate was 100fps in this instance?

I just repeated the 640x480 test for a 60s capture.

On the GUI:

FPS (max): 500

FPS (actual): 54

Captured: 3007

AVI File Details:

FPS: 100

Frames: 3007

Actual FPS: 3007/60 = 50.12

Cheers,

Chris

[JamesF]

Strange.  Looks like it might be using 100 as a default for some reason.  I definitely set the timebase, so perhaps something else is required to get it to believe it.

James

[cgarry]

Looking at the AVI file in detail shows:

In the AVI Header:

micro_sec_per_frame: 10000

In the Stream header:

Scale: 1

Rate: 100

Which does all point to 100 FPS.

Cheers,

Chris

RIFF: AVI  - Size: 0x2ffa4bca - Position: 0x0 - Next: 0x2ffa4bd2
  |- LIST: hdrl - Size: 0x11e8 - Position: 0xc - Next: 0x11fc
  |    |- Chunk: avih - Size: 0x38 - Position: 0x18 - Next: 0x58
  |    |    MAIN AVI HEADER
  |    |    micro_sec_per_frame: 10000
  |    |    max_bytes_per_sec: 16000
  |    |    padding_granularity: 0
  |    |    flags: 0x910
  |    |     - HASINDEX
  |    |     - ISINTERLEAVED
  |    |     - TRUSTCKTYPE
  |    |    total_frames: 2620
  |    |    initial_frames: 0
  |    |    streams: 1
  |    |    suggested_buffer_size: 1048576
  |    |    width: 640
  |    |    height: 480
  |    |- LIST: strl - Size: 0x1090 - Position: 0x58 - Next: 0x10f0
  |    |    |- Chunk: strh - Size: 0x38 - Position: 0x64 - Next: 0xa4
  |    |    |    STREAM HEADER
  |    |    |    type: 'vids'
  |    |    |    handler: 'Y800'
  |    |    |    flags: 0x0
  |    |    |    priority: 0
  |    |    |    language: 0
  |    |    |    initial_frames: 0
  |    |    |    scale: 1
  |    |    |    rate: 100
  |    |    |    start: 0
  |    |    |    length: 2620
  |    |    |    suggested_buffer_size: 1048576
  |    |    |    quality: 4294967295
  |    |    |    sample_size: 0
  |    |    |    frame.left: 0
  |    |    |    frame.top: 0
  |    |    |    frame.right: 640
  |    |    |    frame.bottom: 480
  |    |    |- Chunk: strf - Size: 0x28 - Position: 0xa4 - Next: 0xd4
  |    |    |    BITMAPINFO HEADER
  |    |    |    size: 40
  |    |    |    width: 640
  |    |    |    height: 480
  |    |    |    planes: 1
  |    |    |    bit_count: 8
  |    |    |    compression: 'Y800'
  |    |    |    size_image: 307200
  |    |    |    x_pels_per_meter: 0
  |    |    |    y_pels_per_meter: 0
  |    |    |    clr_used: 0
  |    |    |    clr_important: 0
 

[JamesF]

Regarding the SER timestamps Chris, this is the output from the version of PIPP you sent me on a file I've just captured:

Looks ok to me.  Could you email me the ser file you tested?

James

[cgarry]

PM Sent.

Chris

[JamesF]

Looks like it's a problem with SER timestamps on 32-bit machines.  Could be my first fix for the next version

James

[Eddy_J1]

Hi James, I'm currently on my RPi, when i try install binaries it says arm6l isn't supported and when i open the arm executable it does nothing, any guidance would be greatly appreciated

Cheers

[JamesF]

Hmmm.  I wonder if your install reports a slightly different processor architecture or something.  Can you tell me what the output of

$ uname -p

and

$ uname -m

is?

James

[JamesF]

Might also be useful to know which distribution you're running.  I did only test on Raspbian.  If you're running something different then it looks like I might have to download that and test against it too.

James

[Ags]

Good luck! Sounds like you've got lots of users already :-)

My only criticism is it needs a name - "linux capture application" is a bit dry?

[Eddy_J1]

Hi James sorry for the delay I've been busy with other things over the weekend, both output armv6l

I'm running on the latest version of Raspbian

[JamesF]

How odd.  On mine, which is theoretically completely up-to-date, the former outputs "unknown".  I shall try downloading and installing from scratch again.

What I think might work is to run

$ ln -s ./armv6 ./`uname -p`

in the same directory as the install script and try running it again.  I think that should fix it.  If not, let me know what happens.

James

[JamesF]

Just downloaded Pidora and checked that.  Both uname commands produce "armv6l" so it must be something about the distribution I have.  Odd that it worked on SnakeyJ's Pi though.

Now I'm downloading the latest Raspbian Wheezy to try that.  In theory it should be what I already have.  In practice, who knows?

James

[Eddy_J1]

Yeah that makes some sort of shortcut it seems called uname -p which I imagine is wrong?

Any ideas which version you have on yours which worked? Maybe I can find it in their archive.