oaCapture 0.9.0 is released...

[JamesF]

Turns out that a new version of the ZWO SDK was release a week after I started testing.  Fortunately the changes don't affect Linux or OSX so I'll just include it in the next release.

James

[Peter Rosen]

On 26 april 2016 at 17:35, JamesF said:

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

I use only the .mov format and occasionaly .tif. For these 2 formats, I think the raw mode is automatically dissabled (as well as 16 bits mode) when using the ASI120MC-S camera (will double check this tonight).

Beeing on a mac I have no other option as I use AstroIIDC for stacking and it won't take avi or ser.

I have tested all the demosaic settings and none is having any effect. The result I get is identical to turning demosaic off.

I also have 2 firewire cameras from The Imaging Source, a DMK41AF02 and  a DBK41AF02. They are recognized by oaCapture but for some reason the .mov and .tif options get dissabled so I'm not able to use them.

Thanks,

/*Peter R

[JamesF]

Ok, that makes things much clearer.  Thank you.

The .mov format appears quite limited in terms of astro use.  I don't want to use codecs that involve lossy compression, but that leaves very few options.  In particular I've not found a format I can use that supports anything more than eight bits per colour, nor any format that supports raw colour images.  That's why those options are disabled when using .mov files.

If raw mode is disabled for the ASI120MC then the camera delivers a full RGB image, so no demosaic options will have any effect.  It will be written unmodified to the .mov file.  For the moment therefore I'm at a loss to explain the effects you're seeing.  TIFF isn't a great format for high frame rate imaging because of the overheads of creating, opening and closing so many files.  Are there any other formats that AstroIIDC can work with?  Perhaps not, as there aren't that many options to start with.  What format does it use when it is recording?

I'll have a look at the issues with FireWire cameras.  I can see why .mov would be disabled with the DMK, because I can't find a mono codec to use either.  I could just turn the mono frame into RGB and write that, but it effectively triples the size of the capture data which isn't really desirable.  I'm not sure why TIFF would be disabled at the moment; I'll need to check.  With the DBK I'd expect that to work as long as demosaic is enabled in the options and configured for the output data in the settings menu so you get an RGB frame to write to the .mov file rather than raw colour.  I don't think I have a colour FireWire camera though so it may be something I've never been able to test myself.

James

[JamesF]

Actually it turns out that I do have a colour FireWire camera, so I'll have a look at what happens when I use that.

James

[JamesF]

Hmm.  It's also just occurred to me that some of the TIS cameras don't correctly report the image formats that they produce.  For example, some of the cameras that deliver raw colour actually claim they're providing a greyscale image and my code has to recognise that situation and correct for it.  If that's the case for the DBK41 (and I have no idea if it is or not) then it may be that I'm not recognising that the camera is providing the wrong information.  I think this is probably unlikely, but it's another possible problem I can check out.

James

[JamesF]

Something else that has just occurred to me...

Given that the .mov file contains full RGB frames, is it possible that AstroIIDC expects the data to be raw colour and is applying some demosaic function to it?  Seems unlikely, but worth checking.

James

[JamesF]

Now I've had a chance to check the code it appears that .mov files should be enabled for full RGB frames and for 8-bit mono, so there may be an issue there.  I'll check up on that.

James

[Peter Rosen]

Hi James,

I have done some testing with my 2 firewire cameras from The Imaging Source.

* The monocamera DMK41AF02 appears to work fine with oaCapture and I can record .mov files. I cannot use any ROI though, only full resolution.

* When using the  DBK41AF02 color camera, .mov is disabled and only ser or avi can be accessed and no Raw mode. The preview is in black and white with a mosaic pattern. I attach a screencapture.

 

/*Peter R

[Peter Rosen]

On 29 april 2016 at 23:18, JamesF said:

Something else that has just occurred to me...

Given that the .mov file contains full RGB frames, is it possible that AstroIIDC expects the data to be raw colour and is applying some demosaic function to it?  Seems unlikely, but worth checking.

James

[Peter Rosen]

On 29 april 2016 at 12:24, JamesF said:

Something else that has just occurred to me...

Given that the .mov file contains full RGB frames, is it possible that AstroIIDC expects the data to be raw colour and is applying some demosaic function to it?  Seems unlikely, but worth checking.

James

 

Astro IIDC needed the installation of a " ASC_Bayer 3.01.00 codec " to playback the mov-files and be able to use them for stacking. 

I am not sure but think it is a codec written by Milton Aupperle, the creator of Astro IIDC.

In his user manual he wrote:

"The "Use high quality color bayer decode for grabs and movies" check box is only enabled for color cameras. The "Astro IIDC" application and the "ASC_BAYER.component" decompressor provide two algorithms for converting the RAW Bayer CFA data collected from the color CCD cameras into RGB images, a fast medium quality method and a much slower (approximately 100 times) but higher quality (more detail and fidelity) method. "

 

But anyway, this is a side track as I can continue use my astrocameras from TIS with Astro IIDC for a while.

The most important for the moment would be to find a way to get the demosaic function to work on my Mac with oaCapture and my new ASI120MC-S camera.

 

/*Peter 

[JamesF]

10 minutes ago, Peter Rosen said:

 

Astro IIDC needed the installation of a " ASC_Bayer 3.01.00 codec " to playback the mov-files and be able to use them for stacking.

That's interesting, as it suggests that it expects the mov files to be raw colour rather than RGB.  If they were RGB it should be possible to play them directly.  I'll have a think about this over lunch

James

[Peter Rosen]

This morning I have also retested oaCapture with ASI 120MC-S on my Mac to really confirm that the debayering is not active.

I also made an avi capture ("Use Windows-compatible format for AVI files" NOT checked) but it seems I am missing a codec so I cannot even play it with VLC.

But the preview shows that the demosaic is not having any effect although enabled in the settings.

 

/*Peter R

[JamesF]

Ok, let's start with a few experiments...  I am running oacapture 0.9.0 with an ASI120MC (not the "S" model as I don't have the USB3 model) connected to my desktop.  The camera is in its default state (I plugged it in just before starting oacapture).

In oacapture I have connected the camera and disabled "demosaic" in the options menu.  In the "settings->demosaic" configuration window I have "demosaic preview image" checked, "demosaic output data" not checked, "Bayer format" is "auto" and "demosaic method" is "bilinear".  In the "camera" control box I have "raw mode" unchecked.

The image produced in the preview is full RGB colour.  If I check the "raw mode" box then I get a greyscale image with a sort of checkerboard pattern.  That's the raw colour data from the camera.  If I now enable "demosaic" in the "options" menu I get a colour image preview once again.  Do you see the same behaviour?

Now, if I uncheck "raw mode" the image remains in colour (the demosaic option in oacapture is doing nothing at this point because the camera driver is doing it instead).  If I select the "MOV" file format and save a short capture then I get a full colour image when I play it back even though "demosaic output data" was not checked.  This is because the data from the camera is full colour so that is what gets written to the output file.

Is that consistent with what you see, or is the behaviour on your system different (and if so, how)?

(Actually there does appear to be a bug here in that if raw mode is enabled and "demosaic output data" is set then you ought to be allowed to write a MOV file.  But that shouldn't affect what you're doing.  I'll add it to my list of things to sort out in the next release.)

James

[Peter Rosen]

On 1 maj 2016 at 16:41, JamesF said:

 

Ok, let's start with a few experiments...  I am running oacapture 0.9.0 with an ASI120MC (not the "S" model as I don't have the USB3 model) connected to my desktop.  The camera is in its default state (I plugged it in just before starting oacapture).

In oacapture I have connected the camera and disabled "demosaic" in the options menu.  In the "settings->demosaic" configuration window I have "demosaic preview image" checked, "demosaic output data" not checked, "Bayer format" is "auto" and "demosaic method" is "bilinear".  In the "camera" control box I have "raw mode" unchecked.

The image produced in the preview is full RGB colour.  If I check the "raw mode" box then I get a greyscale image with a sort of checkerboard pattern.  That's the raw colour data from the camera.  If I now enable "demosaic" in the "options" menu I get a colour image preview once again.  Do you see the same behaviour?

 

Yes, all that you have described above behaves the same for me.

(And of course, when checking "raw mode", "MOV" and "TIFF" are disabled and the only choices remaining are "SER" and "AVI").

 

On 1 maj 2016 at 16:41, JamesF said:

Now, if I uncheck "raw mode" the image remains in colour (the demosaic option in oacapture is doing nothing at this point because the camera driver is doing it instead).  If I select the "MOV" file format and save a short capture then I get a full colour image when I play it back even though "demosaic output data" was not checked.  This is because the data from the camera is full colour so that is what gets written to the output file.

Is that consistent with what you see, or is the behaviour on your system different (and if so, how)?

(Actually there does appear to be a bug here in that if raw mode is enabled and "demosaic output data" is set then you ought to be allowed to write a MOV file.  But that shouldn't affect what you're doing.  I'll add it to my list of things to sort out in the next release.)

Yes the behaviour on my computer is still consistent with your description.

 

/*Peter R

[JamesF]

In that case I think we can assume that the demosaic operation is happening correctly and that your problems are perhaps because the MOV file is not in quite the format AstroIIDC is expecting.  Can AstroIIDC save MOV files itself?

James

[Peter Rosen]

1 hour ago, JamesF said:

In that case I think we can assume that the demosaic operation is happening correctly and that your problems are perhaps because the MOV file is not in quite the format AstroIIDC is expecting.  Can AstroIIDC save MOV files itself?

James

Well, I don't think so. Whatever setting I use when demosaic is on in oaCapture, I get exactly the same result as when it is turned off, so how can it happen correctly as it has no effect at all. 

It's also visible on the RGB-split image I showed on the previous page of this discussion. The blinds in the window show pronounced jaggies especialy in the R and B channels. If the demosaic had worked correctly, all 3 channels would have had the same definition. I noticed this the first time I connected the camera and used oaCapture.

/*Peter R

[JamesF]

Fast demosaic algorithms are notoriously bad at handling hard edges and often produce exactly the effect you're seeing, so I'm not really surprised by that.  It's not necessarily indicative that the demosaic algorithm is broken, just that it isn't as good as one might wish.

I'm confused by your comment that "Whatever setting I use when demosaic is on in oaCapture, I get exactly the same result as when it is turned off" when in the previous post you agreed that with the camera in raw mode you saw a colour image with it turned on and a greyscale image with it turned off.  Those comments don't seem consistent so perhaps I've missed something.  If raw mode is not enabled then certainly none of the demosaic options will make a difference because it's meaningless to apply a demosaic operation to an image that is already full colour.

James

[Peter Rosen]

8 hours ago, JamesF said:

Fast demosaic algorithms are notoriously bad at handling hard edges and often produce exactly the effect you're seeing, so I'm not really surprised by that.  It's not necessarily indicative that the demosaic algorithm is broken, just that it isn't as good as one might wish.

I'm confused by your comment that "Whatever setting I use when demosaic is on in oaCapture, I get exactly the same result as when it is turned off" when in the previous post you agreed that with the camera in raw mode you saw a colour image with it turned on and a greyscale image with it turned off.  Those comments don't seem consistent so perhaps I've missed something.  If raw mode is not enabled then certainly none of the demosaic options will make a difference because it's meaningless to apply a demosaic operation to an image that is already full colour.

James

Sorry for the confusion. I am a just a user and have detected a problem so I'm trying to describe this problem but I cannot claim to understand the techniques involved. But I'm doing my best to give a meaningfull feedback.

This is the way I would describe it:

I have been using the firewire DBK41AF02 from The Imaging Source for years using Astro IIDC for capture and stacking. As I mentioned earlier it needed the instalation of a special codec called ASC_Bayer 3.01.00. It captures movies in the MOV-format and they are RGB with full definition in R, G AND B.

Now, when I use oaCapture with the ASI120MC-S camera in the MOV-format I get a far inferior capture with R and B beeing heavily underrepresented, and G beeing just a little better, reflecting that R and B occupy 1/4 each of the total pixels of the sensor and G representing 1/2 of the pixels on the sensor.

I thought that this was what the debayering was to take care of and compensate for before generating the output file. But you say that the debayering will be meaningless and not work on the RGB capture I get through the MOV-format.

If I have to activate Raw Format for the debayering to work, I only have the option to capture in AVI and SER-formats, none of which will work on my Mac (cannot play them back or use them for stacking).

If you use a Mac yourself for capture and stacking, could you please describe your workflow as I feel stuck with the only possible option left seeming to move over to using a PC instead.

Thanks

/*Peter

[Peter Rosen]

1 hour ago, Peter Rosen said:

Sorry for the confusion. I am a just a user and have detected a problem so I'm trying to describe this problem but I cannot claim to understand the techniques involved. But I'm doing my best to give a meaningfull feedback.

This is the way I would describe it:

I have been using the firewire DBK41AF02 from The Imaging Source for years using Astro IIDC for capture and stacking. As I mentioned earlier it needed the instalation of a special codec called ASC_Bayer 3.01.00. It captures movies in the MOV-format and they are RGB with full definition in R, G AND B.

Now, when I use oaCapture with the ASI120MC-S camera in the MOV-format I get a far inferior capture with R and B beeing heavily underrepresented when it comes to resolution, and G beeing just a little better, reflecting that R and B occupy 1/4 each of the total pixels of the sensor and G representing 1/2 of the pixels on the sensor.

I thought that this was what the debayering was to take care of and compensate for before generating the output file. But you say that the debayering will be meaningless and not work on the RGB capture I get through the MOV-format.

If I have to activate Raw Format for the debayering to work, I only have the option to capture in AVI and SER-formats, none of which will work on my Mac (cannot play them back or use them for stacking).

If you use a Mac yourself for capture and stacking, could you please describe your workflow as I feel stuck with the only possible option left seeming to move over to using a PC instead.

Thanks

/*Peter

 

[JamesF]

Ok, I think I have a better understanding now...

The TIS camera can only provide raw colour data to the application.  I'd guess that to convert that to full RGB colour, AstroIIDC uses the Bayer codec you mention.  Those converted frames are then stored in the .mov file.

The ASI120MC can either provide full colour images (already converted to RGB) or raw colour.  I'm actually fairly sure that the camera itself only delivers raw colour, but if the application asks for RGB frames then the driver does the conversion itself before handing them to the application.  So, with raw mode disabled oacapture gets an RGB frame from the ASI120MC driver and doesn't do any other processing on it.  When raw mode is enabled oacapture receives a raw colour frame from the driver and you can choose whether to save it as is, or to process it to full RGB before saving it.

As far as I have been able to find out, neither the TIFF nor MOV formats have any way to store raw colour frames (unlike AVI or SER).  This is why TIFF and MOV are disabled if you have selected raw mode.  The only way (with oacapture 0.9.0) that you can save MOV files is to disable raw colour and use the RGB frames returned by the camera driver.  So, perhaps the built-in conversion process is what causes the problems you're seeing.

I have already changed the behaviour of oacapture so it will allow MOV (and TIFF) files to be saved if the camera is in raw mode and demosaic of the output data is enabled, but it is not fully tested yet and there are other new features that also haven't been heavily tested.  However, once I believe the demosaic part is working I could build another release for you to test if that would help.

(My own workflow at the moment is to capture using oacapture, then transfer the files to a Windows machine the following day where I stack and process using AutoStakkert!2, Registax and Photoshop.  Given that more stacking applications are becoming available for UNIX and UNIX-like operating systems, and in particular Linux and OSX, I hope that will change in the near future so that I don't have to transfer between OSes.)

James

[Peter Rosen]

Thank you for your feedback, I think I also get a better understanding now of the way it works.

28 minutes ago, JamesF said:

However, once I believe the demosaic part is working I could build another release for you to test if that would help.

Yes indeed, it would be very interesting to test that release.

 

/*Peter R

[CarlosD]

Hi, just wanting to report here what I have encountered with a point grey chameleon 3 USB 3 version.  I am not sure if there is more to do installing Oacapture other than downloading and starting the program.  I downloaded 0.9.0 on a 27 inch iMac running El capitan.  I started the program and connected my Chameleon camera.  The camera connects but there is no image visible in the preview area.  It states a Max Frame rate of 73 but 0 for captured.  I tried recording  but nothing.  I also tried on a macbook air running yosemite and still the same issue.  Any advice?

Thanks

Carlos

 

 

[JamesF]

There's no more to do other than downloading the dmg and dropping it where you want it installed, so you should be ok there.  Do you have all of Apple's latest updates installed on El Capitan?

James

[CarlosD]

Hi James, thanks.....yes my iMac is completely up to date with El Capitan.  I downloaded the link on your site and mounted the disk image on the desktop and launch the program.  It starts and recognizes the Chameleon (CM3-U3-31SAM-CS)....this is the IMX265 CMOS chip version.  It will just not display any images. I also tried on an older iMac that still runs Yosemite and encountered the same behavior with 0.9.0...older versions of the OaCapture on that mac resulted in a hard crash.  In any event here is a screen shot of what I am seeing.....

Thanks

Carlos

 

[Peter Rosen]

Hi Carlos,

under "Camera" you can see that your Point Grey camera has been detected and is displayed in the list but you must also click once on it to select it before you can use it.

/*Peter R