Astro Pixel Processor work flow for use in StarTools?
- richbandit
- Posts: 29
- Joined: Tue Oct 08, 2019 11:12 am
- Location: Chepstow, South Wales
Re: Astro Pixel Processor work flow for use in StarTools?
Hi Paul,
Here's my attempt at the Western Veil + Pickering's Triangle - not sure if this link will show an image here (still trying to figure out how to correctly upload an image into my posts!). All done, as described, with APP and Star Tools ...
If not, I'll try linking to it:
https://www.dropbox.com/sh/pz78tta7xff6 ... C+OIII.tif
Apologies if this ends up with two images!!
Here's my attempt at the Western Veil + Pickering's Triangle - not sure if this link will show an image here (still trying to figure out how to correctly upload an image into my posts!). All done, as described, with APP and Star Tools ...
If not, I'll try linking to it:
https://www.dropbox.com/sh/pz78tta7xff6 ... C+OIII.tif
Apologies if this ends up with two images!!
Re: Astro Pixel Processor work flow for use in StarTools?
The modified/Hixx's-settings image indeed has the desired teal coloringPaulInNorthMichigan wrote: ↑Mon Sep 07, 2020 6:20 pm there is a dramatic coloration difference when applying Hixx setting recommendations and using the display from the 1st import option as Ivo suggested.
![Thumb Up :thumbsup:](./images/smilies/handgestures/thumbup.gif)
The only thing missing is the bias, but this is a huge step in right direction.
With the bias missing, however, I can see some banding and "inverse" vignetting. Perhaps superfluous to mention, but ideally you would not correct this with a gradient reduction/removal tool but with calibration.
Please do take care when using sample-setting methods like these (see my previous comments/explanations) - particularly when dealing with well calibrated, faint signal.Finally, and perhaps surprisingly - I generally find that applying 'light pollution removal' on the 'tools' menu actually does seem to work for me! I would have also suspected that this might have a subsequent effect on Star Tool's tracking or it's own light pollution removal processes, but actually I tend to find it cleans the whole image up nicely. If you do use this feature, only run it through once though, and be very careful where you place the selection boxes (away from any objects of interest) - then save the image and move straight on to Star Tools to carry on ....
Any trouble with this do let me know, as color calibration and/or combining channels in other applications will have a detrimental impact on signal fidelity. StarTools (as of 1.5) goes through great lengths to keep color and luminance signal separate for this purpose!richbandit wrote: ↑Mon Sep 07, 2020 6:40 pm I have on occasion used APP's 'calibrate star colours' and 'combine RGB' tools when I have some data that appeared to be difficult (not sure why Star Tools didn't like it?) with some success.
Ivo Jager
StarTools creator and astronomy enthusiast
StarTools creator and astronomy enthusiast
- richbandit
- Posts: 29
- Joined: Tue Oct 08, 2019 11:12 am
- Location: Chepstow, South Wales
Re: Astro Pixel Processor work flow for use in StarTools?
Hi Ivo,
Thanks for your advice, and your concerns are duly noted!
Regarding my previous issue with star colours, etc. I wonder if that RGB data may not have been the best in that case? To be fair, I haven't needed to do that for some time ..... If I have a similar problem in future I may shout out to you for a little guidance!
Many thanks,
Richard
Thanks for your advice, and your concerns are duly noted!
Regarding my previous issue with star colours, etc. I wonder if that RGB data may not have been the best in that case? To be fair, I haven't needed to do that for some time ..... If I have a similar problem in future I may shout out to you for a little guidance!
Many thanks,
Richard
-
- Posts: 35
- Joined: Sat Aug 08, 2020 5:44 pm
Re: Astro Pixel Processor work flow for use in StarTools?
The modified/Hixx's-settings image indeed has the desired teal coloring![]()
The only thing missing is the bias, but this is a huge step in right direction.
With the bias missing, however, I can see some banding and "inverse" vignetting. Perhaps superfluous to mention, but ideally you would not correct this with a gradient reduction/removal tool but with calibration./quote]
Ivo: Are you referring to the bias frames that are included with the stack? I did include these in the stack, but it is possible it didn't come across correctly or I did the bias incorrectly.
I processed the modified image. Although I can see an absolute difference I can't say that it was a true improvement.
Below are the processed images in StarTools. The 1st is the modified image and the 2nd is the original. 1 interesting thing to note is that the original image was more compressed in size when I saved to a Jpeg. The modified image required a 2nd size reduction to get within what I believe the posting limits are. There may be a visual size difference between the 2 images.
Here are the settings that I used in StarTools.
Load: Linear for OSC/DSLR
Auto Dev: Default
Bin: Default
Crop: Ensured I had clean edges
Wipe:
-Dark anomaly 5
Auto Develop (2nd)
-Stretch image as is
-Ignore fine detail 1.5
-ROI tight to East and West Veil
HDR:
-Reveal Core Preset
Sharpen:
-Amount 500%
Deconvolution:
-Auto Generate Mask
Color:
-Fill Mask
-Legacy
-Matrix/Nikon D5500
-LRGB Method/RGB Ratio
-Red Bias Reduce: 1.4
-Green Bias Reduce: 2.0
-Blue Bias Reduce: 1.5
-Dark Saturation: 4.2
I'm not there yet but I appreciate the help given here!
From this point I will need to determine if the limitation is 1) My original data amount. (only 1 1/2 hours) 2) Distortion from using the UHC filter. 3) APP processing. Or 4) StarTools settings.
I did get great results when I processed Sadr with essentially the same settings.
- Attachments
-
- Veil_Mod.jpg (326 KiB) Viewed 15986 times
-
- Veil_Nebula_Original.jpg (462.66 KiB) Viewed 15986 times
Re: Astro Pixel Processor work flow for use in StarTools?
Hi all,
On the Adaptive Pedestal I am not really sure. Yes it actually does its job really great but my understanding was, non-linear operations like this should not be done before Tracking starts, else the DeNoise Module (and others) will not run on actual, precise information. Instead the Ampglow should be removed by DarkFrames (for the Lights) and Darkflats (for the Flatframes). These will subtract the Ampglow completely from the lights prior stacking, hence your result should be clean. Any remaining issues should be done by Wipe, if I am not mistaken. Probably Ivo can weigh in here.
The light pollution Tool in APP is gorgeous - no doubt, but again it would destroy any linear pixel information, so Tracking would not run optimal. My understanding is to avoid any non-linear or even discontinuous operations before Tracking had started.
The automatic setting in APP works great as well so as a beginner you don't need to bother with the settings. However Mabula had included some hover-over boxed that explain the setting briefly but very detailed, so it is really easy to understand the settings and find the right options.
If you all don´t mind, I´ll use your shared experience here and put together a quick doc with recommended APP settings
regards
richbandit, You are completely right, the flow I proposed was DSLR/OSC based. Mono Cameras of course will produce individual Datasets per color. So these are different at the first stage when loading in APP (no Bayer Matrix etc.), but the rest of the workflow should be the same. Tab 0 is for RAW conversion only, so if You don`t have no vendor specific RAW format this tab shouldn't apply.- If using a mono 'astro' camera (I have ASI183mm Pro Cooled) then I believe hixx's point #0 doesn't apply, as it's intended for DSLR and /or colour camera users. I don't think I've ever actually looked at that tab before!
- Because the 183mm is a CMOS chip, I MUST enable the 'adaptive pedestal/reduce amp glow' - it DOES make a difference due to the severe amp glow present on this (and similar) cameras.
On the Adaptive Pedestal I am not really sure. Yes it actually does its job really great but my understanding was, non-linear operations like this should not be done before Tracking starts, else the DeNoise Module (and others) will not run on actual, precise information. Instead the Ampglow should be removed by DarkFrames (for the Lights) and Darkflats (for the Flatframes). These will subtract the Ampglow completely from the lights prior stacking, hence your result should be clean. Any remaining issues should be done by Wipe, if I am not mistaken. Probably Ivo can weigh in here.
The light pollution Tool in APP is gorgeous - no doubt, but again it would destroy any linear pixel information, so Tracking would not run optimal. My understanding is to avoid any non-linear or even discontinuous operations before Tracking had started.
The automatic setting in APP works great as well so as a beginner you don't need to bother with the settings. However Mabula had included some hover-over boxed that explain the setting briefly but very detailed, so it is really easy to understand the settings and find the right options.
If you all don´t mind, I´ll use your shared experience here and put together a quick doc with recommended APP settings
regards
Re: Astro Pixel Processor work flow for use in StarTools?
Hi PaulInNorthMichigan,
This should allocate the bottom dynamic range freed up by WIPE to Your actual content, hence the background should get darker and noise pushed down.
some more tips to push noise down further:
- In AUTODEV (2nd stretch), after adjusting IGNORE FINE DETAIL, try reducing SHADOW LINEARITY and / or OUTSIDE ROI INFLUENCE
- In CONTRAST, reduce parameter DARK ANOMALY HEADROOM
- In LIFE, You may use ISOLATE preset to push down noise and busy star fields.
see also Guy's USER NOTES on the forum for more tips and special techniques (also contained in the Inofficial Manual available on Download)
regards,
jochen
I think at this step You might want to try the option REDO THE STRETCH rather than STRETCH IMAGE AS ISAuto Develop (2nd)
-Stretch image as is
-Ignore fine detail 1.5
-ROI tight to East and West Veil
This should allocate the bottom dynamic range freed up by WIPE to Your actual content, hence the background should get darker and noise pushed down.
some more tips to push noise down further:
- In AUTODEV (2nd stretch), after adjusting IGNORE FINE DETAIL, try reducing SHADOW LINEARITY and / or OUTSIDE ROI INFLUENCE
- In CONTRAST, reduce parameter DARK ANOMALY HEADROOM
- In LIFE, You may use ISOLATE preset to push down noise and busy star fields.
see also Guy's USER NOTES on the forum for more tips and special techniques (also contained in the Inofficial Manual available on Download)
regards,
jochen
Re: Astro Pixel Processor work flow for use in StarTools?
Hi Ivo,
https://www.astropixelprocessor.com/com ... /#post-914
APP Release Notes 1.073 provide a good explanation what LNC does - from what I read here I do not understand why it would eat signal. In general APP outlier rejection is designed to work on rather high kappa values ( 3.0 for High Kappa and 6.0 for Low Kappa). Furthermore, hot pixels will be removed using a bad pixel map (created from MasterDark and MasterFlat), not by outlier rejection on LightFrames. All this should ensure the signal is preserved as best as possible and actual averaging is done on all available signal (except satellite trails etc).
https://www.astropixelprocessor.com/com ... #post-5699
There is another great feature in APP stacking which is the quality weighting average, i.e. the best frames get weighted 100%, the worst in the stack are about 50%-60% I believe. When stacking a high number of frames, this will improve the overall stack result. I did not see any obvious negative impact on tracking (I'm sure You will
).
As someone said before in this thread, APP and ST make up a terrific combo. This is why I really think Tracking while stacking would improve the ST result even further - whether it would be ST's own stacking engine (like APP) or a standardized interface to APP. APP provides lots of pixel statistics for each frame - so probably there is something useful for ST already available in the APP stats.
regards,
jochen
For MultiBand Blending I found this:I'd have to read more about MBB to see what it does... Does anyone have any pointers to documentation, video or a forum post?
https://www.astropixelprocessor.com/com ... /#post-914
APP Release Notes 1.073 provide a good explanation what LNC does - from what I read here I do not understand why it would eat signal. In general APP outlier rejection is designed to work on rather high kappa values ( 3.0 for High Kappa and 6.0 for Low Kappa). Furthermore, hot pixels will be removed using a bad pixel map (created from MasterDark and MasterFlat), not by outlier rejection on LightFrames. All this should ensure the signal is preserved as best as possible and actual averaging is done on all available signal (except satellite trails etc).
https://www.astropixelprocessor.com/com ... #post-5699
There is another great feature in APP stacking which is the quality weighting average, i.e. the best frames get weighted 100%, the worst in the stack are about 50%-60% I believe. When stacking a high number of frames, this will improve the overall stack result. I did not see any obvious negative impact on tracking (I'm sure You will
![Wink ;)](./images/smilies/icon/wink.gif)
As someone said before in this thread, APP and ST make up a terrific combo. This is why I really think Tracking while stacking would improve the ST result even further - whether it would be ST's own stacking engine (like APP) or a standardized interface to APP. APP provides lots of pixel statistics for each frame - so probably there is something useful for ST already available in the APP stats.
regards,
jochen
Re: Astro Pixel Processor work flow for use in StarTools?
Much appreciated Jochen! I will do further research,hixx wrote: ↑Wed Sep 09, 2020 10:58 am Hi Ivo,For MultiBand Blending I found this:I'd have to read more about MBB to see what it does... Does anyone have any pointers to documentation, video or a forum post?
https://www.astropixelprocessor.com/com ... /#post-914
APP Release Notes 1.073 provide a good explanation what LNC does - from what I read here I do not understand why it would eat signal. In general APP outlier rejection is designed to work on rather high kappa values ( 3.0 for High Kappa and 6.0 for Low Kappa). Furthermore, hot pixels will be removed using a bad pixel map (created from MasterDark and MasterFlat), not by outlier rejection on LightFrames. All this should ensure the signal is preserved as best as possible and actual averaging is done on all available signal (except satellite trails etc).
https://www.astropixelprocessor.com/com ... #post-5699
There is another great feature in APP stacking which is the quality weighting average, i.e. the best frames get weighted 100%, the worst in the stack are about 50%-60% I believe. When stacking a high number of frames, this will improve the overall stack result. I did not see any obvious negative impact on tracking (I'm sure You will).
As someone said before in this thread, APP and ST make up a terrific combo. This is why I really think Tracking while stacking would improve the ST result even further - whether it would be ST's own stacking engine (like APP) or a standardized interface to APP. APP provides lots of pixel statistics for each frame - so probably there is something useful for ST already available in the APP stats.
regards,
jochen
There is actually something that's been on my wish-list for a long time. This is being able to access/know per-pixel what the standard deviation (or some other measure, like MAD) was during stacking.With some further trickery, this may enhance signal evolution Tracking's accuracy further.
This potential benefit alone is one major reason why I would even think about adding stacking capabilities to StarTools. However, as you can see in the APP and PI forums, the maintenance burden for just a simple stacker is enormous; just to keep up with external libraries and camera idiosyncrasies is a big task, taking up a lot of development time. I am worried that it would divert too much of my time, simply doing something that is already competently done by a great number of other (free) applications. It's a big time sink with not too much scope for innovation.
Post-processing, on the other hand, is where innovation is happening fast and where new techniques and opportunities are waiting to be discovered and implemented.
Ivo Jager
StarTools creator and astronomy enthusiast
StarTools creator and astronomy enthusiast
-
- Posts: 35
- Joined: Sat Aug 08, 2020 5:44 pm
Re: Astro Pixel Processor work flow for use in StarTools?
Richbandit: Very nice detail on the Western Veil Nebula. I like the twisting effect which is clearly visible on your image. I did not get the same type of effect; perhaps due to the length of acquisition and perhaps you are zoomed in more with your image.richbandit wrote: ↑Mon Sep 07, 2020 6:52 pm Hi Paul,
Here's my attempt at the Western Veil + Pickering's Triangle - not sure if this link will show an image here (still trying to figure out how to correctly upload an image into my posts!). All done, as described, with APP and Star Tools ...
If not, I'll try linking to it:
https://www.dropbox.com/sh/pz78tta7xff6 ... C+OIII.tif
Apologies if this ends up with two images!!
Even though you are using filter(s) you aren't struggling with colors as my image is.
-
- Posts: 35
- Joined: Sat Aug 08, 2020 5:44 pm
Re: Astro Pixel Processor work flow for use in StarTools?
Jochen: I really appreciate your assistance in picking out flaws with my settings. I have tried all your suggestions and the result is arguably better than before. The biggest improvement surprisingly is in coloration. The stars themselves look somewhat improved.hixx wrote: ↑Wed Sep 09, 2020 10:24 am Hi PaulInNorthMichigan,
I think at this step You might want to try the option REDO THE STRETCH rather than STRETCH IMAGE AS ISAuto Develop (2nd)
-Stretch image as is
-Ignore fine detail 1.5
-ROI tight to East and West Veil
This should allocate the bottom dynamic range freed up by WIPE to Your actual content, hence the background should get darker and noise pushed down.
some more tips to push noise down further:
- In AUTODEV (2nd stretch), after adjusting IGNORE FINE DETAIL, try reducing SHADOW LINEARITY and / or OUTSIDE ROI INFLUENCE
- In CONTRAST, reduce parameter DARK ANOMALY HEADROOM
- In LIFE, You may use ISOLATE preset to push down noise and busy star fields.
see also Guy's USER NOTES on the forum for more tips and special techniques (also contained in the Inofficial Manual available on Download)
regards,
jochen
From my own intuitive standpoint it would have seemed that "Stretch image as is" would have made more sense as I saw this as integrating the previous steps. I can't argue that it did make the background darker just as you said, and the other colors are more pronounced. In the general sense is "Redo the Stretch" the more natural choice?
I will look into Guy's USER NOTES per your suggestion.
You have a lot of good information to share for APP users.
That would be awesome!
APP is a great software, but by itself the ability to bring out vivid details is lacking. I'm sure there are many people in the same boat as I in looking to have a way to transition to better images such as can be found in StarTools.
As far as my Veil image is concerned I will attach my last results to compare my 1st modified attempt with your suggested settings. This is still not a great image, (there's only so much that can be done to an image with issues) but I'm a lot happier with the results obtained.
- Attachments
-
- Veil_Mod2.jpg (449.91 KiB) Viewed 15946 times