oaCapture 0.9.0 is released...

[JamesF]

It's taken a very long time, but driven by the latest El Capitan update that fixes a number of USB issues I've made a new release of oaCapture.

This release hopefully gets back to the state where a single OSX binary works on everything from Snow Leopard onwards.  It also uses the latest ASI SDK so all their current cameras should be supported.  There are a number of bugfixes too, and hopefully better handling of TIFF and FITS files.

I'm not happy with the support for the USB2 ASI120 cameras on USB3 OSX machines.  I can't get them to work reliably on my 2013 MBP although on my pre-unibody MacMini I have no problems.  That needs more investigation.

Testing has reached a point now where it is becoming obscenely time-consuming.  It's fair to admit that part of the reason there has been such an interval between this release and the last is that I just couldn't face all the testing involved, especially after finding a problem that meant I had to start all over again.  To help with this release I've dropped a number of the binary builds.  I can do them on request, but otherwise I won't bother.  For the future I think I'm going to create a v1.0.0 release very soon and after that I'll start making "release candidates" for interested people to play with before each major release.

Anyhow, downloads are at http://www.openastroproject.org/downloads/

James

[NickK]

12 hours ago, JamesF said:

Testing has reached a point now where it is becoming obscenely time-consuming.

Yup, have the t-shirt with that.. regression testing imaging systems is hard unless you can use a permanent setup with a test pattern and testing systems that for real image analysis.

I don't do the ATIK drivers now - ATIK have their own bod / drivers but the amount of testing and retesting gets ridiculous for one person + family + life + job.. 

[Davey-T]

Thanks for all your hard work James, my son decided to upgrade my MBP to El Capitan it now takes longer than a Windows PC  to do anything  and the only time I tried oaCapture it had problems, will download and give it another try.

Dave

Happy to test any release candidates for Skyris 274, PGBFly

[JamesF]

El Capitan has been something a nightmare in terms of the USB subsystem.  I've seen quite a few problems reported where hardware (not just cameras, but PIC programmers and all sorts) stopped working because the USB layer was broken.  Apple also appear to have "invented" a number of virtual USB devices for reasons that I don't understand.  Unfortunately they don't respond quite the same way as real USB devices and when you're enumerating them trying to work out what's what it causes some hideous delays unless you know to ignore them.  Hopefully you'll have more success this time.  Things seem to have improved a great deal in 10.11.4 though I'm not entirely convinced they're perfect yet.

