oaCapture for OSX

[Davey-T]

Right sorted that, now get message in Terminal "libpng warning:iCCP known incorrect sRGB profile

Had similar message in Firecapture.

Dave

Seems to be working today, opens and closes, the ROI controls are still greyed out so can't change settings.

[JamesF]

USB3 James.

Just tried running it from terminal and get message "No such file or directory" so just playing around with that ATM

Dave

Not a USB2 vs. USB3 issue then, at least.

James

[JamesF]

Right sorted that, now get message in Terminal "libpng warning:iCCP known incorrect sRGB profile

Had similar message in Firecapture.

Yes.  I'm not sure where that comes from, but I don't think there's anything I can do about it immediately.

James

[Davey-T]

Any way to make the ROI settings come to life ?

Dave

[JamesF]

Any way to make the ROI settings come to life ?

Dave

I've just been looking at that.  The UVC protocol does support ROI controls, but the camera doesn't actually appear to offer them.  Unless of course TIS have done something slightly different with the firmware.  I'll see what I can find out.

James

[JamesF]

Aha.  Looks like it may be done as a camera-specific extension.  This is going to be fun.  I'll have to do some work to unpick the details.

James

[Davey-T]

If it's any consolation James the ROI doesn't work in the supplied iCap software either, it works in Firecapture so one up to Torsten 

Dave

[JamesF]

If it's any consolation James the ROI doesn't work in the supplied iCap software either, it works in Firecapture so one up to Torsten 

Dave

It's possible Torsten just crops the image after it's come off the camera which is functionality that I do want to add at some point.  It won't save on bandwidth to the camera, but it can at least reduce the size of the saved file.

James

[Davey-T]

Looks like you're right James as the fps stays at 20 in Firecapture using the Skyris regardless of the ROI size, whereas using the PG B'Fly the frame rate goes up as the ROI goes down.

Dave

In the 274 spec's it says maximum frame rate 20fps

[JamesF]

Aha.  Tonight I have managed to get the hang on my own machine.  Just the once, but even that is a good start.

Were I to have a wild stab in the dark I'd guess that it's perhaps down to threads not being terminated in the correct order somehow leaving one thread waiting on a mutex that never clears.  That could be a bundle of fun to find

James

[Davey-T]

Stop you getting bored and a pause button would be really handy, I see there's room for one if you slide the auto thingy and stop button to the right a bit.

Guess as the camera only runs at 20fps they don't see any point in supporting an ROI so Torstens idea of just cropping the image is a good one.

Dave

[JamesF]

Code for the pause button (partially) already exists just as you suggest.  It's just been commented out in pretty much all releases so far

The reason it's commented out is because I couldn't decide how it should work.  Or perhaps more specifically, I couldn't see how it could be made to work and still provide sane values for some of the data in the .txt file such as the frame rate, recording mid-point and so on.  Perhaps for the time being that data might just have to be invalidated if the recording is paused.

It is in my list of things to look at though.  Somewhat to my horror I've just counted and discovered that list currently extends to about eighty items

James

[JamesF]

I think I've found something that may be causing trouble on OSX, basically relating to claiming the USB interfaces at he right time.  It's definitely a problem and it wouldn't surprise me if it was messing up OSX as OSX seems to be rather intolerant of this sort of thing, but at the moment I'm having quite a struggle to fix it.  Everything I've tried so far has just made things worse.  At the moment the code is in a state where it needs value B so it can calculate value A, but the only way to get value B is to know what value A is

James

[JamesF]

Ok, so it's not that.  I've fixed the problem and nothing appears to have changed on OSX.  Still looking...

James

[JamesF]

Well, the number of times I've thought I've had this fixed this evening...

What I have discovered is that on my MBP running Mavericks I'm getting some USB errors from the OS driver layers saying the camera device is not responding (ioKit error 0xe00002ed).  This is actually the reason for the relatively slow start-up and when the frame rate is changed.  I don't get this on Linux at all, so I'm wondering if there's something a bit marginal about the combination of the Skyris cameras and the MBP.  I've ordered some shorter cables to see if that makes any difference and I'll give it a whirl on the mac mini to see what happens there.

It seems I'm not alone though.  Google finds reports of other people seeing the same sort of error, sometimes only on a single one of a group of identical Macs.

James

[NickK]

Well, the number of times I've thought I've had this fixed this evening...

What I have discovered is that on my MBP running Mavericks I'm getting some USB errors from the OS driver layers saying the camera device is not responding (ioKit error 0xe00002ed).  This is actually the reason for the relatively slow start-up and when the frame rate is changed.  I don't get this on Linux at all, so I'm wondering if there's something a bit marginal about the combination of the Skyris cameras and the MBP.  I've ordered some shorter cables to see if that makes any difference and I'll give it a whirl on the mac mini to see what happens there.

It seems I'm not alone though.  Google finds reports of other people seeing the same sort of error, sometimes only on a single one of a group of identical Macs.

James

Ahh 0xe...2ed .. that sounds familiar. I'm assuming this is occurring from ReadPipe - where I've seen this before - or the interrupt equivalent. 

It wouldn't surprise me if it was USB power related. Have you tried plugging in a powered hub too?

[JamesF]

