OSC Faux SHO failing in Compose import

[PaulInNorthMichigan]

About a year back I learned a Faux SHO technique from Ivo in which I brought in Red as SII, Green as HA and Blue as OIII. It is faux because I am using a one shot color camera. (ASI533MCPro)

I am using the Luminance Extreme filter for the HA and OIII.

I am using a dedicated SII filter for the SII.

I believe that I am using the same technique that I tried last year; this time I am attempting this with the Wizard Nebula.

I can bring the 2 Fits files in from the L Extreme, or the 1 SII Fits image. I can not however bring the L Extreme Files in with the SII file.

I get the following fail message.

Compose Import Error.png (338.78 KiB) Viewed 23992 times

This isn't allowing me to go beyond the failure. I believe that all of the fits images were pre processed the same way in APP. Any idea for why this fails.

[Mike in Rancho]

Hi Paul,

Well, I suppose I would take ST literally to start out with, and check the x and y resolution of each file. This can be done in just about anything, including ST if you just bring them in by themselves.

I don't know how APP creates it's duoband extractions or registration of the duo to discrete SII data, but my guess is something went amiss in one of those steps?

If the x and y are identical, we might have to look for other differences, and I'm not sure what ST thinks about mixing and matching those. Is each file an extracted mono FITS now - the Ha from the duoband R, the OIII somehow (?) a combination from the duoband G and B, and the SII from the SII R?

I have done similar composites with my L-eNhance and a discrete SII, both on a D5300. I would not call them Faux SHO at all, even though they aren't pure SHO from mono. They are just SHO with some usually minimal contamination in the duoband files, plus debayering in all files. Actual Faux SHO, which is decently popular, generally involves some technique to fabricate a third channel, or just plain hue manipulation of selective areas. Often very pretty, if you're into that sort of thing.

[PaulInNorthMichigan]

Mike,

As far as the APP narrowband; the OIII and Ha were extracted separately. This produced a couple mono looking Fits files. The SII was extracted as SII by itself and it also resulted in a mono appearing Fits file.

If we were to assume that the pairing couldn't be made due to a dimensional difference: All 3 files were not cropped in APP. Likely there also would be small placement differences, but you would anticipate something like that any time you would shoot a set of images such as RGB.

With that being said I didn't see a big placement offset when I integrated the SII image together with the 2 L Extreme results.

I could possibly crop to an exact X and Y dimension and see if that makes a difference.

I am not sure whether to do the crop in APP or in Star Tools. Not sure I go in and out of Compose to crop.

[Mike in Rancho]

Hi Paul,

Unfortunately not enough information yet to unravel the issue. And I don't have APP so I can't quite guesstimate what might have occurred.

