Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Change star profile image interpolation to nearest neighbor #1081

Closed
wants to merge 1 commit into from
Closed

Change star profile image interpolation to nearest neighbor #1081

wants to merge 1 commit into from

Conversation

alexhelms
Copy link
Contributor

The star profile image is currently bicubic scaled but I'm proposing changing to nearest neighbor which I think makes more sense. Normally you want a high quality scaling like bicubic but specifically for astrophotography we actually like nearest neighbor so we can see the pixels. Not seeing the pixels, in my opinion, is misleading because the star appears to show more detail than there really is.

Below is an example using the camera simulator.

Bicubic (current):
image

Nearest Neighbor (proposed):
image

agalasso
agalasso approved these changes Jun 13, 2023
View reviewed changes
Copy link
Contributor

@agalasso agalasso left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice improvement!

bwdev01
bwdev01 reviewed Jun 13, 2023
View reviewed changes
Copy link
Contributor

@bwdev01 bwdev01 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have reservations about this if it has only been tested using the simulator. The simulator produces very nice Gaussian profiles which are not typical of many guiding setups. I would like to see some testing done on real-world star images that include comatic and astigmatic aberrations before we merge the changes

@alexhelms
Copy link
Contributor Author

Here is a screenshot from a real star from last night. This is from an OAG on a 2100mm focal length scope.

image

Regardless, I don't quite understand why this should have been anything other than nearest neighbor. Any kind of interpolation misleads you into thinking the camera has more resolution than it does.

@alexhelms
Copy link
Contributor Author

And here is another example:

image

@bwdev01
Copy link
Contributor

bwdev01 commented Jun 14, 2023

I still don't understand why this is a desirable thing to do. I don't want to be argumentative, but I want to give you my perspective based on 10 years of PHD2 development and end-user support for it. The images you've shown are for badly saturated stars, not stars that should be used for guiding. What is the effect of this change for difficult guide stars - for example, an 11th magnitude star with an SNR of 20? It looks like the net effect to the typical user might be to see heavy pixelation and greater brightness variations at the pixel level. How is this useful to them, what is the benefit? The Star Profile tool is recommended for reaching critical focus of the guide camera. How will the pixelated star images help with that? How will the image renderings behave in periods of poor seeing as you move in and out of focus? Will the revised rendering help a user to see convergence of focus? Another common use of the Star Profile tool is to look at HFD values to see if the current Min-HFD setting is appropriate. If the change in rendering has a strong effect on the HFD values displayed in the Profile window, how will they correlate with currently established Min-HFD values?

PHD2 is used by thousands of people around the world, so we have to manage it as we would a commercial-scale product. When we are considering changes, the decision is always measured by 1) is this going to make the product easier to use and/or 2) is it going to allow people to get better guiding results or use new/different gear. I can't answer those questions for this proposed change. When we do make a change that is going to affect everyone but may only benefit some, we always provide a means for people to avoid consequences of the change. If this change was implemented as-is, it would create a support nightmare. Users would see what appears to be a seriously degraded star image in the Star Profile window and their reaction is predictable:

  1. Something has gone wrong with my camera
  2. I will change the gain settings, change focus, or change the camera driver. In the process, equipment profiles will be negatively affected.
  3. I will get on the support forum and ask for help.
  4. While I'm waiting for help, I will de-install PHD2 or revert it to an earlier release.
  5. When the earlier release works, I will post additional messages on the forum announcing that the latest PHD2 release has bugs and should be avoided.

As the "owner" of the change, you would be expected to be actively engaged in dealing with all these support issues, probably not something you want to do. That suggests to me that the new rendering approach would, at the very least, need to be implemented in the UI as an option whose default value would be use of the current algorithm. That assumes of course, that we can answer the question of whether this is an important change to make and be able to explain how it will provide practical benefits to the user base.

Thanks.

@cconstantine
Copy link
Contributor

I'm a user and recent contributor (I removed a line of code :) ) of phd2, and the current star rendering is something that has confused me. It confused me because I thought it was an actual zoom-in of the star, but it was suggesting way more resolution that I have, and the star profile to the left didn't seem to fit any part of the star rendering on the right. This is because the left is not interpolated, but the right is interpolated. I would expect for either both of them to be interpolated or neither. Interpolating for the profile is, I think, more clearly the wrong answer so not interpolating both would be my expectation.

I like this change.

I still don't understand why this is a desirable thing to do.

