Jump to content

Banner.jpg.b89429c566825f6ab32bcafbada449c9.jpg

oaCapture 0.9.0 is released...


JamesF

Recommended Posts

I could get to hate USB3 :)

I don't have any Point Grey USB3 cameras so I can't do an immediate test, but I'll see if I can come up with any ideas.  The only one that springs to mind immediately would be to see if it works if you connect it to the computer via a USB2 hub.  Clearly that's not a desirable solution, but it might be a useful datapoint.

James

Link to comment
Share on other sites

  • Replies 81
  • Created
  • Last Reply
44 minutes ago, JamesF said:

I could get to hate USB3 :)

I don't have any Point Grey USB3 cameras so I can't do an immediate test, but I'll see if I can come up with any ideas.  The only one that springs to mind immediately would be to see if it works if you connect it to the computer via a USB2 hub.  Clearly that's not a desirable solution, but it might be a useful datapoint.

James

Thanks James, confirmed it does not work on USB 2 either (the old 2010 iMac running Yosemite).

Carlos

 

 

Link to comment
Share on other sites

When the camera is connected, could you scan through the "About this Mac" section to see if you can find the vendor and product IDs for the camera?  You probably want something like "OS X System Information → Hardware → USB → USB Device Tree"

If there's any indication in the information you have about the camera regarding the firmware revision it is using then that might also be helpful to know, but it's no big deal if you can't find that out.

I suspect this might be down to a bug in libdc1394 which implements the IIDC over USB stuff and there may be a fix, so if you can confirm the IDs then I can look at building a version for you to test.  I'll try to do one new binary for both you and Peter Rosen to try.

James

Link to comment
Share on other sites

Well, that was unexpected.  What I've read appears to suggest that the firmware in USB3 cameras ought to be 2.x.x.x, but perhaps that isn't what it means.

I guess the best thing we can do is try the alleged fix and see what happens...

James

Link to comment
Share on other sites

Thanks James. It's all going a bit over my head....but that is the firmware written on the camera box under the camera model number. 

I will try using a friends PC and the fly capture app to see if it truly is that firmware. 

Carlos

Link to comment
Share on other sites

So yes, here are the camera stats using Flycapture:

IIDC VERSION: 1.32

FIRMWARE VERSION: 1.10.3.0

DRIVER: PGRUsbCam.sys- 2.7.3.79

This camera uses the Sony IMX265 CMOS

 

Hope this helps.

thanks again!

Carlos

Link to comment
Share on other sites

The good news is that it looks like both Peter Rosen and CarlosD's problems are now fixed by my test version and so the fixes should go into the next release.  If anyone else is having similar problems in the meantime (especially with Point Grey USB cameras), let me know and we'll see if it fixes those too.

James

Link to comment
Share on other sites

  • 4 weeks later...

Hi James,

I just tried to give oaCapture 0.9.0 a run in Ubuntu 16.04 but failed.  The problem occurs when trying to install libcfitsio3, I get an 'E: Unable to locate package libcfitsio3' error.  After that oaCapture fails to start because of the missing shared library.  What you need is a nice new snap package to remove all this dependency rubbish!

Cheers,
Chris 

Link to comment
Share on other sites

2 hours ago, cgarry said:

Hi James,

I just tried to give oaCapture 0.9.0 a run in Ubuntu 16.04 but failed.  The problem occurs when trying to install libcfitsio3, I get an 'E: Unable to locate package libcfitsio3' error.  After that oaCapture fails to start because of the missing shared library.  What you need is a nice new snap package to remove all this dependency rubbish!

Cheers,
Chris 

Yup, this is regular issue - you can put a symbolic link in but if it's the architecture (often 32bit required on a 64bit system) then you can grab the sources from NASA and build..

 

Link to comment
Share on other sites