Did you check the dimensions yet on say, the Ha file versus the SII file? Same camera used for both filters? Same stacking "mode," if available (I don't know if APP has an intersection mode like DSS, which you would probably not want here).

How are the two filter files registered to each other (i.e. star aligned)? Generally could be done in the stacking itself, by using the prior final stack or the single known reference sub from the final stack - but of course only as reference, not to be included.

An exact X and Y are of course needed in order to Compose them in ST, though the question would be why aren't they already matching. They really should be. Cropping to match and then saving, in any program including ST, might take a bit of legwork because you don't want to ruin the star alignment in doing so, again possible because of this mysterious mismatch (each would require different cropping).

Feel free to link your files and I could take a peek at them, if you like. Another quickie solution would be to use ASTAP for "calibration and alignment only" which will save out three new files (with aligned appended to the name). It will use what it considers to be the "best" file as the reference, ensure star alignment as needed, and the files will all be the same X and Y (matching the chosen reference). You will then only need to crop overlaps after composing all three in ST as SHO. Unlike DSS, ASTAP can start out with files that have different dimensions, which yours seem to. I believe the only limitation is that you need matching bit levels (probably all 32 here?) and they all have to be either mono or color. As far as you've described it, that's what APP should have produced for you...

[PaulInNorthMichigan]

Mike:

I was able to batch crop the 3 images in APP. Unfortunately it took the widest of the 3 images and cropped to it. Even knowing this I cropped again and there still was a void on the right of 2 of the 3 images.

I took this into Star Tools and it did allow me to compile. My results were very disappointing. The color banding actually favored to the right side; not symmetrical to the central image. Since there was such a wide variety of consistently bad results I didn’t save the image.

I am still wondering whether the imported data is the real culprit though.

I would like to make sure the right side cropping is clean on all 3 images, and see what that does.

Also, I noticed while processing the SII images in APP that some of my images had star widths of 5, even though many were around 2.5. If I could pare out the larger star images perhaps the end result might be more pleasing.

Lastly, and quite importantly I am not certain that I am applying the correct processing techniques in Star Tools.

I am not sure if I am applying the correct L Synthetic “””” choice in Compose. (What applies best to the OIII and Ha from the L Extreme and the SII data)

After bringing the images together I did a typical top to bottom processing in Star Tools.

I don’t have enough drop box space to share any files. I can however share images that I get in Star Tools when I reprocess the data.

[Mike in Rancho]

Hi Paul,

Great to hear you got something working! Though I admit this situation still has me thoroughly confused.

Are you seeing star alignment between all three files? You should be able to see this on the screen from within compose -- after each file loads in, if there are bright enough stars in the linear files a few will pop up. And you should see said stars land, well, right on top of each other in each channel.

Culling some outlier bad frames can always be a good idea.

Since these files are, in essence, now effectively grayscale narrowband SHO (I presume), you would just compose them as such and the default of L+Synth L from RGB, RGB, would be appropriate.

Hopefully someone who uses APP can jump in with better suggestions as to what may be going on with the stacking, extraction, and registration.

I will say, from it being last month's CN Challenge target, and from still using it as sampling for the ongoing "Mike's terrible stars vs SVD" thread, the Wizard is not an easy SHO target. Ha is strong. SII is actually decently strong. OIII is pathetically weak. But of course what everyone wants is to show a nice big patch of blue streaking away from the lower Wizard structure. Easier said than done.

If you are running into issues like that, you might consider -- binning way down to gain SNR, and making sure your Wipe is strong enough to handle any gradients in the OIII. I used a 6.5nm OIII filter on mono and it picked up plenty of gradient, and I used 75 in the aggressiveness despite being SHO narrowband (the Wipe narrowband preset would set that to zero).

[hixx]

Hi Paul,
I am also using APP for stacking
While I don't use SHO technique, I might have some hints regarding the error:
1) Try not to let APP extract H-a and O-II. I'd suggest let Compose do it. So just produce 1 duoband stack which You will import in both G 6 B in Compose (leaving stack
2) Load all lights and corresponding Flats, Darks and Flatdarks into APP as 2 sessions (e.g. duoband and S-II.
3) In tab 6, top use Multi/channel filter option " integrate per channel" and "integrate all" under Multi-session options
3) In ST Compose, use option "Channel Interpolation" when loading the OSC duoband stack into both G & B
3) For stacking the files in APP tab 6 bottom, under "Composition" use option "reference" which crops the result matching the reference frame exactly.
4) Use ST Crop to further eliminate border artefacts
Clear Skies,
Jochen

[Mike in Rancho]

Hi Jochen,

Excellent to get some APP expertise in here.

I may be missing something in reading your workflow, however. In Paul's case, and again I have done this exact thing myself though not via APP, we need a red channel from his SII file for the Sulfur (that would be placed in Red), but also another red channel from his duoband file for his Hydrogen (which would be placed in Green). And then either another extraction or combination of the duoband B and G for oxygen (which would be placed in Blue).

This can be done in ST with a few more steps using compose and then saving off files (though they become 16 bit) to later recomposite. Or, they could be later extracted (i.e. post final stack) in something like ASTAP or Siril, maintaining 32-bit depth. Maybe in APP as well. Though as far as I know only within ST could you utilize a (2xG)(B) technique in creating and saving off that mono OIII file.

[PaulInNorthMichigan]

Thanks guys, this gives me some things to look at.

Perhaps at the end of the day I may just determine that there isn’t enough OIII to make it worth while, but up to that point I’d like to experiment as per your suggestions.

No hen: You suggested to bypass extracting HA and OIII with the L Extreme processing. I am assuming that you would also recommend not extracting the SII from the SII filter processing.

I have never attempted a multiple session processsing in APP but your suggestion appears to combine the L Extreme and SII data into one Integration.