The current display algorithm doesn't show the real data, and I usually like seeing the real data. I agree with @alexhelms that I don't understand why the current behavior is desirable. In fact, I thought the current display method was a result of some kind of unfortunate limitation, not a decision that was made.

The images you've shown are for badly saturated stars, not stars that should be used for guiding.

Not quite. The first two images (with the star profiles) are from the simulator, and do show over saturated stars, but the following two images (without star profiles) are reported to be from a telescope and do not look saturated. In fact, it's easier to see that they are or aren't fully saturated with this change. With the bi-cubic interpolation the fully saturated star previews reads to me as having a rounded top which suggests they aren't fully saturated, and the only way to tell they are fully saturated is by looking at the star profile.

What is the effect of this change for difficult guide stars - for example, an 11th magnitude star with an SNR of 20? It looks like the net effect to the typical user might be to see heavy pixelation and greater brightness variations at the pixel level. How is this useful to them, what is the benefit? The Star Profile tool is recommended for reaching critical focus of the guide camera. How will the pixelated star images help with that? How will the image renderings behave in periods of poor seeing as you move in and out of focus?

These are some very good questions. I would expect this to either have no effect, or a positive effect for all of those situations. Perhaps we could get some samples of those situations with and without this change?

For the low SNR stars that is mostly a question of the stretch applied to the data before display, and, if anything, doing bicubic interpolation will dampen the already low peak signal. Our vision is based on variations of brightness, so by having greater brightness variations it'll be easier for us to perceive what is really happening. I've always been frustrated with the star preview for reaching critical focus because it's all blurry. I can use it to get the focus close, but for getting the final focus position I have to use the star profile (and computed hfd). This is because the smaller a feature is the more the bicubic interpolation is lying to me about what the data really looks like. Seeing the pixels also helps me get a sense for how big the currently selected star is. Without the pixels it's hard to get a sense of how big the star actually is on the sensor.

If the change in rendering has a strong effect on the HFD values...

My understanding is that this change will only effect the rendering of the star to the screen. It will not change the computed HFD.

I can't really speak to the user-support issues this will (or won't) cause, but if this were made into a checkbox in the settings I would expect most people to go in and check it.

@agalasso
Copy link
Contributor

agalasso commented Jun 14, 2023 •
edited
Loading

thanks for your input @cconstantine

this change will only effect the rendering of the star to the screen. It will not change the computed HFD.

that is correct.

if this were made into a checkbox in the settings

let's not go there! we've got too many settings already and they end being a support problem in themselves!

@bwdev01 what do you think about trying this change out in your obs to get a feeling for how it looks in action?

@bwdev01
Copy link
Contributor

bwdev01 commented Jun 14, 2023 via email

@alexhelms
Copy link
Contributor Author

I agree with what @cconstantine has said so no need to repeat.

PHD is the only astro software I can think of that shows the user an interpolated zoomed-in image. Everything else shows the user an image without interpolation (nearest neighbor) so the user can visualize the real data from the sensor. The user isn't seeing "heavy pixelation", they are seeing the raw data from the sensor which is critical to understanding. Interpolation hides the ground truth because it is by definition interpolating data that does not exist.

As @agalasso mentioned, there are already a lot of options and I don't think this warrants another one. I'm not seeing this be the issue you're suggesting. A line item in the changelog to show that the rendering has been corrected to better show the raw data should be enough.

@cconstantine
Copy link
Contributor

I managed to get some clear skies last night, even if the seeing wasn't great. Here's some screenshots of the new render algorithm from my Orion 8" f/3.9 with an oag.

Screenshot_20230616_004150
Screenshot_20230615_214344
Screenshot_20230615_214006

@cconstantine
Copy link
Contributor

I've had a few nights of good seeing. Here's a screenshot of what that looks like with my equipment.

After using this build for a few days I've found that I strongly prefer this new rendering mode.

Screenshot_20230621_131251

@bwdev01
Copy link
Contributor

bwdev01 commented Jun 22, 2023 via email

@jmodrako
Copy link

Guys, does it affect a guiding in any way?

@alexhelms
Copy link
Contributor Author

Guys, does it affect a guiding in any way?

No it does not, it is just the image displayed to the user.

@bwdev01
Copy link
Contributor

bwdev01 commented Jun 26, 2023 via email

@agalasso
Copy link
Contributor

fixed by #1082

thanks for the PR and for pointing out the issue!

@agalasso agalasso closed this Jul 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@bwdev01 bwdev01 bwdev01 left review comments

@agalasso agalasso agalasso approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@alexhelms @bwdev01 @cconstantine @agalasso @jmodrako