Suggestions to reduce confusion

Randy

Randy

Well-known member
I've now gotten good with PI, but I ran into two problems that you can easily address. When I ran into the problems, I did a lot of searching and found that many people experienced the same thing. Thus, this post.

1. Change STF's default to unlink the color channels. This isn't clear to the new user, and in one case I found on CN an imager had used CC30 Magenta film filters to remove the green tint. While looking at the posts, I came to believe that the RGGB pattern contributes to or causes this, so the Unlinked default will probably give most new users better results.

2. Using the CIE C* channel in CurvesTransformation requires the image be linearized. If it's used on a new image without an embedded histogram transformation, the color balance changes dramatically with any Curves saturation tool. I looked a lot and found people saying that the image needs to be in a certain color space; It takes experience to understand this, but I found a video on YouTube demonstrating a saturation enhancement. He started by opening a file that didn't need an STF. When I did the same, saturation worked naturally and maintained color balance. I've shown an image of M42 that's quite remarkable in another thread on the SubframeSelector Move/Copy option. The suggestion: if the user clicks C* or Sat on a non-linearized image, the program issues a warning (that can be disabled) making the direct statement that the tool is best used on an image with an embedded histogram from the STF. By telling the exact steps necessary for success, hours of web searching will be eliminated.

Thanks again for the fine program and wonderful new release!
 
Last edited:
i think Randy is asking juan to change the default configuration of STF, not suggesting that users change their defaults.

rob
 
Let's remove the ambiguity. This is from 268 30s subs on the first night with a 100ED (not enough patience to set up PHD2). Open the original xisf file. Open SubframeSelector and note that the upper-left button is active, linking the channels. Press the Radioactive button. This is the result.

Current default STF.png

Unlink the color channels by clicking the button and see this.

New default STF.png

pfile has it right. I'm asking Juan, pardon the lack of introduction, to modify the program defaults in favor of the latter results. Seriously, this button's importance is more difficult to find than people here might think. As I said, in my search I ran across a user who found CC30M filters would come close to fixing it. What a Godsend it was when I ran across it.

[EDIT] I realized that this default might only be applicable to RGGB files and hope the suggestion is interpreted in the context of an ASI294MC.
 
Randy,

As an instructor, I have a different perspective. This default would hide the very nature of the issue at hand- color balance and more importantly color calibration. By automatically finding the best STF per channel (unlinked channels), the ambiguity of whether or not an image was already color calibrated would be increased dramatically. Many beginners and users that know "enough" to get around will be very confused (I predict based on my experience) by this default and wonder "why did my color balance change ... " in later steps. The uncalibrated image is a real feature of the data. The unlinked autoSTF is neither a real feature nor a true color calibration.

People *already* have issues with understanding what the autoSTF does (especially when a change to the image is made and the STF is unchanged). This default would multiply the ambiguity by three (for each channel).

Your green result is actually giving you some information. It is telling you something about the debayering process, the color of the sky, and any other systematic color bias in the data. This is actually useful information.

There is certainly an argument to be made about the tool's functionality and the current state of the image- but making the 3-channel unlinked autoSTF a default I think will be even more problematic (and inconvenient) than your current issue.

-adam
 
It's wonderful to have a forum open to reasonable presentations of alternate viewpoints. My requests are not for myself, as I've learned the product to a reasonable degree. These are only stumbling blocks that I found common in many new users, yet ngc1535 may still be right overall. As an alternative, a settable option would eliminate the confusion. It's a bit embarrassing to admit how many hours it took me to find the simple answer.
 
If you'll pardon this second, reconsidered post, I realize most people on this forum are extremely skilled. It would not surprise me if the ngc1535 and his supporters are all three-band mono users, who certainly would not benefit from the change. If this is truly an artifact of RGGB debaryering rather than technique or conditions, then defaulting to Unlinked [for RBBG images] provides the most true presentation of the available data.
 
Randy said:
It would not surprise me if the ngc1535 and his supporters are all three-band mono users, who certainly would not benefit from the change. If this is truly an artifact of RGGB debaryering rather than technique or conditions, then defaulting to Unlinked [for RBBG images] provides the most true presentation of the available data.
Click to expand...
Your assumption is wrong: at least Fred and I are using OSC cameras.

Bernd
 
Randy said:
If you'll pardon this second, reconsidered post, I realize most people on this forum are extremely skilled. It would not surprise me if the ngc1535 and his supporters are all three-band mono users, who certainly would not benefit from the change. If this is truly an artifact of RGGB debaryering rather than technique or conditions, then defaulting to Unlinked [for RBBG images] provides the most true presentation of the available data.
Click to expand...
Thank you for taking time to consider my position.
The color bias could have multiple sources. A simple example is imaging with the moon in the sky.
This will always cause a blue bias (in otherwise equally responsive pixels/system).
This blue bias is actually a real thing... that is later calibrated out.
With regards to OSC... I guess I have to be open to all cameras and data formats...since I need to make videos on each and field questions on all.
-adam
 
bulrichl said:
at least Fred and I are using OSC cameras.
Click to expand...
Let me confirm that. Ever since I got my ASI2600MC Pro OSC in July 2019 it has been my principal camera. It took me a while to understand that the "magic" visualisation using unlinked STF was something of a dangerous seducer. It looks as though, at the simple push of a button, the image has been colour balanced and stretched to near-perfection. A linked STF made it clear that the image was not colour balanced; the unlinked STF had simply performed a "blind" histogram equalisation - which only achieved near-correct colour balance if the image really did average out to neutral grey (which some starfield images may come close to, but many complex nebulae definitely do not).
With PCC now a highly polished and reliable utility, you can accurately colour balance most images early in the processing workflow, after which you have no need for the unlinked STF.
As a default, I would much prefer to know the truth, rather than a seductive lie ;) .
 
