Firecapture / Omegon 385MC problem

[Tommohawk]

Hi all. I've been using my Omegon 385MC with Toupsky capture for a while now for planetary imaging. However I noticed that Firecapture, which I'd always used previously, now has Omegon capability.

So last night I set up with FC - but the screen showed an odd grid pattern , and I couldnt find any setting which would alter this. I figured it was maybe just a display oddity, and wouldn't affect capture.

However, it does. the captured images also display this pattern. I wondered if it was something to do with gamma settings, but doesn't seem to be. It loks the same with gamma disabled/altered. Debayer is disabled.

I cant see any other setting that affect it.  

I hooked up my ASI290mm and that seems normal, and also my ASI1600mm. I don't have another colour camera to try.

Would be great to get it sorted - Ive gotten to like Touptek, but Firecapture is definitely better. Any ideas anyone?

2022-09-27-2336_4-U-RGB-Jup_pipp_lapl5_ap150_conv.tif

Edited September 28, 2022 by Tommohawk

[CraigT82]

When you tick the debayer option in FC does it debayer correctly on the preview or does it still have the weird pattern? 
 

The Jupiter image looks like it’s been debayered with the wrong pattern in AS3, not sure what the actual patttern is but you can force AS3 to use a user specified pattern rather than autodetecting, you can just try each one until it looks right. I wonder if FC is reporting the wrong bayer pattern in the SER header which is causing AS3 to trip up? 

[CraigT82]

Just found this on the IMX385 data sheet... GBRG

Edited September 28, 2022 by CraigT82

[Tommohawk]

Hi Craig and thanks for your input.

TBH I struggle to get my head round the whole debayer thing, not helped because there seems to be lots of conflicting info out there!

In the past I worked in mono mostly for planetary, although I did some with a ZWO 290MC and had no problem - that was some time back and I cant recall my FC settings.

My understanding its best not to debayer when capturing, although not everyone seems to agree. Even if it did it makes focussing really tricky.

Not sure I follow this but here Kokatha Man (Daryl) seems to say to use debayer when capturing? Edit: but just realised this is for lunar, so end result will mono.

According to this the pattern is only in preview - but as you can see from my image above that isnt so! But that comment is from Torsten and he should know!! the grid pattern is definitely in both the SER file and the processed TIFs.

So I'm baffled. Your info on the bayer pattern is useful, thanks for that - but in the end if you have the wrong pattern that will simply affect the colour - it should cause a grid pattern surely?

And looking at the info you posted, is shows Gb and Gr - what  the heck is that???

And to confuse things further it all looks fine with Toupsky -  maybe a glitch with FC??

Puzzled!

Quick follow on - if I set FC to debayer when capturing, the grid disappears. 

Edited September 28, 2022 by Tommohawk

[CraigT82]

56 minutes ago, Tommohawk said:

Quick follow on - if I set FC to debayer when capturing, the grid disappears

Ok that’s good, so FC does know what the debayer pattern is then, is the FC preview the correct colour and not odd looking?
 

56 minutes ago, Tommohawk said:

My understanding its best not to debayer when capturing, although not everyone seems to agree. Even if it did it makes focussing really tricky.

Yes I always focus using the debayered colour preview but then switch it off for capture. If I remember correctly I got significantly slower frame rates when FC was debayering each frame and so I always have it switched off (I think that was with a 224mc) but never tried it with my 462 or 485, just always switch it off now out of habit. 

 

56 minutes ago, Tommohawk said:

but in the end if you have the wrong pattern that will simply affect the colour - it should cause a grid pattern surely?

No actually you still get the grid pattern if the wrong debayer is used, it’s to do with the demosaicing (interpolation between the pixels) being incorrect too. 

I think Firecapture might be writing the wrong bayer pattern into the SER header and that is being picked up by AS3 making it debayer the video frames incorrectly, but you can force it to use the correct pattern so if you run it through AS3 and force the correct bayer pattern you should be good I think. 