Ahh 0xe...2ed .. that sounds familiar. I'm assuming this is occurring from ReadPipe - where I've seen this before - or the interrupt equivalent. 

It wouldn't surprise me if it was USB power related. Have you tried plugging in a powered hub too?

Ah, not since I squashed the last bug, no.  I'll give that a whirl again.

I had also been wondering if OSX's own camera management stuff wasn't getting in the way somewhere.  The Skyris cameras do claim to be true UVC in the USB layer which OSX decides it's happy to play with, but then they don't offer a frame format it knows anything about.  The TIS cameras (which seem to work fine) are UVC, but claim to be something different so OSX ignores them completely.  Of course the TIS cameras are also USB2 whereas the Skyris models are USB3 so there are other variables.

James

[JamesF]

Actually, the other thing that might count towards this being a software problem is that the error shows up quite predictably when certain events occur.

Perhaps I should give Yosemite a try.  Is it possible to non-destructively repartition my hard disk (currently fully used by OSX), or am I going to need to reinstall both Mavericks and Yosemite to go dual-boot?

James

[NickK]

Actually, the other thing that might count towards this being a software problem is that the error shows up quite predictably when certain events occur.

Perhaps I should give Yosemite a try.  Is it possible to non-destructively repartition my hard disk (currently fully used by OSX), or am I going to need to reinstall both Mavericks and Yosemite to go dual-boot?

James

Then the fun is ensuring all the third party libraries work with 10.10.. 

Also if you want OpenCL 1.0 support on older GPUs.. that disappears in Xcode 6 ... (10.10)

It's a good point about Apple's frameworks stealing the devices.. that's particularly true for HID devices. Principally to prevent people from making keyboard key loggers by installing kernel HID drivers without the user knowing on installs..

[JamesF]

Hmmm.  Well...  Thus far I have been unable to reproduce the same problems on my late 2009 Mac mini running Snow Leopard.  Of course that is only USB2 which rather defeats the point of these cameras.  Although they're rather slow I'll give the same machine a try with Mavericks and Yozzymight to see what happens.

James

[Davey-T]

Started and stopped 274 several times today with no problems, still a bit hesitant to start at times.

Need some Sun for a proper trial, probably refuse to work then 

Dave

[JamesF]

To be honest even if I can get as far as understanding the remaining issues with this camera on OSX I'm prepared to make a new release just to get bugfixes out as I can document the limitations at that point.

The next release even has a feature specifically requested for solar imaging (I think perhaps actually more for outreach demos displaying images from a camera) allowing mono images to have false colour applied in the preview.  It can also save (some) capture formats in quicktime format files although they're enormous and I'm not sure how useful it is now everything seems to get converted to H.264 unless you're using a codec that Apple approve of.

James

[JamesF]

Curiouser and curioser, said Alice...

I've built a binary on 10.6, rolled it into a dmg and tested on 10.6 through 10.10 on the Mac mini.

On all versions of OSX the camera connection is immediate, unlike on the MBP where the camera is reported as not responding and then recovers a few seconds later.

On 10.6 through 10.9 I've not been able to get the application to hang on exit.  In 10.10 it hangs every time (though not when I've used non-Skyris cameras).

So, it looks like the startup problem may be somehow USB3-related, though we do have to bear in mind that this works perfectly well on a Linux box with USB3 ports.  The hang on exit could be anything and I'm certainly not discounting some sort of mess with the threading in my own code.

Next steps are, I think, to build a binary on Yosemite and see how it behaves on the same release and to plug a USB2 hub into my MBP and see if the startup delay goes away.

James

[NickK]

This was on the apple usb list:

I looked at the issue with a fresh pair of eyes this morning and

indeed, you are partially correct, its not a power issue. ... but
neither is it a protocol problem.

I'm seeing a very reproducible case with ReadPipeAsyncTo() where,
issued multiple concurrent calls to this creates issues under OSX
10.10, but not 10.9

struct buf_s {
unsigned char *ptr;
int len; /* total size of allocation in ptr */
int readlen; /* bytes returned from readpipeasyncto() */
/// other buffer stats
};

I submit the buf->ptr and buf->len to ReadPipeAsyncTo() and pass the
buffer struct as the context. A fairly standard thing to do. My USB
interface is in the run loop so I get callbacks and timeouts as
expected.... Except that I've previously 'submitted' 8-16 of these
readPipeAsyncTO() calls concurrently (much like any driver would do
for usb bulk transfers, queue up a few).

I'm finding that after a small number of completions, the callbacks
only timeout (wire protocol to the hardware is perfect). Adjusting the
number of concurrent ReadPipeAsyncTo() calls varies the failure rate
dramatically.

I've always had an assumption that calls to ReadPipeAsyncTO() were
queued by iokit or the kernel, as a thin wrapper around a more
standard usb_bulk_transfer() type implementation. I'm starting to
doubt that now, or doubt thats how its intended to work in 10.10.

Also, interestingly, assuming I queue a large number of these (all
calls return success) and immediately abort the pipe, only a small
handful of those are returned to the completion handler, the rest
'disappear'. The also feels new and unexpected.

Something's going on inside ReadPipeAsyncTo() that's new to 10.10. Grrr.

Thanks again for your earlier comments.

[msh1]

hi james will my point grey blackly gige work with this software I'm using mountain lion

mark