2023-04-17: APP 2.0.0-beta17 has been released !
RAW support for camera color matrix with Bayer Drizzle integration, fixed couple of image viewer issues.
We are very close now to releasing APP 2.0.0 stable with a complete printable manual...
Astro Pixel Processor Windows 64-bit
Astro Pixel Processor macOS Intel 64-bit
Astro Pixel Processor macOS Apple M Silicon 64-bit
Astro Pixel Processor Linux DEB 64-bit
Astro Pixel Processor Linux RPM 64-bit
Green Cast and Odd Histogram on Integrations with OSC.
I have a query about the results I'm getting from APP integrations. Not exactly a problem but something that looks curious and I'd like to try and make sure that it's not hiding a fault.
Sorry if this turns into a long post, here goes.
I have a OSC camera (an Altair Astro 183C). When I use APP I leave the RAW/FITS (Tab 0) set to "supported" assuming that APP can determine the correct Bayer matrix stuff for my camera. I also have a full set of calibration files (Flats, Darks, Bias, even Dark Flats)
Most other options in APP I leave unchanged but on the "5) NORMALIZE" tab I de-select "neutralize background" - in line with most advice/tutorials for APP.
Following Integration, the results always look something like this (shown with "log" scale to clearly show the issue):
It has a complete green cast and the histogram looks very odd with very separate R, G and B channels and loads of top end green.
If I select the "neutralize-BG" option on the right hand side, I get the following (ie, from the same integration, just enabling neutralize-BG"):
Which looks OK, and I can go on to process this with the background compensation / star colour tools etc and get quite nice results.
I read a lot of things about green casts from OSC cameras and I understand about the RGGB bayer matrix etc but - My main question is - I thought that the de-bayering process within APP would account for the extra green sensitivity of the OSC and remove the original green cast. Yet my integrations all have this very green cast and odd looking histogram.
If this is normal behaviour for a OSC then I'm happy, ie, I'm not seeing anything unusual or that is a problem.
I'm really just trying to confirm if this is normal? Or am I seeing something unusual that's needs some attention? (maybe it's something to do with the stretch that DPP adds).
Have other users seen similar results?
Can the APP guys shed any light.
Is this very heavy green cast correct for a one shot colour camera?
I thought APP would create the correct colour balance via the de-bayer process.
@smapo Debayering en removing a green cast are two different processes. Yes it is normal to have a green cast and a background neutralization usually will take care of it.
Thanks. Been reading around it more and it makes more and more sense. I was just kind of checking that I was seeing the right result - and it seems I am.
Very pleased with the results I'm getting from APP (looking forward to the next version).
@wvreeven I have a green cast issue that is amazing to me: I photographed the Rosetta Nebula with an ASI 183 MC Pro, using the L-eNhance filter. Because of my FOV I have to make a two-panel mosaic. I know about the options to extract H-alpha and OIII, but in this particular case I do not want to use these options but I want to treat the frames as OSC and build two RGB-panels and then use these to build the mosaic.
The amazing thing is that one panel comes out oke, while the other one has a green cast like the one shown above in this topic. The frames for both panels were made during three consequitive nights. Every night I made frames for both panels. I did not check "Multi-Session processing" in the LOAD-tab (mainly because I do not understand this option). In the NORMALIZE-tab I did not check "neutralize background", because I once read that you should not do that for mosaic-panels (but I forgot where I read this)
So the frames for both panels were made under the same conditions, and APP processes them with the same parameters. Then how is it possible that one panel does not have this green cast, while the other one has it?
I reprocessed the "greenish" panel with "neutralize background" checked. Now it is oke also. But still my questions remains.
Why that would be is very hard to say, it could be some side-effect of having a bit more signal in the channels in one night then the other, you are using a narrow-band filter so to make a RGB with that is not really possible (it won't create a nice RGB result). The reason for OSC images turning greenish is that you have more green pixels on the sensor, that without normalization, that signal will pop out.
@jan-monsuur I agree with Vincent's comment.
I want to treat the frames as OSC and build two RGB-panels and then use these to build the mosaic.
In order to get the best RGB-like image directly out of APP, choose the Ha-OIII color algorithm in tab 0. Did you do that?
I did not check "Multi-Session processing" in the LOAD-tab (mainly because I do not understand this option).
Multi-session processing allows you to load data acquired over several nights or with multiple optical trains into separate sessions to integrate them together. In case of separate nights, this is only needed in case you need to process them with different calibration data, for instance different flats for the different nights.
In the NORMALIZE-tab I did not check "neutralize background", because I once read that you should not do that for mosaic-panels (but I forgot where I read this)
You should select "neutralize background" to make sure that all frames of the two panels have their backgrounds neutralized in the same way. This allows APP to better create a neutral background in the mosaic panels which helps to avoid obvious transitions between the panels in the final mosaic.
Every night I made frames for both panels.
There still can be differences in a single night that can introduce these differences, like varying light pollution, Moon phase and altitude, humidity, high clouds etc etc. Especially the OIII part of the L-eNhance filter is sensitive to this, even more especially if and when the Moon is involved.