My advice is to always do your debayering in AS3 as it uses a much more sophisticated algorithm for interpolation called bayer drizzle, this can overcome the resolutions disadvantage of OSC cameras compared to mono. 

 

 

Edited September 28, 2022 by CraigT82

[Tommohawk]

Thanks for that Craig.

37 minutes ago, CraigT82 said:

Ok that’s good, so FC does know what the debayer pattern is then, is the FC preview the correct colour and not odd looking?

IN FC without debayer selected, I get a mono image with grid, as above.

If I select debayer, there is then the option to manually choose the Bayer pattern.

If I choose RG I get a grid free yellowy image (Though this is with artifical light and no optical system)

If I choose BG I get a grid free turquoise type colour.

If I choose GR or GR I get lots od vertical coloured stripes.

37 minutes ago, CraigT82 said:

No actually you still get the grid pattern if the wrong debayer is used, it’s to do with the demosaicing (interpolation between the pixels) being incorrect too. 

OK that's really interesting and maybe thats the nub of it. But if I'm not using debayer to capture, why is the raw SER file showing the grid? If it's not debayering while recording, there is no grid to get wrong.... ? In the FC log file, Debayer defintiely shows as "No".  Maybe I misunderstand this!

37 minutes ago, CraigT82 said:

I think Firecapture might be writing the wrong bayer pattern into the SER header and that is being picked up by AS3 making it debayer the video frames incorrectly, but you can force it to use the correct pattern so if you run it through AS3 and force the correct bayer pattern you should be good I think. 

As above, if I dont ask it to bebayer, there is no grid to get wrong??

37 minutes ago, CraigT82 said:

My advice is to always do your debayering in AS3 as it uses a much more sophisticated algorithm for interpolation called bayer drizzle, this can overcome the resolutions disadvantage of OSC cameras compared to mono. 

I actually do this in PIPP before putting into AS!3 - it's always worked fine in the past.

So it seems the only way to get rid of the grid is to debayer, and select "RG" or "BG". The colour balance will presumably always be off in no-debayer mode, because of the greater number of "G" pixels. With toupsky the SER files recorded are green, but this resolves with PIPP.

One other thought - I read somewhere that some apps flip the image, and that this can muck up the Bayer pattern. Not sure if thats relevent? 

Edited September 28, 2022 by Tommohawk

[CraigT82]

How are you viewing your SER files? I use SER player (downloaded from PIPP website). That will read the bayer pattern in the SER header and temporarily debayer the video file before playing which will give you a clue if the wrong bayer pattern is written into the SER header (That Bayer pattern will be written into the SER header by FC whether or not it is debayering the video). You can actually read the SER file header in SER player too.

I think the best thing to try now is to take your undebayered Jupiter video capture and run it though PIPP or AS3 to debayer it with the debayer pattern GBRG, and if that doesn’t work try the other patterns to see which is the correct one, then compare that with what is written into the file header (using SER player).

 

 

Edited September 28, 2022 by CraigT82

[Tommohawk]

Sorry just realised I'm confusing things a bit when I say "grid pattern". When I say grid pattern I mean a physical grid you can see on the screen. Ill call this "grid effect" going FWD to distinguish fomr Bayer grid pattern!

So. yes, I'm using SER player. And looking at the file info in SER player, with the  FC unbayered file I get the grid effect, and the pattern in SER player shows as GBRG. With toupsky unbayered I get a greent// yellowy image, no grid pattern, and in SER player it also shows as GBRG

So something weird going on for sure. 

And also I realise now that one image is indeed flipped with respect to the other. Not sure what , if anything, that might mean - but there's a thread out there somewhere about how it can spook the bayer pattern. 

I thought there used to be setting in FC to flip the image, but I cant find it now - anyhow, this may flip the image and matrix, whereas the issue I'm looking for is an image flipped with respect to the matrix... if that makes any sense at all!

One way or another the Touspky recording is totally different to the FC recording even thought the Bayer pattern is the supposedly same. See pic below - FC on the left - you can maybe just make out the grid effect. Toupsky on the left

[Tommohawk]

Sorry, more questions!!

