oacapture 1.0.0

[JamesF]

I decided it's time.  We have a 1.0.0 release   Time is tight as I'm away from home for two weeks from tomorrow afternoon, but I really wanted to get this out so people could start playing with it rather than wait another fortnight.

Currently thanks to the time constraints binaries are only available for OSX I'm afraid.  I'm working on Linux versions and adding them as I get them built.  Source is also available to download, but I should give fair warning that the build system has become something of a monster in this release

Changes include:

• Support for Touptek cameras.  This can't be considered complete, but I think it's most of the way there.  Feedback would be appreciated.  Kudos is due to FLO for loaning me the cameras so I could do this work.
• Build with the May 2016 release of the ZWO ASI interface library.
• Add support for some of the newer Point Grey IIDC-over-USB cameras
• Add support for occultation-timing hardware (more of this later)
• Add support for sub-millisecond exposures
• Add support for newer ASI camera models
• Enable the ZWO ASI2 interface (though this should really only be considered experimental)
• Allow the UtVideo codec to be disabled
• Load the Point Grey GigE library and the Toupcam library at runtime, meaning a single executable can support them or not rather than requiring separate builds
• Fix "directory not writable" errors for TIFF and FITS files
• Fix a 16-bit SER byte-order issue (SER documentation doesn't match reality.  Reality is probably in error in this case
• Allow MOV and TIFF files to be saved from a raw colour camera if the output stream is demosaicked

There are a few other low-level bugfixes too.

Regarding the occultation timing hardware, this is in development and I hope I (or the designer) can say more about it later, but the idea is to be able to add a timestamp from a GPS-synchronised source to FITS files containing an image taken at that time.  For now, just ignore the "Timer" menus.

Downloads at http://www.openastroproject.org/downloads/ as ever.  I'll try to remember to post here as I add Linux binaries.

James

[Vox45]

Good news as I am going down the path of a full linux setup, oacapture was next on my list. Can't wait to get the v1.00 on Linux

[Gina]

Same here.

[Davey-T]

Thanks for all your hard work James, will have a go with the PGBFly GigE if the Sun ever appears.

Dave

[Gasman]

Any chance of a quick 'How to' to install oacapture James please?. Its been a while since using Linux and I've just installed Netrunner 16 on a laptop (an Ubuntu flavoured distro). If memory serves is it the ./configure,make etc dance to install these files?.

Cheers

Steve

[rpineau]

Unfortunately this version no longer works for me (OS X + ZWO ASI174MC).

Your previous 1.0.0 beta you sent me was working better.

If I chose ZWOASI I get 95 fps but no actual preview no matter what exposure time I chose (so even with 1000 ms it says 95 FPS).

If I chose ZWOASI2 I get  different amount of FPS with is always above the Max FPS (should not be possible) and garbled data in the preview.

Rodolphe

 

[Gasman]

Hi James again

Read the install instructions and installed the prerequisites but still getting QT libs missing after running ./configure.

It seems some qt5 files are missing somewhere! (moc-qt5 and vic-qt5)

 

cheers

Steve

[JamesF]

My internet access appears to have stabilised for the moment and I was going to run through responses to all these postings this evening, but I've just read about Per and I'm afraid my heart isn't in it any more.

I'll get back to you all soon,

James

[Gina]

I can well understand that James - a real body blow!

[JamesF]

On 03/07/2016 at 21:00, Gasman said:

Any chance of a quick 'How to' to install oacapture James please?. Its been a while since using Linux and I've just installed Netrunner 16 on a laptop (an Ubuntu flavoured distro). If memory serves is it the ./configure,make etc dance to install these files?.

Cheers

Steve

Generally I think you should be able to get it to build as you suggest, but it looks like there's one small fly in the ointment in that the build system decides the libdc1394 Makefiles are out of date and attempts to rebuild them, throwing an error if you don't have the correct version of automake installed.  I can fix this when I get home, but a temporary workaround once you have the sources extracted is to do the following from the top-level directory:

$ touch ext/libdc1394/Makefile.in
$ sleep 5
$ touch ext/libdc1394/Makefile

and then run configure.

James

[JamesF]

On 04/07/2016 at 01:55, rpineau said:

Unfortunately this version no longer works for me (OS X + ZWO ASI174MC).

Your previous 1.0.0 beta you sent me was working better.

If I chose ZWOASI I get 95 fps but no actual preview no matter what exposure time I chose (so even with 1000 ms it says 95 FPS).

If I chose ZWOASI2 I get  different amount of FPS with is always above the Max FPS (should not be possible) and garbled data in the preview.

Rodolphe

 

Ok, I'll look into this as soon as I can, though it may have to wait until I get back home next week.

James

[JamesF]

On 04/07/2016 at 18:58, Gasman said:

Hi James again

Read the install instructions and installed the prerequisites but still getting QT libs missing after running ./configure.

It seems some qt5 files are missing somewhere! (moc-qt5 and vic-qt5)

It may be much easier if you can install the qt4 libraries and build against them.  There appears to be much weirdness when it comes to linking against qt5 libraries and I'm struggling to get to grips with it all at the moment. (Really cleverly, it appears that on some systems the qt5 libraries are built with the PIC flag set and on others they aren't.  But libraries compiled one way won't link with code compiled the other and there's no easy way to tell which was used on any given system

James

[rpineau]

8 hours ago, JamesF said:

Ok, I'll look into this as soon as I can, though it may have to wait until I get back home next week.

James

No problem. There is no emergency.

Thanks again

Rodolphe

 

[MCinAZ]

On 06/30/2016 at 15:41, JamesF said:

Changes include:

• Add support for occultation-timing hardware (more of this later)

Regarding the occultation timing hardware, this is in development and I hope I (or the designer) can say more about it later, but the idea is to be able to add a timestamp from a GPS-synchronised source to FITS files containing an image taken at that time.  For now, just ignore the "Timer" menus.

  Although I read James's message shortly after it was posted, it's taken me a while to find time to chime in. I am the designer of the timing hardware mentioned above, and James and I have been working on system architecture and integration of my timing module into oaCapture for almost two years now. The timing module, which I've named PTR (Precision Timing Reference) is a small, MCU-based circuit which incorporates a GPS receiver to provide a millisecond-accurate clock along with a camera interface capable of generating exposure trigger signals or recording strobe pulses generated by a camera. It was designed specifically to interface with Point Grey cameras, however it should be capable of working with any camera which supports either trigger input or strobe output. The PTR module also includes a regulated 8 VDC supply to power the camera.

There are two prototype systems at present, one in my Arizona observatory and the second in Wiveliscombe. Both prototype systems are using Blackfly GigE cameras, however the PTR hardware and oaCapture should work equally well with USB or Firewire cameras. Timing data generated by the PTR are transferred to oaCapture across a USB link and embedded directly as DATE-OBS records in the FITS header for each image.

  The primary goal for the system is reduction of the amount of equipment necessary to record occultations. The most common complement in amateur hands is composed of a high-sensitivity NTSCo or PAL surveillance camera, an obsolete Canon DVR with analog video input, a video time inserter (which may require a separate GPS receiver) and enough power supplies and cables interconnecting all the pieces to significantly improve the odds of failure. Because the tape mechanism on my Canon camera had failed years ago, I also needed a computer and FireWire adapter to record video data directly to disk. Most folks not using a computer carry a separate monitor into the field to be able to see the target star field well enough to ensure that the telescope is pointed correctly.

  The system we've developed is composed of the camera, the PTR module, one power supply and a computer.  Although at present I'm using a Dell mobile computer in the observatory, it may be feasible to substitute a smaller system (on the order of a Raspberry Pi, albeit with a faster I/O subsystem), perhaps using a tablet or phone for control. Even with the Dell, there are far fewer connections and components to haul to the field for a remote observation. Because the camera is fully controlled through oaCapture, integration time can be adjusted to record much fainter stars at lower time resolution. This has extended the capabilities of my telescope from about 11th magnitude to beyond 14th. As cameras with CMOS sensors , particularly those built around the new Sony backside-illuminated devices become available, it is reasonable to expect substantial improvement in limiting magnitude for a given time resolution.

  In addition to occultation work, I have been using oaCapture with my Point Grey camera to collect speckle data for measurement of bright, relatively wide (>0.8 arc-sec) double stars. The embedded time stamps can be read directly by my data reduction software for drift calibration of camera angle and image scale.

  There is still some development work required to make our system fully operational, though it's getting very close. The existing PTR prototypes use an 8-bit S08 MCU, however I've begun work on an ARM-based successor. That module will provide some added capabilities related to geographic coordinate determination (vital for occultation recording at remote sites) and address a couple of limitations identified in the first-generation units. It will also a bit less expensive to produce and, if I'm sufficiently clever, field-upgradable.

  I'll post a more detailed follow-on message at some point in the future, but I thought it would be good to provide a brief introduction in case anyone has been wondering what those new Timer references in the menus are all about.

  -- Mike --

[MCinAZ]

  In the oaCapture-0.9.0 thread, I posted a message about a month ago indicating that I was having some difficulties viewing color images with a Point Grey Chameleon USB camera. I saw similar issues using Coriander-2.0.2. Damien Douxchamps suggested booting Ubuntu 14.04 from a flash drive to see if the problems persisted, and that was the case with the Dell computer in my office. It occurred to me yesterday to try the same experiment using a different computer. Doing so, I learned that Coriander works pretty much as expected on the other computer. There is clearly some hardware or hardware configuration interaction which prevents Coriander from working correctly with the Chameleon camera on the Dell.

  I tried the same experiment using oaCapture-1.0.0 under Ubuntu 14.04 booted from flash. Results were the same as reported previously, i.e., image data are displayed however no combination of de-Bayer options that I've tried yielded color. I was hopeful that the problems with both Coriander and oaCapture could be assigned to something peculiar to my Dell computer, but alas, such is not evidently the case.

  This is not an issue which warrants attention, however I thought it worth documenting what I've learned in case it may help someone else down the road.

  -- Mike --

[Gina]

Irregularity in the way Dell implement some features has been reported in the past and indeed I have found things that won't work with my Dell machine.

[MCinAZ]

15 hours ago, Gina said:

Irregularity in the way Dell implement some features has been reported in the past and indeed I have found things that won't work with my Dell machine.

  For the most part I haven't encountered too many difficulties with the four Dell machines in the household. I've not been able to get the wireless interface on the oldest of them to work with Linux Mint, but otherwise this is the only peculiarity I've found. FlyCapture, Point Grey's demo GUI, works with the Chameleon on my Dell, so I presume there is nothing in the USB subsystem or elsewhere which is fundamentally incompatible with the camera. I suspect there is an underlying problem related to implementation of the Linux USB or IEEE 1394 drivers at a level common to oaCapture and Coriander but not FlyCapture. James has noted that he doesn't have a Chameleon to test against, so in the case of oaCapture, there may be a relatively trivial discrepancy that he could track down if he were able to perform some hands-on debug. It's probably not worth his time, however, given his other priorities.

  -- Mike --

[Gasman]

On 11/07/2016 at 20:11, JamesF said:

Generally I think you should be able to get it to build as you suggest, but it looks like there's one small fly in the ointment in that the build system decides the libdc1394 Makefiles are out of date and attempts to rebuild them, throwing an error if you don't have the correct version of automake installed.  I can fix this when I get home, but a temporary workaround once you have the sources extracted is to do the following from the top-level directory:

$ touch ext/libdc1394/Makefile.in
$ sleep 5
$ touch ext/libdc1394/Makefile

and then run configure.

James

Hi James

Trying oacapture on another laptop now running latest 64bit Ubuntu. Did what you suggested above but still getting the Qt lib errors

checking for moc-qt5... no
checking for moc-qt4... no
checking for moc... moc
checking for uic-qt5... no
checking for uic-qt4... no
checking for uic... uic
checking for rcc... rcc
checking for QT... no
configure: error: Qt libraries are required.

Maybe easier waiting until the packages are sorted ?.

cheers

Steve

[Gina]

Hi James - hope you had a great holiday - welcome back

I would like to try oaCapture with a ZWO ASI185MC in a Raspberry Pi 3 for my all sky camera.  What are the chances?

[D4N]

I installed v0.5 on my PI and it worked really well with my asi120mm.  The frame rate was a lot lower than on my laptop but that is to be expected.  I've not tried it with the newer versions as my ASI is set up for guiding and I've not wanted to move it off the OAG for fear of messing the spacing up (again).

[JamesF]

I now have an RPi3, so I'll have a go at building it.  I see no reason why it shouldn't work.  I'll have a try at building it now.

James

[Gina]

Thank you very much James

[JamesF]

Well, with very little fiddling about the sources do build.  I've not tested it yet, but I'll try that tomorrow.

James

[Gina]

Great - thanks

[D4N]

Hi James,

 

Is there a reason why tiff format is disabled when I turn on 16 bit mode?

Using oacapture 1.0.0 with asi178mc on OSX 10.10.5.

 

Cheers,

 

/Dan