15th Feb 2024: Astro Pixel Processor 2.0.0-beta29 released - macOS native File Chooser, macOS CMD-Q fixed, read-only Fits on network fixed and other bug fixes
7th December 2023: added payment option Alipay to purchase Astro Pixel Processor from China, Hong Kong, Macau, Taiwan, Korea, Japan and other countries where Alipay is used.
I've been experimenting with drizzle on data from an l-extreme filter with some interesting results which I thought I'd share. In the attached picture of the jellyfish nebula the left integration is using the Ha-OIII color algorithm with normal drizzle. I've noticed when I do this (not just in this case) that I get this kind of basket weave texture in high magnification. The middle integration is switching to using Bayer/X-trans drizzle - surprising how much better this is - great result!
Where I get a bit lost is with trying to break out Ha and OIII whilst drizzling. The third pane is Ha-OIII extract Ha algorithm with Bayer/X-trans drizzle. Although the tooltip says the algorithm should be ignored in this case, you can see it actually isn't and is producing a grayscale image but it's not clear to me what's actually happening. It looks like there's bayering artefacts remaining in the image, and I don't think it is Ha - if I switch to extract OIII it looks like the same output. Ideally what I'd like is the quality of the Bayer/X-trans drizzle with the ability to separate out the Ha and OIII data. It seems I have to choose between bayer/X-trans drizzle with Ha-OIII color or normal drizzle with Ha-OIII extract - have I understood this right, or missed some way of doing this?
I should just add that extracting the two channels has really made a massive difference to my processing workflow and results. Thanks very much for adding this capability, it's highly valuable!
FIXED, BAYER DRIZZLE WITH THE HA-OIII debayer algorithms, enabling bayer drizzle with the Ha-OIII extract Ha or extract OIII algorithms did not work correctly. It showed the exact same result which was similar to the Ha-OIII mono debayer algorithm. It now works correctly as is show in the next screenshots:
Bayer Drizzle with Ha-OIII mono (so mix of the Ha and OIII signals):
Bayer Drizzle with Ha-OIII extract Ha (only Ha):
Bayer Drizzle with Ha-OIII extract OIII (only OIII):
A HOO composite of these Ha and O3 signals made with the RGB Combine and Selective Color tools (data courtesy of Ian Barredo @tracer, asi533 Optolong L-Extreme filter):
Mixed results so far... It definitely is now pulling out the signals properly, whereas before they looked the same no matter the algorithm, now it's clear the Ha and OIII are being extracted. However I'm seeing some banding on OIII and mono, while the Ha and color look great. Left to right is color, mono, OIII, Ha.
Thank you, glad to see that the signals are as expected for Ha & OIII.
Please be aware of the requirement for using Drizzle in general:
You need a lot of data, many frames !
They need to be undersampled
And all the frame need to be well dithered
What you are describing as banding, are well-known drizzle artefacts in fact. It means that not all pixels in the target drizzle grid are receiving enough data... leading to artefacts.
So it is very likely that you don't meet the drizzle requirements in your data with the drizzle settings that you used.
As a first step, enlarge the drizzle droplet size, then probably the drizzle artefacts reduce and the result will be less noisy as well 😉
Assuming you did dither you data with a random dither (so in all directions), how large was the dither step between exposures?
Which drizzle settings did you use for droplet, scale and kernel?
And how many frames were your processing with what kind of setup and exposure time?
Mabula
This post was modified 2 years ago 4 times by Mabula-Admin
@mabula-admin Thanks for the advice, I'll give that a go - haven't played with the drizzle settings at all because its a 2hr integration 🙂 I just automatically assumed it was something I had done wrong because it only was showing on the OIII rather than a lack of undersampling.
The data is 237 300s frames on a Redcat with an ASI533mc which gives a scale of 3.1 arcs/pixel, dithering every 2 frames by 5 pixels. I used 0.5 droplet, with 2 scale and tophatkernel.
I should add that the reason I'm drizzling is because by eye the stars do look undersampled and blocky. On the right is a normal integration with no drizzle, on the left is the Bayer drizzle. Fantastic results for the color image.
@mabula-admin Thanks for the advice, I'll give that a go - haven't played with the drizzle settings at all because its a 2hr integration 🙂 I just automatically assumed it was something I had done wrong because it only was showing on the OIII rather than a lack of undersampling.
The data is 237 300s frames on a Redcat with an ASI533mc which gives a scale of 3.1 arcs/pixel, dithering every 2 frames by 5 pixels. I used 0.5 droplet, with 2 scale and tophatkernel.
-Mark
Since it is Bayer Drizzle, you need to be aware that with droplets of only 0.5 you need a massive amount of data..., much more than you process now. This is because the bayer holes really are not well covered quickly. So try droplets of 1.0 and keep scale just at 1.0 to start with 😉
What you can do to find nice drizzle settings for any particular set is to use the Composition Crop mode in 6) Integrate. You can then simply test the drizzle settings an a small interesting part of your field of view 😉 Then when you have nice settings, giving you a fine balance between noise and sharpness and no drizzle artefacts, apply those settings on the full composition. Oh, keep the default kernel as well. Don't use the point kernel with Bayer Drizzle.
I should add that the reason I'm drizzling is because by eye the stars do look undersampled and blocky. On the right is a normal integration with no drizzle, on the left is the Bayer drizzle. Fantastic results for the color image.
-Mark
Indeed 🙂 Okay try droplets of 1.0 with scale 2.0 and let me know if the artefacts dissapear and the stars still look good ;-). It will definitely be less noisy. The smaller the droplets, the noisier is will be and more sharp. This is what drizzle will do, you need to find a balance to your liking between noise and sharpness.
The crop tip sped things up a lot, thanks Mabula, though still took quite a while to experiment as it takes a long time to load in file mappers for that many images (is there any way to reuse the file mapping between runs?). I read up a bit and now understand why I was having the problems with the bayer drizzle. I would suggest tweaking the pop-up that encourages switching from drizzle to bayer drizzle for CFA data - it implies this is a like for like swap rather than the fact that your settings will likely also need changing.
I had trouble finding any settings with this data that I was happy with for the bayer drizzle. By the time the patterns were more under control the stars had returned to blockiness. In the end I settled instead on debayering first plus standard drizzle at drop size 1 and scale 2 for the Ha and OIII - It's not as sharp as the bayer drizzle, but the fixed patterns are down to an acceptable level. For the colour integration I ended up doing a bayer drizzle with the same settings which seemed to cope better.
The screengrab shows the following: top row left to right is OIII drizzle, colour no drizzle, Ha drizzle; bottom row is colour bayer drizzle, colour drizzle, and no drizzle just scale 2.
I have to say I still can't get my head around why the OIII has worse patterns than the Ha - I'm assuming the Ha is from the red pixels and OIII from blue and green so I would have expected OIII to have more data to work with and fewer holes to cover. Maybe I don't understand the algorithm you're using to break out Ha and OIII data from the RGB? I'm also puzzled why the colour data is better - technically there's still the same holes to cover, so shouldn't it show the same fixed patterns in each colour that I see when I break out Ha and OIII, or is the overlaying of the fixed patterns canceling out into something that looks like random noise? One other thing to note is that the colour drizzle seems to have better colour than the colour bayer drizzle which has a greenish cast - assume this is because of double the green pixels in the CFA seeping through.
Thanks for all your help - I thought I understood this after reading your great forum post on drizzle, but it turned out I didn't until I read some more 🙂 I'm happy with where I've got to now and in the end I'm being really picky at very high magnification here which is not going to make any visible difference to the final result. It's good to know what's going on behind the settings though!
Excellent 🙂 I will have a look at the tooltip, maybe it will be easier if I internally use 2x droplet size when Bayer Drizzle is enabled? then you can use same droplet size with Bayer and Bayer Drizzle and better compare it? I will think about it
I had trouble finding any settings with this data that I was happy with for the bayer drizzle. By the time the patterns were more under control the stars had returned to blockiness. In the end I settled instead on debayering first plus standard drizzle at drop size 1 and scale 2 for the Ha and OIII - It's not as sharp as the bayer drizzle, but the fixed patterns are down to an acceptable level. For the colour integration I ended up doing a bayer drizzle with the same settings which seemed to cope better.
Yes, okay.
I have to say I still can't get my head around why the OIII has worse patterns than the Ha - I'm assuming the Ha is from the red pixels and OIII from blue and green so I would have expected OIII to have more data to work with and fewer holes to cover. Maybe I don't understand the algorithm you're using to break out Ha and OIII data from the RGB? I'm also puzzled why the colour data is better - technically there's still the same holes to cover, so shouldn't it show the same fixed patterns in each colour that I see when I break out Ha and OIII, or is the overlaying of the fixed patterns canceling out into something that looks like random noise? One other thing to note is that the colour drizzle seems to have better colour than the colour bayer drizzle which has a greenish cast - assume this is because of double the green pixels in the CFA seeping through.
Yes, the green cast in Bayer Drizzle is definitely produced by having 2x green pixels over red and blue. It is clear that the amount of information in R & B suffers relative to green and so you get a green cast. Much more data would remedy that for the color bayer drizzle using the same drizzle settings.
I think the O3 will have much less signal in general versus the Ha data, leading to more problems?
I the end, you would like to make a Ha O3 bi-color composite, right? So I would not concern myself with the Ha O3 color result. I would focus on getting nice Ha + O3 stacks and then make a nice bi-color, it wiil look much better than the color result where normally Ha will dominate over O3, thus seeing little of the O3 contribution.
I have a very similar problem as ennui2342 with the same setup: Redcat, ASI533mc-pro and a Optolong l-enhance dual narrowband filter in my case. I have nearly 8 hours worth of data (130x 3min), drizzled every third frame by max 5 pixels randomly in both axes. When I try to use bayer drizzle, these artifacts appear. It doesn't matter if droplets are anywhere between 1.2 to 2 and scale at 1 or >1 leads to similar results, with different appearances of these artifacts. They become very prominent once the scale is above 1. They always have a frequency of 3 pixels, no matter what scale I use.
Attached first image HA, second image OIII extract.
Glad to hear it isn't just me doing something silly Björn! I tried many different setting combinations and just couldn't get this to work, after 22 hours of data captured on the same target the o3 and mono integrations were still awful and I gave up and resorted to separating the channels post integration using pixinsight pixelmath rather than doing the separation in APP. The HaO3 colour integration is excellent so this gives a good result, even though I'd prefer to do the separation in APP with x-trans as it should be higher quality!
I have never experienced this myself to be honest with my data, so it might be still a problem with the data or the dither steps being too small. A dither of max 5 pixels is really small in my experience. Are your dither steps really random? If not, it could explain this ugly repeating pattern in your dither results.
I can not exclude that there might be an issue with Bayer Drizzle in combination with these Ha-O3 extract formula, so probably it is good if one of you or both can share your data with me so I can test and exclude some problem of APP's processing here 😉
Please upload it using the instructions at the top right of the forum and let me know once uploaded.
The OIII extracted from my ASI294MC using an L-Extreme filter shows a pattern which is not present in the extracted Ha.
I integrate using the Bayer/X-Trans method and Ha-OIII extract Ha/OIII algorithms in tab 0.
I have 30 subs of 300s, I know it may be too few for the bayer drizzle algorithm to perform well but the thing is that results from bayer drizzle on the same subs with pixinsight does not show the artifacts in either Green or Blue channels.
It makes me think it's a problem in APP which is frustrating since I really want to try an HOO processing with the APP tools.
Of course my APP version is the latest 2.0.0-beta2
Hereunder you will see top row: APP Ha, APP OIII; Bottom row Pix Ha, Pix Green
Edit:
I extracted the RGB channels from an APP integration with Ha-OIII color algoritm (still using Bayer/X-Trans method). Now the three channels are free of artifacts. So may the problem come from the Green/Blue combination to get the OIII ?
Left to right, top to bottom: Ha-OIII color red channel, Ha-OIII extract OIII, Ha-OIII color green channel, Ha-OIII color blue channel.
please make a folder with your name and let me know once uploaded 😉 I will have a detailed look soon. Based on the earlier reports, it does seem that there is a bug in the O3 extract in combination with bayer/x-trans drizzle indeed.
Can you tell me which drizzle settings you were using:
drizzle droplet size, drizzle kernel, and which scale ? That should help me duplicate the problem and solve it a.s.a.p !
I am on vacation right now and far from my PC. I will upload the data and provide you all information when I’m back the 5th of september. Glad to ear you are working on the issue.
I'm back and as agreed, I uploaded all the lights as well as master files in folder 'rbarbout'. I hope it will help you to find the issue with OIII extraction with bayer drizzle.
For information, all settings were set to default: topHatKernel, droplet Size = 1.0, Bayer/X-Trans Drizzle, scale = 1.0
My first testing indicates that there is NO BUG here with the O3 extract and Bayer Drizzle combination. The artefacts that you get are a combination of 2 things it seems:
- too little data for droplet size of 1.0. If I set droplets to 2.0, all artefacts are gone and the result is similar to interpolation instead of Bayer Drizzle. This is what we would expect.
- the blue channel is clearly worse than the green channel in terms of signal. So in your setup with your camera and filter more O3 signal is caught in the green channel compared to the blue channel.
These 2 factors combined result in the artefacts that you see. The drizzle droplets of green and blue do not match and can't average properly due to too little data with droplets of 1.0.
And this does explain why the single Green And Blue Bayer Drizzle channels look okay when extracted from the color Bayer Drizzle result.
I will run a couple of more tests. Maybe a solution for this issue will be to do a normalization of blue and green before making the O3 mono signal from Blue and Green Combined. In that way, even with too little data, the too small droplets can still average nicely together and not give drizzle artefacts. To be clear, what you see in this issue is a typical drizzle artefact resulting from too little data for the set drizzle parameters. (So yes, i think the solution if any would be in how green and blue are combined to get the mono O3 result)
Mabula
This post was modified 2 years ago 2 times by Mabula-Admin
I've noticed this issue since at least one year, but haven't reported it as I though it was something relative to my datas, and I didn't use this function anyway.
So I conducted some tests with the pre-beta5 and unfortunately, the checkerboard pattern is still present when extracting OIII in Bayer-Drizzle mode. I did not see any difference between result from beta4 except the beta5 pixel values are now twice the value of beta4. I used the very same data I already sent you and took some screnshots to show you the results:
Top center is Green channel from HaOIII_color in bayer drizzle mode Top right is Blue channel from HaOIII_color in bayer drizzle mode As you can see, no checkerboard pattern in these images even if they come from a bayer drizzle intergration of just 30 subframes. To build a OIII image, I mixed the Green and Blue channels with formula (2G+B)/3. I called this image GGB. As you can see in top left image, again, no pattern visible.
Bottom left is the result from HaOIII_extract_OIII in bayer drizzle mode . Here the checkerboard pattern appears. As experiment, I have subtracted this OIII image from my synthetic GGB image. The results are in center and right bottom images (GGB-OIII and OIII-GGB). These images show the differences between the extracted OIII and a OIII created by mixing Green and Blue channels. The lighter the pixel, the more the difference. The checkerboard appears clearly indicating evenly spaced deviation in pixels values. These deviation cannot be caused by lack of subframes since the Green and Blue channels do not have these artifacts and moreover, I conducted the same tests with another image of 95 subs and the result is the same.
I hope these data will help you to find what's going on. During this time, I will keep my GGB image as OIII even if it is not as accurate as the extracted OIII. Below are the same images with a lower magnification.
Last point, Red channel from HaOIII_color and Ha image from HaOIII_extract_Ha are the same and none is showing the checkerbord pattern so it seems the problem is just when combining the blue a nd green channels. All settings to default except stars detection set to 1000 and background neutralization disabled All images taken with an ASI294MC Pro (CFA pattern = RGGB) integrated in Bayer Drizzle mode, scale 1, droplet size 1, topHat Kernel.
Thank you very much for your detailed response. I re-opened this issue so I will work on this first thing tomorrow to see if I can solve it now... one question though for now: why the GGB image, what argument do you have for such a synthetic over a GB synthetic ?
Mabula
This post was modified 2 years ago by Mabula-Admin