In FC, if I were to save as bayered, the pattern options - -as mentioned above - are RG, GB, GR, BG. But these are just 2 pixel sets - the patterns are normally expressed as 4 pixel sets as per the SER files (eg GRBG)

Also, in the pattern you gave in your first reply, two of the pixels are Gb and Gr - I dont get what that means?? 

Grateful for your input Craig - or anyone else's! 

[symmetal]

If the colour camera image isn't debayered it will always show the 'grid' pattern as you've seen as the R, G and B colour filters in front of the pixels let through different amounts of light, which you'll see as this repeating pattern of different brightness dots over the image. Depending as to how much the image is zoomed to fit on screen this will appear as grid of lines of varying spacing, but this is just a result of the image resampling the undebayered image to fit it on the screen, so don't worry about the lines. At full 100% zoom they won't be there, nor once the image is debayered later in processing and is then resized on screen.

As shown in Craig's picture your Bayer pattern is GBRG which is different to the RGGB present on many cameras and which is the default chosen by FC. Switching debayer on/off in Firecapture only affects the preview image and not the recorded image, unless you click the down arrow next to the debayer icon and tick the 'Force record in colour, not recommended' box. You should in reality never record debayered as the debayer algorithm in FC is rather crude and it consumes a lot of processor time debayering each frame. You also have the option to not debayer the preview during capture which may help with improving fps if you don't have a powerful enough PC. Preview is updated slowly during capture so debayering the preview doesn't take much processor time.

Selecting the wrong debayer pattern may still give a visible 'grid' pattern as the different brightness dots are now assigned to the wrong colours on screen. Looking at a 'normal' subject, green pixels are usually the brightest, then red pixels, with the blue pixels being darkest.

You need to select GB as your debayer pattern in FC. You only need to specify the first two pixels of the group of four as the other two pixels are inferred by definition. Green pixels are diagonally opposite on cameras used nowadays. Your selecting GB means the second pair of the four will be RG by default. FC will store the selected bayer pattern in the Ser file header as Craig says so if it's selected wrong in FC it will be wrong in AS3, though it can be overridden in the AS3 menu.

Calling the pixels Gb or Gr in the bayer pattern just refers to Gb pixels being recorded on the same line as the blue pixels, while the Gr pixel are on the same line as the red pixels. This may help the debayer algorithms in selecting pixel patterns but you can ignore this distinction when specifying the bayer pattern, as it's again inferred by looking at what the pixel next to it is. Camera data is read out line by line and not in a square groups of 4 pixels so the data sent out by the camera will be a line of alternating G and B pixels followed by a line of alternating R and G pixels and so on repeated until the end of the frame.

Hope that helps Tom. 🙂

Edited September 28, 2022 by symmetal

[Tommohawk]

hi Symmetal and thanks for such a detailed response - it's very helpful. I have now tied myself in complete knots with all the tests I have done, and whilst it looks like I may have a solution I'm not sure why.

Starting with the easy bit toward the end of your post, your explanation of the 2 character definition of the 4 pixel group in FC makes perfect sense, as does the explanation about Gb and Gr pixels. Got that, brilliant.

However:

10 hours ago, symmetal said:

If the colour camera image isn't debayered it will always show the 'grid' pattern as you've seen as the R, G and B colour filters in front of the pixels let through different amounts of light, which you'll see as this repeating pattern of different brightness dots over the image. Depending as to how much the image is zoomed to fit on screen this will appear as grid of lines of varying spacing, but this is just a result of the image resampling the undebayered image to fit it on the screen, so don't worry about the lines. At full 100% zoom they won't be there, nor once the image is debayered later in processing and is then resized on screen.

But why don't I get this grid effect with toupsky, either when capturing or viewing or processing the file? The toupsky SER file is definitely not debayered, because when I open it in PIPP it offers to debayer. My Q in the previous post still stands. Why does the undebayered Toupsky SER file look different to the undebayered FC file - there is no grid pattern. Undebayered is undebayered.. right??? Maybe not!!

 

10 hours ago, symmetal said:

You need to select GB as your debayer pattern in FC.

What difference does it make if its not actually debayering??

And if in FC I do select GB I get this, and a grid effect on the saved undebayerd SER file:

If I select RG I get this, and no grid pattern - this may be the solution:

BUT... having types all that I realise that I can change the debayer options in SER viewer. If I load the SER file with nasty grid, ie when debayer set in FC to GB, but then change the debayer options in SER manually to RGGB it fixes the grid, and then has the expected yellowy green hue.

What this means however, is that if when recording I set debayer in FC to RG, the images look great ... BUT...  when viewing these SER files in SER player the debayer patterns for toupsky and FC dont match. See below- the Toupsky file is on the left, the FC on the right:

 

My conclusion, which is probably 100% wrong, is that FC somehow has the pattern wrong due to the image being flipped. 

Hilariously, in all of this I was running out of disc space, so I deleted all the "no good" FC files I took when Jupiter was at meridian. Grrr.

Please do offer further thoughts/ corrections!!

[symmetal]

Hi Tom,

When you view the debayered preview image in FC at 100% size, I assume the vertical stripe pattern you see disappears, and you just see a fine pattern of coloured dots. This is what the wrong debayer pattern selected will  likely look like.

I don't know why the Toupsky undebayered looks different to the FC undebayered image. Look at them both at 100% size, not reduced size, where the stripes appear. Both should show a fine dot pattern of different brightness corresponding to the coloured filters in front the pixels. If the Toupsky one doesn't show this dot pattern then it's possible it's averaging the group of four pixels for the preview image. 

It's likely that RG is your correct debayer pattern. I found that Astroart when you choose a debayer pattern they are displayed rotated 90 degrees so you end up choosing the wrong one. An easy way to test this once and for all is to look at a scene where you know what the colours are. Zwo give a wide angle lens with many of their cameras so you can use them like a normal camera and point it out the window and then choose a debayer pattern where the grass is green and the sky is blue.  🙂 Then you know it's right.

If you dont have a lens to fit on the camera, then in daylight just place something with one strong colour like a book cover or piece of coloured card, fairly close to the camera sensor and see the colour of the blurred image you get. Choose a debayer pattern where the colour is closest. Confirm you have the right selection using another book or card with a different colour.

If you have the camera on the scope just place the coloured object fairly close in front of the scope to check the colour.

Your last two Toupsky and FC images look to be the same debayer pattern. The FC one is just brighter as a different gain has possibly been used. 

The image looking yellow is quite normal as usually a lot of blue gain needs to be used in FC or any capture program to get a more balanced colour image.

Alan

Edited September 29, 2022 by symmetal

[Tommohawk]

Hi Alan, and once again thanks for your input. 