Hi James - I'm planning to try oaCapture again and my immediate thought when I saw you had a new release out was "oh goody" :)  I've bought a ZWO ASI1185MC for planetary imaging and planning to try oaCapture in Linux (Mint or Ubuntu) as I was impressed when I used it before for my all sky camera with QHY5-II-C. 

I haven't got as far as trying the ASI1185MC for planetary yet but I did get it working with the supplied fisheye lens and was very impressed with the ASC images I got.  That was using AMCap in Win 7 and it'll be nice to see how well it performs with oaCapture for planetary.  Also, I'm now thinking of using it for ASC when I'm not using it for planetary imaging.

Link to comment
Share on other sites

On 04/06/2016 at 09:10, cgarry said:

Hi James,

I just tried to give oaCapture 0.9.0 a run in Ubuntu 16.04 but failed.  The problem occurs when trying to install libcfitsio3, I get an 'E: Unable to locate package libcfitsio3' error.  After that oaCapture fails to start because of the missing shared library.  What you need is a nice new snap package to remove all this dependency rubbish!

Cheers,
Chris 

libcfitsio seems to have so many different shared object versions :(  A symlink from whatever you have to the version it's looking for may well work as they usually seem to be binary-compatible.

In this instance, building a per-distribution release (as would normally happen) would fix this particular problem, but the snap package does hopefully finally solve the issue of oacapture needing later versions of common libraries (eg. libusb, libdc1394, ffmpeg) than may be installed as part of the distribution (and that other packages may have specific dependencies on those too).  The irony of course is that by the time the snap package has become commonplace distributions will probably have caught up with the versions I need :D

James

Link to comment
Share on other sites

On 04/06/2016 at 12:09, Gina said:

Hi James - I'm planning to try oaCapture again and my immediate thought when I saw you had a new release out was "oh goody" :)  I've bought a ZWO ASI1185MC for planetary imaging and planning to try oaCapture in Linux (Mint or Ubuntu) as I was impressed when I used it before for my all sky camera with QHY5-II-C. 

I haven't got as far as trying the ASI1185MC for planetary yet but I did get it working with the supplied fisheye lens and was very impressed with the ASC images I got.  That was using AMCap in Win 7 and it'll be nice to see how well it performs with oaCapture for planetary.  Also, I'm now thinking of using it for ASC when I'm not using it for planetary imaging.

Do let me know how you get on.  I've not tested it with all the new ASI cameras so there may be one or two niggles, but they should be relatively easy to sort out .

James

Link to comment
Share on other sites

1 hour ago, mistuk said:

Hi James - not having much luck with a QHY5II and 10.11.5 - keeps crashing. Any thoughts?

The QHY5-II (as opposed to the QHY5L-II) has been a bit of a nightmare to support.  I'll have another look at it.

James

Link to comment
Share on other sites

3 minutes ago, JamesF said:

Do let me know how you get on.  I've not tested it with all the new ASI cameras so there may be one or two niggles, but they should be relatively easy to sort out .

James

Will do :)

Link to comment
Share on other sites

On 05/06/2016 at 15:55, JamesF said:

libcfitsio seems to have so many different shared object versions :(  A symlink from whatever you have to the version it's looking for may well work as they usually seem to be binary-compatible.

In this instance, building a per-distribution release (as would normally happen) would fix this particular problem, but the snap package does hopefully finally solve the issue of oacapture needing later versions of common libraries (eg. libusb, libdc1394, ffmpeg) than may be installed as part of the distribution (and that other packages may have specific dependencies on those too).  The irony of course is that by the time the snap package has become commonplace distributions will probably have caught up with the versions I need :D

James

Ubuntu 16.04 seems a little strange here.  The repositories have the libcfitsio2 shared library but libcfitsio3-dev, I would have thought they would have matched but I am far from an expert on the way Linux works.  Anyway, after I created a symbolic link from libcfitsio3 to the installed libcfitsio2, oaCapture started perfectly.

I did some brief testing and captured some nice SER files with my ASI174MM camera.  However, I found that the window was always too large to fit on the screen.  The bottom of the window was always off the bottom of the screen.  Is it possible to reduce the window size?

Cheers,
Chris

Link to comment
Share on other sites

2 hours ago, cgarry said:

I did some brief testing and captured some nice SER files with my ASI174MM camera.  However, I found that the window was always too large to fit on the screen.  The bottom of the window was always off the bottom of the screen.  Is it possible to reduce the window size?

Cheers,
Chris

Do you have the controls at the top or the side at the moment?  If the smallest the window will go is still too big and they're at the top then moving the controls to the right (in the settings/general menu) might help.

What size screen are you using?

James

Link to comment
Share on other sites

What a wee screen you have :)  After allowing space for the toolbars at the top and bottom you're probably only left with about 700 pixels I guess.  I'm surprised that moving the controls to the right doesn't help though.

I think that the reason I originally set a minimum window size is probably no longer relevant, so I'll remove it in the next release.  It's easy enough to do for the current release if you want to recompile the application yourself.

James

Link to comment
Share on other sites

Hello James.

I just got my new ASI 174MC-Cool and it's not recognized by oaCapture (OS X El Capitan) :

Unrecognised camera 'ZWO ASI174MC-Cool'
Unrecognised camera 'ZWO ASI174MC-Cool'
libpng warning: iCCP: known incorrect sRGB profile
unknown camera type -1. Using limited resolutions

The camera works with Astrolive USB and TheSkyX Pro, so I know it works :)

But none of the 2 application above are meant for planetary imaging.

Regards, Rodolphe

Link to comment
Share on other sites

Ok so more data point (with positive outcome :) ).

On the same machine directly on one of the Mac Mini USB3 port, it works but drops a lot of frame (MAX FSP is 125, Actual is 85).

On the same machine, on one of the Thunderbolt docking station (Belkin) USB3 port, it doesn't work (MAX FSP is 125, Actual is 0). -> in this mode is does work in AstroLive USB and TheSkyX Pro (and PHD2).

On the same machine, on one of the  USB3 port of my monitor integrated USB3 HUB, it works but drops a lot of frame (MAX FSP is 125, Actual is 85).

On My MacBook Pro Retina, it works (MAX FSP is 100, Actual is 100, few dropped frame from time to time).

So it's not all negative :) (I suspect the Belkin Thunderbolt docking station port are the issue as they are not real full speed USB3 bit only 2.5Gbps max).

A few more things common to both machines : 

If I click on the 16 bit checkbox, FPS drop to the floor ! (MAX FSP is 125, Actual is 22)
The camera has 2 modes, 12 and 10 bits, how do I select between the 2 ?
Binning 2x2 works but doesn't give me any speed increase.

So overall, good result with a few things to look into.

I'm mostly concerned about the FPS as the camera is supposed to do 128FPS in full res 12 bit and 164 in 10 bit mode.

In both case the CPU cores are nowhere close to be saturated, they went to  about  50% on the mac Mini (Core i7 quad core at 2.6GHz) and 35% on the MacBook Pro  (Core i7 quad core at 2.8GHz) (using MenuMeters).

Which mean the CPU is not the limiting factor for the FPS.

Regards, Rodolphe

 

Link to comment
Share on other sites

Is this with 0.9.0?  If so it's probably worth trying my test version, so let me know and I'll give you a link to the download.

Saving data with more than 8 bits per colour plane is definitely problematic in 0.9.0.  Firstly because there aren't too many supported codecs for AVI, so whilst oacapture may be able to save it, other applications may not be able to read it.  The obvious solution would be to use SER, but sadly there's a nice little feature I wasn't aware of in SER files whereby the flag for little-endian data must be set to 0 if the data is little-endian and 1 otherwise.  I wasn't aware of this, so I did it the intuitive way :)  It will be fixed in the next release.

James

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.