I've not noticed general performance issues with El Capitan on my MBP, but on the Mac Mini both it and Yosemite are painfully slow even after doing all the "how to speed up OSX" type stuff I've found on the net.  I assume it must be lack of memory or too slow a CPU (I think it's only a Core 2 Duo in that box), but there's not much I can do about the latter.

James

[Peter Rosen]

Hi James,

I have been using AstroIIDC with my TIS-cameras for some years now but when I heard of oaCapture, I decided to buy an ASI 120-MC. Everything has worked out quite well but the debayering is not working for me.

I noticed that there is also a folder called oaCapture-0.9.0 sources (bzip2) that can be downloaded but I have found no explanation so I have no idea where I should put it and what it is supposed to do. Hopefully it will help with the debayering.

Thank you for incredible amount of work you have put into developing oaCapture.

/*Peter R

[NickK]

One thing I noted for USB is that it does go fast IF a single call is called. The issue of using libusb is that it copies data.. then copies it again.. In the drivers I wrote the user buffer is used directly (with the fun of being packet based rather than byte based) and the result is a far faster implementation.

 

[michael.h.f.wilkinson]

Might well try this on a Linux install (OpenSUSE), just to get rid of Windows. I gather AS!2 and the like will run under WINE, I will test AutoStitch

[JamesF]

5 hours ago, Peter Rosen said:

Hi James,

I have been using AstroIIDC with my TIS-cameras for some years now but when I heard of oaCapture, I decided to buy an ASI 120-MC. Everything has worked out quite well but the debayering is not working for me.

I noticed that there is also a folder called oaCapture-0.9.0 sources (bzip2) that can be downloaded but I have found no explanation so I have no idea where I should put it and what it is supposed to do. Hopefully it will help with the debayering.

Thank you for incredible amount of work you have put into developing oaCapture.

/*Peter R

In what way is the debayering not working?  There are a couple of places to configure it.  In the "Options" dropdown you can turn it on and off, and in the "Settings" dropdown option  you can change the mask pattern and change the algorithm used.  By default the ASI cameras provide a debayered image as far as I recall, so you'll need to check the "raw mode" checkbox too.  I think that should be it, but if you have any more details I'll look into it.

James

[JamesF]

4 hours ago, NickK said:

One thing I noted for USB is that it does go fast IF a single call is called. The issue of using libusb is that it copies data.. then copies it again.. In the drivers I wrote the user buffer is used directly (with the fun of being packet based rather than byte based) and the result is a far faster implementation.

 

I've not reached a point yet where the speed of the user-space USB implementation is an issue, to be honest.  The bottlenecks at the moment tend to be the USB bus bandwidth and disk bandwidth.  And of course the advantage of using libusb is more portable code.

If libusb does become a bottleneck and the developers aren't interested then it's something I might revisit, but until then I can spend the time better on other things, for example supporting additional hardware.

James

[JamesF]

2 hours ago, michael.h.f.wilkinson said:

Might well try this on a Linux install (OpenSUSE), just to get rid of Windows. I gather AS!2 and the like will run under WINE, I will test AutoStitch

Have to admit that I'd completely forgotten about OpenSUSE.  I've never tested oacapture on it.  I'll download it and have a go.

Amazingly I've just discovered that SUSE is now owned by Micro Focus, who used to pay my mortgage in return for me turning up in their office more than twenty years ago.

James

[Peter Rosen]

1 hour ago, JamesF said:

In what way is the debayering not working?  There are a couple of places to configure it.  In the "Options" dropdown you can turn it on and off, and in the "Settings" dropdown option  you can change the mask pattern and change the algorithm used.  By default the ASI cameras provide a debayered image as far as I recall, so you'll need to check the "raw mode" checkbox too.  I think that should be it, but if you have any more details I'll look into it.

James

Hi,

I had the debayering on and in auto mode. But I get the same result either it is on or off.

If I turn on Raw mode I get the same result except that the "mov" format that is the one I use for planetary capture is disabled!

This is a Tiff-capture I just did and and it shows that Red and Blue are half the resolution of Green, with very visible jaggies.

This is the reason I guess the debayering is not working as it should for me.

Please disregard the second image. I have not been able to remove it from the post.

 

What is the the folder oaCapture-0.9.0 sources (bzip2)  and where is it suposed to be placed once downloaded.

Thanks

/*Peter R 

 

 

[JamesF]

mov format doesn't have a way to store raw colour frames as far as I'm aware, which is why it is disabled.  I'm not sure it's a particularly good choice for recording anyhow, but it may be useful on OSX and I was asked to add it specifically so some people could record video for display on an Apple machine.

If "auto" doesn't work then I'd suggest trying each of the other options in turn (click "save" after changing them) to see which works correctly.  It's entirely possible the correct one is not identified properly in auto mode (some cameras lie

Usually I only enable the conversion for the screen display and leave the saved files written as raw colour because I use AutoStakkert!2 for stacking and it does a pretty good job of handling the raw colour frames.

James

[Peter Rosen]

I have tested all the demosaic-settings and also turned it off but I still get the exact same results every time as shown in the example above.

The reason I use the mov-format is that being on a Mac I don't have many options when it comes to stacking. I still use AstroIIDC for stacking and it only takes mov-files.

 

But can you also please tell me what is the folder oaCapture-0.9.0 sources (bzip2)  and where is it suposed to be placed once downloaded?

Thanks

/*Peter R 

[JamesF]

1 minute ago, Peter Rosen said:

But can you also please tell me what is the folder oaCapture-0.9.0 sources (bzip2)  and where is it suposed to be placed once downloaded?

Thanks

/*Peter R 

Oh, sorry, I forgot to answer that bit first time around.  It's the source code for the application.  You don't need it at all unless you want to recompile the application for some reason.

James

[JamesF]

You've definitely enabled the demosaic option in the "options" menu as well?

James

[Peter Rosen]

1 hour ago, JamesF said:

You've definitely enabled the demosaic option in the "options" menu as well?

James

Yes, I have checked the demosaic option in the "options" menu as well.

But I get the exact same result whatever setting I use and also if I turn the demosaic off.

That's the problem I am trying to solve.

This is the first result I achieved with the camera but the resolution is lower than it should be and with a high color noise level due to the debayering not working as expected

/*Peter R

 

/*Peter R

[NickK]

All RGB bayer matrix images are imprecise approximations. 

Looks like the upscale for the R&B components is doing a straight integer block upscale. Using something like Lanczos interpolation would help with the impact of CPU/GPU performance.

Looking at the de-mosaic code that's what's happening (although averaging). One option is to de-mosaic then simply render the images using a sampler that copes with the upscale for each colour. Slower but the resulting image could also be drizzled if stacking.. 

 

[NickK]

10 hours ago, JamesF said:

I've not reached a point yet where the speed of the user-space USB implementation is an issue, to be honest.  The bottlenecks at the moment tend to be the USB bus bandwidth and disk bandwidth.  And of course the advantage of using libusb is more portable code.

If libusb does become a bottleneck and the developers aren't interested then it's something I might revisit, but until then I can spend the time better on other things, for example supporting additional hardware.

James

Yup, so each camera having it's own USB or even switching to SSD for the initial capture before offloading to secondary larger storage.

 

[JamesF]

Hmmm.  I'm at a loss for the moment to explain why the debayering wouldn't work unless for some reason the application has insufficient information to be able to debayer the image.  What camera are you using?

(As an aside I'd also suggest avoiding the "nearest neighbour" algorithm for debayering if you need RGB output.  It's fast, but fairly nasty.  Bilinear is better.  After that the algorithms reach a level of complexity that begins to impact performance, but you may find they're worth a try.)

James

[JamesF]

I see Ubuntu 16.04 has been released too.  I guess I should check it runs on that...

James

[Peter Rosen]

3 hours ago, JamesF said:

Hmmm.  I'm at a loss for the moment to explain why the debayering wouldn't work unless for some reason the application has insufficient information to be able to debayer the image.  What camera are you using?

(As an aside I'd also suggest avoiding the "nearest neighbour" algorithm for debayering if you need RGB output.  It's fast, but fairly nasty.  Bilinear is better.  After that the algorithms reach a level of complexity that begins to impact performance, but you may find they're worth a try.)

James

I am using an ASI120 MC camera. It's the model with USB3 although my Macs only have USB2.

Turning the debayer on or off or testing the different algorithms in oaCapture has no incidence at the result, I always get exactly the same result with a visible bayer-pattern

This is a 2x scaled up crop of a stack from 1027 frames.

If somebody has the same camera and uses a Mac, would you please check if you can get different debayering results?

The fastest way to test is to output a single tif-file of a subject containing thin parallell lines as for example window blinds that will reveal jaggies.

Thanks /*Peter R

 

[JamesF]

How odd.  Something is definitely very strange there.  Unfortunately I don't have the 120MC-S, but I'll have a think about how I can try to reproduce the problem.

James

[Peter Rosen]

Thanks James, that would be appreciated.

I'm waiting for your feed-back

 

/*Peter R

[JamesF]

I've downloaded the latest OpenSUSE release (I have limited bandwidth, so that takes a while -- usually I have to leave it running overnight) and had a play with it.  Once the libraries for cfitsio, dc1394 and Qt4 are installed the Fedora binaries do run though there's a warning about libtiff not containing any version information.  I don't know if that's significant or not.

It may be possible to compile the source against Qt5 which appears to be the default in OpenSUSE, but whilst that pretty much works there is one odd niggle that I've only been able to fix by fudging the Makefiles thus far: some Qt5 distributions (on Linux, at least) apparently need applications to be compiled with "-fPIC" whereas others don't.  It ought to be possible to work that out and have autoconf add the flag automagically, but I haven't worked out how to do so yet.

James

[JamesF]

On 25/04/2016 at 08:37, Peter Rosen said:

Thanks James, that would be appreciated.

I'm waiting for your feed-back

 

/*Peter R

Ok, can you just clarify, so I'm trying to reproduce the problem in the right way...

You have raw mode enabled, saving data as a SER file and demosaic is enabled in the "options" menu as I understand it.  What options are enabled in the demosaic section of the "settings" menu?

Thanks,

James