oacapture 1.0.0

[kens]

On 8/31/2016 at 08:37, JamesF said:

Touplite probably won't recognise the camera.  As far as I can see the toupcam libraries don't recognise the USB VID/PID used for this camera.

You won't get a /dev/videoN device at all though.  The drivers are userspace rather than in the kernel and completely sidestep the whole V4L2 subsystem.

The only think I can think of at the moment is that perhaps you have a permissions issue.  If you have installed the udev files and either restarted udev or rebooted, and added yourself to the "users" group and logged in again then I'd have thought it should work.  Perhaps the shared library is not being found.  If you can confirm that you've done the first two then we can work on checking that.

James

I've got the ToupLite software working. I got hold of a copy from the reseller of the ProStar but it crashes on my machine. Same with the version from FLO. The download from Touptek runs but doesn't detect the camera. So I replaced libtoupnam.so and libtoupcam.so with the ProStar versions and it all works. oacapture still doesn't detect the camera. I tried replacing your libtoupcam.so with the ProStar one and I also edited 70-touptek-camera.rules to include product B134 but still no luck.

[Odiug]

Hi James,

I just wanted to report that oaCapture 1.0.0 also works with a ZWO ASI224MC. However I experience the same issue when using longer exposure times. It seems that image acquisition is blocking the UI. So for me longer exposures do work, but you have to be real patient, because UI changes will only happen after the next exposure window. I wonder if acquisition could be moved to a background task. Or was the ASI SDK not supposed to block? Even with "preview" off, the same behavior persists. Is acquisition still taking place, but images are just not displayed?

As a workaround, would it be possible to have a button to start and stop image acquisition or even have a single shot button? So, one could fiddle around with settings and do a control snapshot until the result is satisfactory.

Anyway thanks for your work on oaCapture.

 

Cheers

Guido

[Gina]

I have this problem with SharpCap under windoze but SharpCap will capture long exposures of >2s in fact it's quite happy with several minutes.  oaCapture fails to work for me with exposures >2s using ZWO cameras and James is working on it.  Meanwhile I'm struggling with my Win7 laptop using SharpCap for setting up and APT for imaging runs.  Worst problem is that CdC keeps getting disconnected from EQMOD ASCOM.  So I'm waiting for useable astro capture software that works with Linux so that I can go over to INDI etc. 

Sorry to keep on about this James and good luck with sorting out the long exposure problem

[GuLinux]

@JamesF, @GinaI had the same problem with my Planetary Imager. 

I investigated a bit together with Sam from ZWO, and the solution seems to be to alter /lib/udev/rules.d/asi.rules
to this new version: https://raw.githubusercontent.com/GuLinux/PlanetaryImager/master/src/drivers/zwo_asi/ASI_SDK_v0.3.0908/lib/asi.rules

I also updated to the new SDK version in PlanetaryImager, and seems very fast with USB3 cameras, so you might want to update it in oaCapture too

[JamesF]

Hmmm.  That usbfs memory thing in the udev rules isn't the greatest idea.  What happens if it is already set higher for some reason?  Checking the current value and raising it if it is less than 200 would be better.

Looks as though there are a few bugfixes in the ASI SDK released recently, which might explain why I haven't find the problem in my own code thus far   I'll update things, retest and see what happens.

James

[GuLinux]

 

4 hours ago, JamesF said:

Hmmm.  That usbfs memory thing in the udev rules isn't the greatest idea.  What happens if it is already set higher for some reason?  Checking the current value and raising it if it is less than 200 would be better.

Well, I do agree, it is in the wrong place..

But I didn't think of a viable alternative yet, I was thinking to create a sysctl file, but this is not a sysctl control..

Adding it as a system init script isn't viable either, too distribution dependant.

Maybe it could be the imaging application changing the value at startup, but then you'd add to enter your root/sudo password each time you run it...

[DorsetBlue]

Hi James,

Just been on the Altair google group and found that there was a suggestion that Altair might be helping you with getting the GPCAM V2 to work with OACapture? Have you made any progress, as I would love to use my GPCAM under Linux?

Regards

Ian

[SteveBz]

On 26/08/2016 at 06:33, JamesF said:

I am very happy to consider suggestions for new functionality, so please feel free to make suggestions if you have them.

Hi James,

Just got this working under Ubuntu 16.04 in a VM with a very cheap generic camera.  Of all the imaging programs I tried this was the only one that worked!  wxAstroCapture sees my cameras but does nothing, Qastrocam-g2 is now not even opening, CCDciel - no, OpenSkyImager - no, Entangle - no.  GStreamer of course works, and that is what I was using until I found your program.