The point with the two approximately yellow looking SER images  (yes I didn't check the exposure/gain etc) is that to  get that result youll see the Toupsky one on the left shows as GBRG and the FC one the right shows as RGGB (bottom right of the image) This seems inconsistent and I think there may be some misinterpretation in the capture software, similar to your experience with AstroArt. My guess is that this is caused by a flip in the axis prior to the bayer pattern being applied. You can see in the images of jupiter a few posts back that one is definitely flipped with respect to the other.

In any event it looks like I have a fix.... so more testing tonight provided the sky clears!

Later next day  ... sorry I thought I'd sent the response above!

Anyhow, I have a result. Fanfare etc. In FC I set it to debayer for viewing only, and record undebayered using RG. PIPP then deals with this as ever it did, and equalises RGB which I find very helpful. Then to AS!3 with the bayer pattern set to auto. Everything works fine now I have the original recording sorted.

Some folk say its better to let AS!3 debayer - better algorithm. But I tried this and couldn't see any difference - though to be fair the data isnt great. Also FC doesnt equalise RGB and I struggle adjust that nicely in PS. 

FC has "align RGB" feature which I assume means laterally shift channels as per Registax rather than align histo?

TBH there's lots I still struggle to understand, primarily why telling FC what the pattern is makes any difference, when it isn't actually saving as debayered. Is it because it stores the pattern as a header, which is then applied - rightly or wrongly - in the next stage ie PIPP or AS!3? 

Here's the result - done with my SW200PDS and Powermate x5 (set at x4) Not as good as my mono results from some years back, and if I'm honest a bit disappointing. Sharpened to death and reduced to 0.9x. Seeing was pretty good and 34 degrees alt, so .. I must need a bigger scope!

Any comments welcome -  thanks Alan and Craig for bearing with me!

[symmetal]

Ah! Didn't notice that your Toupsky and FC had different debayer patterns selected. There isn't any actual rule that specifies how bayer pixel patterns should be represented, and TL, TR, BL, BR it seems has been adopted by the majority, but not all.

A vertical image flip is done by some Capture programs, Astroart being one again, presumably to make fits files more 'standard', as fits data was primarily used for storing graphical data, where coordinate 0,0 is at the bottom left. Raster image files have evolved where pixel 0,0 is at the top left so vertically flipping the image makes 0,0 at the same place in the fits file. I assume Toupsky can store single fits images, and they just used the same data orientation in their video files. 🙂

The data from the camera has no information as to what the bayer pattern is, the camera itself doesn't 'know' or 'care' if there is a bayer filter mask or not, it just reads out the brightness value of consecutive pixels. That's why it's helpful to specify the bayer matrix in FC via the Ser file header, even though it's recorded raw, so that as you say, subsequent programs don't have to guess or be told each time. If you specify the wrong one though as you've found, it can cause havoc. 😊

Yes, align RGB in FC does register the RGB channels on top of each other, if you don't have an ADC to do that optically.

To adjust colours in Photoshop select the menu option 'Window / Histogram' to show all three colour channels above each other so you can set the colour gains more easily. Setting the colour of the black end of the histogram is easy if the data isn't clipped to black initially, and hovering the curser over the dark background, use levels or curves to make the background pixel value the same value just above zero.

To avoid the image data being black clipped set the camera 'offset' in FC 'camera settings' high enough that the hump at the left of the histogram has its peak away from the left hand edge.

Your final image, although nice colour, doesn't have much detail as you say. How did you focus? I use a bahtinov mask on a bright star beforehand. Also keep the camera exposure around 5mS to hopefully freeze the 'seeing' and don't worry about using a high camera gain to use about 70% of the histogram on the target. It may look very noisy in the preview but stacking the frames in AS3 will remove the noise. Get your fps rate as high as possible by using a short exposure as mentioned, record in 8 bit, and select 'high speed' in the FC camera settings if available. Don't use gamma during capture, leave it at 50, which is the same as turning it off, or just turn it off. Applying gamma adjustment to each frame involves significant processor time which slows your fps. You should hopefully then be getting around 200fps which will give you 24,000 frames in a 2 minute video and you can select a 10% or so stack in AS3 to only use the best 2400 frames in your final image, which is plenty enough to allow lots of sharpening in Registax wavelets before it gets too noisy. 😀 

That should help you get sharper results, Tom. Good luck.

Alan

Edited September 30, 2022 by symmetal

[Tommohawk]

Hi Alan and thanks for the further useful info. 

The scope I'm using is one I've had for some years - 200PDS + powermate 5x, which is actually working at 4x. It's given much  better results in the past with the same set up and capture technique, but using ASI290MM + filters

That capture was done at 4ms, ~250fps and I joined the best adjacent 2x 90 second runs to make a 180 sec file with ~45000 frames, then stack in AS!3 best 10%. (no better with more or fewer frames) Gamma off. 

I agree that focus looks off - but I focused using both Bahtinov and / or manual fine tuning using the excellent autoalign feature in FC. It's the same method I've used for years with good results. 

At least I've solved the fundamental capture issue in FC which is excellent - I've got used to Toupsky and it does have some features which FC doesnt have, but overall for planetary FC is better I think. That said Touspky gives my max frame rates from the outset, where FC can can be quite flaky especially when capturing without ROI ie full res.

Anyhow, many thanks for your input!