oaCapture 0.9.0 is released...

[GreatAttractor]

44 minutes ago, JamesF said:

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.

That's right, too bad Y16 isn't more widely supported. On the other hand, with the SER Player around, using the SER format became quite convenient.

48 minutes ago, JamesF said:

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

This almost got me too in Stackistry But I first recorded some SERs with FireCapture to verify, the flag is indeed reversed w.r.t. the online documentation I've found.

[rpineau]

Yes this was on 0.9.0

I use Lynkeos for the stacking and it uses ffmepg to load the file, so whatever ffmpeg supports will work in my case, but probably not for everybody.

I'll gladly try your test version.

Also using ROI I was able to get a very high FPS with very little dropped frame. So that is a very positive things for planetary imaging.

I hope to get the full 128 FPS at full frame size for solar/lunar imaging as this was the main reason for buying this camera (big pixel = bigger FOV on my 102ED = full frame Sun/Moon).

I might get an ASI 290MC  for pure planetary latter.

Thanks

Rodolphe

[JamesF]

26 minutes ago, GreatAttractor said:

That's right, too bad Y16 isn't more widely supported. On the other hand, with the SER Player around, using the SER format became quite convenient.

This almost got me too in Stackistry But I first recorded some SERs with FireCapture to verify, the flag is indeed reversed w.r.t. the online documentation I've found.

I'm having a bit of a time with 16-bit stuff at the moment...

I've pretty much got the first cut of support for the Touptek cameras done, but the documentation is a little on the light side and there are a number of areas where the behaviour in 16-bit mode is not clear.  Sadly I've not had a response from their support email address yet, so I might just have to stick to 8-bit support for the first release.

James

[MCinAZ]

  I just received a Point Grey Chameleon color USB-2.0 camera which I'm hoping to use for some time lapse sequences and perhaps even some casual planetary imaging. No problem getting monochrome images from it, but I've not found the correct settings needed to either preview or store color images. I've confirmed that the camera will produce color image data using FlyCapture2. Has anyone used oaCapture with one of the original Chameleon color cameras? Are there any particular settings I should configure to make this camera work as expected? I've got a fair amount of experience with oaCapture, but none with a color camera to this point.

  -- Mike --

[JamesF]

I'm afraid the only Point Grey cameras I have are mono so you may well be using code I can't test.  However, I do have a colour Imaging Source FireWire camera that works and despite the different interface it should actually use much of the same code.

Are the demosaic options set (enabled for the preview image in Settings->Demosaic, and enabled in the Options dropdown)?  It probably won't matter if you have the wrong CFA pattern initially as getting any colour on-screen would be a good start

James

[MCinAZ]

5 hours ago, JamesF said:

Are the demosaic options set (enabled for the preview image in Settings->Demosaic, and enabled in the Options dropdown)?  It probably won't matter if you have the wrong CFA pattern initially as getting any colour on-screen would be a good start

  I think I've tried at least a good subset of the combinations. In Settings -> Demosaic, both Demosaic Preview Image and Demosaic Output Data are selected, along with Options -> Demosaic. I've tried all Bayer format and Debayer method options, though not every every combination of the two. In the Settings -> Camera dialog, adjusting Brightness seems to have a minor effect, Contrast none that I can tell. The other four controls, Blue Balance, Red Balance, Gain and Auto Exposure all affect image brightness, but still only monochrome.

  PNG renderings generated from a TIFF image shown below. one full frame and the other a 32x32 region from an evenly illuminated portion of the wall. It appears that only the one of the four (presumably red or blue) pixels are contributing the bulk of luminance data. This may be a color balance effect. In any case, color information is getting lost somewhere.

  This is not an issue of any great importance, but since I had the camera I thought it worth a try. If it's not simply a settings issue I wouldn't worry about it.

  -- Mike --

p.s. Apologies for the missing 'u's.

[JamesF]

That absolutely looks like a raw colour image before demosaic processing to RGB.

I'll have a look at the code to see if I can spot anything obvious that might be wrong.

James