The only thing I'd like to do is turn off automatic noise reduction and brightness correction - I think stars may be noise!  And I don't know whether v4l2 has such a switch (I can't see it) or whether it's a soldering-iron job .  I hope not.

I would also think you should set the default setting on install for the position of the control panel to "right".  When I first opened oaCapture there was no screen real estate set aside for the image at all and I considered forgetting it.  Luckily I persevered.

Regards

Steve

[Plutonium5793]

On 6/30/2016 at 16:41, JamesF said:

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

In my hands oacapture v1.0  is not working in Fedora24 or Ubuntu 16.04.  While it runs it crashes when I begin to record.  When run from terminal (either system) it gives a C++ error. 

I dropped back to Fedora 23 and installed oacapture and that works fine.

John

 

[Owmuchonomy]

On 18 September 2016 at 11:55, Gina said:

I have this problem with SharpCap under windoze but SharpCap will capture long exposures of >2s in fact it's quite happy with several minutes.  oaCapture fails to work for me with exposures >2s using ZWO cameras and James is working on it.  Meanwhile I'm struggling with my Win7 laptop using SharpCap for setting up and APT for imaging runs.  Worst problem is that CdC keeps getting disconnected from EQMOD ASCOM.  So I'm waiting for useable astro capture software that works with Linux so that I can go over to INDI etc. 

Sorry to keep on about this James and good luck with sorting out the long exposure problem

Hi James, similar to Gina I am having a long exposure problem. I have just started using my ZWO ASI 174 MM for spectroscopy and oa Capture freezes solid for exposures over 2s. It doesn't always happen though as after rebooting a few times I got 7s TIFF spectrum exposures in one run of 30 seconds. It was a one off though and I couldn't repeat it. BTW I really like the new live frame capture info at the bottom of the pane. Many thanks for your efforts.

[Plutonium5793]

I think somewhere above there should be a message from me saying that I cannot get oacapture to record under Fedora 24 or Ubuntu 16.04 (ver 1.0). It crashes when you try to record.  There is a C++ error message when I run from terminal.   I have version 0.9 working under fedora 23, and it works ok.  However I took a bunch of gigabytes of data last night that most programs won't read.  I was using 'raw avi' setting.  Registax won't read them, Avistack 2.0 won't read them,  Virtualdub won't read them.  Astroavibrowser does read some of them, and Gxine reads them.   Any idea how I can get in to process them.   Thanks for any help

John

[Odiug]

Hi James, Hi All,

I have had the issue that I am running Arch Linux and desperately wanted to run oaCapture under it. Building it natively failed, because of all the dependency issues and the Qt4/Qt5 differences. I came across AppImage  when I discovered SER-Player. After some tweaking, I successfully wrapped the Ubuntu binary as an AppImage that also runs under Arch Linux.

I liked the AppImage idea, but wanted to have a more general build. Docker was used to create a clean build system and preferrably an older one, so the generated AppImage works on as many distributions as possible. It took me some time, but finally it worked, at least on Arch Linux. My approach can be found under oacapture-appimage-build. Beware, this is just the Dockerfile, some build scripts and a README, not the actual AppImage. I was not sure yet where to make it available. Maybe on Github as well.

James, you might have a look at Ubuntu14/build_1_oacapture.sh, if I got everything right in the actual build. I needed to run "autoreconf -vfi" in ext/libdc1394, because the autoconf version did not match there.

Cheers,

Guido

[Odiug]

OK, I added the created AppImage as well: oaCapture-1.0.0.AppImage

Just download, make it executable ("chmod +x oaCapture-1.0.0.AppImage") and execute it. I am curious on which Linux distributions it works (or not).

Cheers

Guido

[Odiug]

I just got aware that this AppImage is 64bit only. I discovered it when I wanted to test it on an older system I have.

One limiting factor is using Docker in the build process, which is for x86-64 and ARM only. AppImage for 32bit should be possible, as the roots of AppImage are already 12 years old.

Cheers, Guido

[MCinAZ]

4 hours ago, Odiug said:

I just got aware that this AppImage is 64bit only. I discovered it when I wanted to test it on an older system I have.

One limiting factor is using Docker in the build process, which is for x86-64 and ARM only. AppImage for 32bit should be possible, as the roots of AppImage are already 12 years old.

Cheers, Guido

I just downloaded your executable and it launched without error on a Mint 17.3 (x86-64) system. My camera and PTR are at the telescope, so I won't be able to make a full functionality test until the next time I'm in the observatory. Given that the program runs at all, I would expect that your build should be fully functional.

[JamesF]

I'm not sure where my life has disappeared to this year.  I can't believe it's nearly November already.  However, I've reorganised things to give myself a bit more time to spend on oacapture in the future.  I'll now be trawling through this thread to makes sure I've not missed anything.  I'll reply here and add items to my "todo" list for the next release.

James

[JamesF]

On 26/08/2016 at 11:02, Vox45 said:

Since you are asking for suggestions and I am currently moving everything to Linux, I'll jump on your offer and hope you will consider it

There is a feature I really like in Firecapture.It is the ability to add the session details and embed them in the final image result as such: (there is a short youtube demo here)
 

I'm a little confused by this one, I have to admit

Are the details being added to some final processed image, or are they added to every frame of the output data stream?

James

[MCinAZ]

4 minutes ago, JamesF said:

Are the details being added to some final processed image, or are they added to every frame of the output data stream?

 

Or the FITS headers, where they belong? (Only slightly tongue in cheek.)

[JamesF]

On 26/08/2016 at 11:14, Gina said:

I would like to see the gain and exposure displayed when in auto mode.  I've found it very interesting to know these when running SharpCap.

A minor point - the dropdown box showing the image resolution isn't quite long enough to show the resolution when in the form HHHHxVVVV ie. 4 digits in each direction.

Displaying the current values of controls when it auto mode is certainly possible if the camera supports it.  Some have no way to read the actual values set in the camera right now whilst others do and I think there are even some that even tell you when the automatic systems have changed the setting of a control.

I'll work out how to enlarge the size of the resolution drop-down.

James

[JamesF]

On 02/09/2016 at 11:33, kens said:

I've got the ToupLite software working. I got hold of a copy from the reseller of the ProStar but it crashes on my machine. Same with the version from FLO. The download from Touptek runs but doesn't detect the camera. So I replaced libtoupnam.so and libtoupcam.so with the ProStar versions and it all works. oacapture still doesn't detect the camera. I tried replacing your libtoupcam.so with the ProStar one and I also edited 70-touptek-camera.rules to include product B134 but still no luck.

Are the ProStar versions of these libraries available for download anywhere?  I don't know that I can make them work, but if I can compare them with the others perhaps I can work out what's going on.

James

[JamesF]

On 27/09/2016 at 13:36, DorsetBlue said:

Hi James,

Just been on the Altair google group and found that there was a suggestion that Altair might be helping you with getting the GPCAM V2 to work with OACapture? Have you made any progress, as I would love to use my GPCAM under Linux?

Regards

Ian

Some of  the Altair cameras may work.  It depends which one you have.  The easiest way to identify them is by the USB Vendor and Product IDs.  Do you know how to find those?

James

[JamesF]

On 07/10/2016 at 10:46, SteveBz said:

The only thing I'd like to do is turn off automatic noise reduction and brightness correction - I think stars may be noise!  And I don't know whether v4l2 has such a switch (I can't see it) or whether it's a soldering-iron job .  I hope not.

I would also think you should set the default setting on install for the position of the control panel to "right".  When I first opened oaCapture there was no screen real estate set aside for the image at all and I considered forgetting it.  Luckily I persevered.

I don't know if V4L2 has controls that allow those to be turned off, but I'll check and see what I can do to make them work.  It may be something that I have to add code for and then leave you to test, assuming the controls are indeed actually present.

Moving the controls to the right by default may well be a good idea.  We seem to be moving towards having wider screens without necessarily increasing the height anywhere near as much, so perhaps utilising that extra screen width makes sense.

James

[JamesF]

On 15/10/2016 at 01:38, Plutonium5793 said:

In my hands oacapture v1.0  is not working in Fedora24 or Ubuntu 16.04.  While it runs it crashes when I begin to record.  When run from terminal (either system) it gives a C++ error. 

I dropped back to Fedora 23 and installed oacapture and that works fine.

John

 

I've just upgraded my desktop to the latest Mint (which is based on 16.04) so I'll try to work out what's going on with this.  Looks like it could be the same problem in both cases.

James

[JamesF]

On 15/10/2016 at 14:51, Plutonium5793 said:

I think somewhere above there should be a message from me saying that I cannot get oacapture to record under Fedora 24 or Ubuntu 16.04 (ver 1.0). It crashes when you try to record.  There is a C++ error message when I run from terminal.   I have version 0.9 working under fedora 23, and it works ok.  However I took a bunch of gigabytes of data last night that most programs won't read.  I was using 'raw avi' setting.  Registax won't read them, Avistack 2.0 won't read them,  Virtualdub won't read them.  Astroavibrowser does read some of them, and Gxine reads them.   Any idea how I can get in to process them.   Thanks for any help

John

I wonder if this is because there are some differences between "raw" AVI files created on different systems.  You may find that if you process the files with PIPP it can produce you something that works.  There's also an option in the settings panes that allows you to write "windows style" AVI files that might help in the future.

James

[JamesF]

On 22/10/2016 at 18:50, Odiug said:

OK, I added the created AppImage as well: oaCapture-1.0.0.AppImage

Just download, make it executable ("chmod +x oaCapture-1.0.0.AppImage") and execute it. I am curious on which Linux distributions it works (or not).

Cheers

Guido

One of the things I have on my list of stuff to look at for the next release is how AppImage deals with stuff that is (in the case of oacapture) handled by udev rules.  Did you get anywhere with that?

James