ngc1535 said:
I see... so the "S" in STF stands for succubus... :)
Click to expand...

Now you've caught me! :devilish:

Seriously, the STF tool has never been intended to provide a 'nice' representation of the image. STF aims at providing a realistic visual representation, including all defects and problems that one will have to fight when processing in the nonlinear phase, as well as the true potential of the image. STF is also necessary to work on linear images with algorithms such as deconvolution, multiscale transforms, noise reduction, etc.

For this reason the STF tool is not an image stretching tool and does not modify pixels, but just their screen representation.
 
Randy said:
It's wonderful to have a forum open to reasonable presentations of alternate viewpoints. My requests are not for myself, as I've learned the product to a reasonable degree. These are only stumbling blocks that I found common in many new users, yet ngc1535 may still be right overall. As an alternative, a settable option would eliminate the confusion. It's a bit embarrassing to admit how many hours it took me to find the simple answer.
Click to expand...
If you'll allow my fanboyism to shine through, and if you haven't already, I would recommend checking out Adam's you tube channel. He has a huge amount of extremely informative tutorials on there regardless of existing PI knowledge.
Search for Adam Block....

en.wikipedia.org

Adam Block (astrophotographer) - Wikipedia

en.wikipedia.org en.wikipedia.org
 
What a can of worms I inadvertently opened. Thanks for your reply, Juan. I'm familiar with STF, embedding it with a histogram for use with linear algorithms, and such things. In fact, now that I have your eye, it's hard to come up with a fine enough compliment for your implementation and broad array of algorithms. Thank you very much for all you and the other contributors have done.

I have no bone to pick about these issues and would like to let it be. I certainly didn't mean to ruffle feathers, only to offer potentially useful thoughts.
 
Last edited:
PS, Fred, thank you for the new viewpoint re color balance; I will learn PCC as I move forward. Scotty38, thank you also, I'll watch Adam's YouTube at your recommendation.
 
I unlink the STF just before I do DynamicBackgroundExtraction(DBE). I find it easier see the background without the color cast. Thus, it is easier to place my sample points in DBE.

I typically have a strong green color cast. I use a QHY268C OSC camera.

I have two suggestions to make it more obvious that unlinking the STF helps remove the color cast.

1. Create a new button in STF that is RemoveColorCast. In the tool tip for this button it
would be explained that this is done by unlinking the STF.

2. In the tool tip for Link/Unlink add words that would indicate that unlinking could be
used to possibly remove a color cast.

Jack
 
Randy said:
If you'll pardon this second, reconsidered post, I realize most people on this forum are extremely skilled. It would not surprise me if the ngc1535 and his supporters are all three-band mono users, who certainly would not benefit from the change. If this is truly an artifact of RGGB debaryering rather than technique or conditions, then defaulting to Unlinked [for RBBG images] provides the most true presentation of the available data.
Click to expand...
The whole notion that you can buy any camera that does not require color calibration is a fallacy. I've owned several mono cameras and several one-shot-color cameras. I am currently using one of each. Color calibration is a necessary part of image processing.

The STF process, including AutoSTF, is a tool for visualizing the data, not manipulating it. I sometimes want the channels linked, and sometimes I don't, depending on what I am doing. Whether the camera is mono or OSC does not factor into it. I also frequently adjust the sliders manually - again, sometimes linked and sometimes not, depending on what I am trying to do.

Finally, I want to say something about the green noise. A while ago, I made a comment on Cloudy Nights that mentioned the 1:2:1 aspect of pixels under the Bayer matrix and suggested that this was the reason for green casts. I was educated on the subject that debayer algorithms average the pixel values, so the green signal is not 2x that of the red and blue channels (assuming neutral grey).

That said, I would expect that S/N to be a bit better in the green channel, due to 2x the number of pixels, and that may affect an AutoSTF. But the main factor is simply that many sensors are simply more sensitive to light in the green part of the spectrum. That's why we see green noise pixels, even with mono cameras with RGB filters. It's also worth noting that both Aurorae and air glow can both be green, so it may even happen that the sky background actually has a green bias in some cases.

My workflow for RGB data, regardless of camera, is generally to do a PhotometricColorCalibration very early in processing. I have gone back and forth over whether this should be done before or after gradient correction with DynamicBackgroundExtraction. In practice, I have not see a huge difference by changing the order. The important thing is that both tools are each used correctly to handle the specific data in the image.
 
Fellow astrophotographers, can you please help?

Today I was granted an Order of Protection by a Superior Court judge. My Losmandy Titan holding an SW Esprit 150ED was tipped over intentionally. Brian at Losmandy knows the story, and Daleen at AP will be helping me find a 1600GTO to replace the irreparable Titan. I've been prepping for today's hearing for 6 days or so and am now officially brain-dead. This might explain some of my posts?

Wadeh - thank you for the courteous and informatory post. I tried using PCC on the M42 xisf file above. In summary, court went better than PCC. I couldn't find a setting for nebula, I tried some star types at random, and to my dismay it worked best on the "...Errors" image. Completely brain dead.

If you would like to make a sad APer happier, could you please look at the xisf and jump-start me on PCC? I can't focus well enough to learn as one should. If you or anyone can run this image and capture the PCC settings, I would be most grateful.

This started with a request and ended up as a classroom; what a fine group of people.

Thanks to all!
Randy
 
You must log in or register to reply here.
Back
Top