The current code in master asks about inverting wave front when first started.

[githubdoe]

I have stored wave fronts that are not inverted and match the sign of the desired conic. Yet when just started and loading that wave front DFTFringe says it may be inverted and give me the invert options dialog. It should not do that. Why does it?

[atsju]

Maybe convert this to an issue ?
@gr5 correct me if I'm wrong but this this dialog should only pop on first potentially inverted wavefront after opening DFTFringe.
If there is no doubt on invertion, it should probably NOT pop.

[gr5]

That's on purpose. I made it so that DFTF always asks on the first wavefront no matter what. Because...

Let's say the conic is -1 and the null is only 1/100 wave (-0.01). What do you do now? There may be enough noise in the measurement to get it wrong.

Let's say the person is making a parabola but they haven't started parabolizing and they unwittingly have conic at -1 and null is -.5. Let's say the wavefront SA is at -0.01. Should DFTF not ask?

So if we are going to just assume "conic" (the first option) on launch of DFTF we need to also add some kind of threshold and more complicated logic. Something like:

If conic is within 1/10 wave of 0 OR if mirror SA is within 1/10 wave of 0 then always ask for first wavefront after launch of DFTF. If both are farther from 0 than 1/10 wave then go for it and assume they want the "conic" method.

However I've seen some pretty significant SA when there are lots of air currents, particularly on larger mirrors (>12 inches). My 6 inch mirror always has the correct SA no matter how bad air currents are within about 1/15 wave. I think because the "air blobs" are large enough that they don't affect SA on my 6 inch test mirror.

So do we also need to have a larger thresholds for larger mirrors?

I thought it best to always ask on launch.

I could be convinced to use some kind of threshold. Maybe 1/10 wave for 6 inch and smaller and 1/4 wave for 12 inch and larger. Something like that.

Another thing to consider. If we don't ask on the first wavefront because it matches conic, do we still not ask on another wavefront where they are backwards? To me if we aren't asking on the first then we shouldn't ask on others as long as they are all over the mentioned threshold.

Instead it's much simpler to just ask on the first wavefront no matter what. People can certainly choose the manual method and they won't be asked until the restart DFTF.

[githubdoe]

I still like my original method. Only ask when there appears to be an inversion. Don't ever say there appears to be an inversion when there is not one. That is just confusing the whole thing.

[githubdoe]

I have never seen SA change due to air currents. But I suppose it might. But I never have seen it. I have very bad air currents after first test while polishing. But SA is good. I don't use a tunnel these days either but fast camera and a few igrams works fine.

Worst case is disable on start up based on preference in settings. But otherwise I hate what it does now. It is so annoying. I'm sure Jan will not like it.

[githubdoe]

Another reason I don't like it is when a new user first opens DFTFringe perhaps just to see what it is they get a complex dialog that requires them to think about a task the may not want to or know anything about before they can continue.

[githubdoe]

So if you must then the limit would be only display it if they have set the desired conic to 0. Don't worry about tiny values that is a very limited case where more than likely that is never set. The standard use cases for DFTFringe are conics of 0 and -1.

[githubdoe]

I actually never use 0 but instead use .00001 so I get the best fit conic to show and also know when the conic inverts. So once again I don't like the idea of opening that dialog within a small range of 0.

[gr5]

1. Why is it such a pain? It only asks you one time per launch of DFTF?

Don't ever say there appears to be an inversion when there is not one.

I don't say that. Here's a screen shot

Another reason I don't like it is when a new user first opens DFTFringe perhaps just to see what it is they get a complex dialog that requires them to think about a task the may not want to or know anything about before they can continue.

But it is complicated and many people get it completely wrong. I get regular calls from a guy in Colorado who has used the app maybe 30 times on his mirror and after that he went back to a sphere and didn't understand that he had to do something different. He had entered -1 in the mirror config like a year ago. This is on an older version where it would ask if he wanted to invert and he just always hit "yes". There's no clear explanation to new users. And even users who have used it dozens of times may have never understood what is going on with the auto-invert feature.

[atsju]

I don't say that. Here's a screen shot

It actually says "your wavefront may be inverted". When reading this, I understand like the historical way of doing. Tool detected that THIS wavefront may be inverted.

[gr5]

I actually never use 0 but instead use .00001 s

If I did make it automatically do "match conic if both null and SA are > .1" then you would still only have to click the "match conic" button once per launch.

If you process 50 igrams in automatic mode, it will only ask on the first one.

[gr5]

Also if you are processing one igram "the old way" it took one click 50% of the time to say "yes". And if you process 2 igrams you still have to do one click 75% of the time. and so on. With "the new way" you have to do only one single click but 100% of the time.

I propose a compromise:

I can add something to the "configuration preferences" when, if checked, it just always defaults to "match conic". And by default that is off for newbies. And it won't default to "match conic" if the conic is zero but will default to that if the conic is anything other than zero (such as .00001).

[githubdoe]

"It says your wave front may be inverted" when there is no reason for it to say that or even think it.

I start DFTFringe many times while in my testing with the laptop sitting precariously on my lap while adjusting the Bath. Many times without the mouse. Then I have to hit a an extra key. It is very annoying. At first I thought I must have saved the wave front with it inverted. Then eventually I realized I would never save an inverted wave front.

[githubdoe]

No to an y pressing the button when it is not needed. The only thing I would accept is a way to display that using preferences. It must never default to asking when the conic is close to 0 but matching the sign if the preference is set to matchConic at startup and it matches.

When a wavefront is loaded from a file it probably should never ask in the first place I think. That is what triggered my comment. However it probably is way to complicated to implement that.

I like the new dialog and it's options. I don't like that it pops up at first use when it is not needed. It is fine for it to pop up on any analysis first or otherwise when the wave front may be inverted and it can not decide. That is what the old one did.

[gr5]

Well clearly there should be shortcut keys. I agree to that.

I am pretty busy this weekend but I'll reread your messages above and think about this some more later.

[githubdoe]

The other issue I have with it asking when there was no reason to ask is it requires the user to think about why it might be asking saying that the wave front may be inverted. That may be a decision they are not capable of answering since all they were doing is loading a saved wave front. Does it also happen when creating a wave front using the simulate menu? If so there too that would be a puzzle.

[githubdoe]

Shortcut key? For what? That is just another form of extra user interaction and not addressing my original objection. That objection is a dialog pops up suggesting that a wave front may be inverted when it is clearly not the case. DFTFringe has turned stupid when before it was smart for many of the common use cases.

[githubdoe]

I said something wrong. The original never inverted anything but did always ask if the conic did not match. Then if you said invert it would invert till restart.

That is the default it should always start with. So really I want it to be manual and ask if the conic does not match. Then pop up the dialog for the user to decide if it should stay in manual and always ask or instead invert on one of the other selectable conditions.

[atsju]

I think this topic is subtle and easy to misunderstand, especially given the legacy behavior and the fact that we’re working asynchronously across time zones. From the recent discussions, it’s clear there are different interpretations of when and why the popup should appear — and that it’s confusing for users without deeper context.

Rather than iterating on dialogs and risking multiple rounds of rework, I suggest we first align explicitly on what problem we are solving and what assumptions we are making.

Since a live meeting is impossible, I drafted a short, async-friendly process focused on clarifying the problem and constraints before discussing solutions.

I used ChatGPT as a writing and structuring aid to make the process explicit and readable, but the intent is for us to review, challenge, and adapt it together.

https://docs.google.com/document/d/1SdY3obgTb-U6kOoNFiKV7FDgcaWRYMSTURTQrel9iFE/edit?usp=sharing

If you’re okay with this approach, I can share a work document with editor access so we can iterate on it collaboratively.

[gr5]

Aren't these 2 things the same thing?

[gr5]

I particularly like the part that says "how should DFTFringe choose to auto invert" as I didn't realize the old wording could be taken to mean "I think your wavefront is inverted and needs fixing", but I can imagine that people would interpret it that way after that being pointed out to me.

The old text said "Wavefront seems inverted". I did not intend the new dialog (which said "wavefront may be inverted") to imply the wavefront appeared to be inverted.

[gr5]

@atsju - I'm not sure I want to spend just as much time learning a process versus spending that time thinking about possible improvements DFTF. But it would be nice to write up the requirements. My test cases include new users and experienced users and mirrors close to spheres and mirrors far from spheres. Also power users who want to minimize mouse clicks.

[atsju]

The process document is quite long but the process is just:

• explicit constraints
• technical requirements
• solution proposals
  Still interesting to read it all in my opinion. There are some points that we not always think about.

I have a better idea of constraints now. Let me start the document and I will share it for review be email to both of you. If we are as aligned as we think, review should be fast.

[gr5]

In the current dialog it says "I'll invert...". I have always worried that people might think "I" is DFTFringe but I intended "I" to mean the user. Maybe it should say "the user will invert...".

I had hoped that the word "manual" would imply that it is the user doing the deciding instead of "automatic" which would be DFTF doing the deciding.

[gr5]

I'll write up some requirements and convenience ideas including these convenience ideas below.

conveniences are not requirements and must not violate requirements so they might need further fleshing out before becoming "features".

• try not to ask anything about inversion for wavefronts loaded from a file (versus freshly processed)
• When both null and SA of wavefront are over a threshold auto-invert

[githubdoe]

I think I already specified the requirements in one of my last posts. Here is the synopsis once again.

Here it is again:

**_So to recap my current thinking.

There are two features here.

DFTFringe recognizing when a wave front may be inverted. There are several ways it can but some conditions where it can't.
What to do when the wave front is recognized as being inverted.
You have covered case 1 well and case 2. mostly.

The issues are when to ask and when to invert without asking.

I say the default is to never ask unless the conic does not match. If the desired conic is 0 then it is ok to ask on startup.

Also add an additional option to always ask if it should be inverted when it does not match the criteria.

Now some users might like an option to save that when to ask configuration so that it does not revert to match conic on startup. But that would be an feature enhancement._

Then to respond to Georges question:

George yes those are the same but you don't have an equivalent of "ask but don't invert" which may be better stated as warn and ask to invert.

TO summarize again:

DFTFringe could have these three states when a wave front might be inverted.

1. Do nothing. Let the user beware. Currently the "Manual" setting.
2. Ask if it should invert (that is warn the user that it suspects the wave front is inverted and not just on the first one.
3. Ask and then preform auto there after.

[gr5]

I think you are still not taking into account people who are testing a spherical mirror for the first time but put in -1 for the conic because they will be making it into a parabola "soon". Maybe that could be fixed by more instruction somewhere or maybe by something that only happens the first time your run the program (as determined by the registry) or maybe it's something that you can check a box to have it stop asking in certain cases. Or maybe a "novice mode" for DFTF. I haven't thought about this much.

I also don't understand why you would want to warn people repeatedly and ask them if they should invert every time it "looks" inverted but not if it looks correct. What is the use case for that? How is this better than just manual mode? I'd like to understand the requirements. Is this somehow related to loading wavefront files (versus processing igrams)? If so maybe we can handle wavefront files differently.

[githubdoe]

When both null and SA of wavefront are over a threshold auto-invert when enabled.

However instead of talking about null and SA instead talk about when criteria are met because you already have other criteria than just that.

[githubdoe]

Manual mode is not good for a Novice. They need some help like you said. However there are cases when polishing near a sphere where the sign really does change so auto does not work either.

So they should be warned on each one and not be in auto invert.

So you see I am taking the novice and your use case into account. That was the purpose of that. The issue then is how to teach them about that mode. Yet DFTFringe is not a teaching tool. I would put it in the help where one would talk about why invert can happen or perhaps on first ever startup asking if they want pro or novice mode. Then in novice mode nag them with the dialog.

[gr5]

Yet DFTFringe is not a teaching tool.

Ha! This is an important point. Maybe it should be? I don't know. I love to teach and help people so maybe I'm putting too much thought into that, lol. But this is a good point: DFTF shouldn't necessarily teach you about why the wavefront may be inverted. Just like it doesn't currently teach you about where to put the null filter (the blue circle). It's just that I've seen a lot of "noobs" mess this step up. Badly. I guess it's a good thing that by the time they get to a parabolic mirror they are unlikely to mess this step up in current and older versions.

You give me more things to think about in your posts above.

Also currently it pops up the dialog for simulated wavefronts (you mentioned this above) and I don't think it should. I could characterize wavefronts into 3 categories as we enter the auto-invert step (but before we look at user preferences and before we look at conic or current S.A.)

• wavefront has 50% of being inverted (all wavefronts created from an igram)
• wavefront has a very small chance of being inverted (loaded from a file)
• wavefront has no chance of being inverted (simulated wavefront)

We can and probably should have different behavior for the 3 situations.

I think auto-invert step should never pop up for simulated wavefronts and only pop up for "loaded from a file" wavefronts if we are really sure something is wonky. And it should say something like "this is surprising - the wavefront from a file looks like it's inverted" (or something similar) and only bring this up if we are pretty sure and regardless of what settings they did earlier. Similar to your old dialog.

[atsju]

I used LLM to clarify and lay out my understanding. Please review my understanding so that we are all aligned

✅ Main Goal

Ensure users always see the correct wavefront sign without unnecessary interruptions.

---

❗ Observed Problems

• A popup appears on the first wavefront load after app launch, even when the orientation is already correct.
• The popup appears without real ambiguity in most cases.
• It interrupts workflows, especially during repeated testing or batch loading.
• New users face a confusing dialog before they understand what inversion means.
• Experienced users find the popup annoying and redundant.

🧩 Underlying Issue

The inversion popup is triggered based on application startup,
not on the actual ambiguity of the wavefront orientation.

---

📌 Use Cases Affected

• Loading a correctly saved wavefront or simulated wavefronts → popup appears.
• Automated or repeated loads → popup slows workflow needlessly.
• Beginners → unclear why inversion is being asked at all.
• Ambiguous cases → legitimate scenarios, but current trigger logic does not use ambiguity detection.

👥 Who Is Impacted

• Beginners: confusion and uncertainty
• Experienced users: frustration and workflow interruption
• Power users: slowed down by extra clicks

---

🎯 Success Criteria

We consider the problem solved when:

• The popup appears only when inversion is truly ambiguous.
• Correct wavefronts never trigger the popup.
• Users can see or confirm inversion state without guessing.
• High‑frequency workflows run without any unnecessary interruptions.

---

---

✅ Proposed solution

• Do never ask on loading wavefronts or simulated wavefronts → We suppose they have been stored or generated correctly
• what about loading igrams where sign can be wrong ?
  • My idea:
    • default to match conic
    • add some verbatim in right menu to explain "this wavefront was taken from inside/outside focus + a radar with tilt direction"
      • requires to add a menu to give user Bath configuration (mirror left or right) that you set once for all
  • What it brings:
    • easier for user to tell if wavefront is incorrectly inverted or not (you remember the tilt direction during pictures)
    • we could have a red warning text if focus inside/outside changed from previous picture/wavefront
  • Additionally:
    • a dropdown in batchigram that lets you select from auto match conic (by default), manual, inside focus, outside focus. this makes sense as inside/outside focus really only makes sense when processing batches. "Manual" is not even interesting because if DFTFringe gets sign good more than 50% of the time, using auto+doing a manual pass is faster than full manual.

[githubdoe]

I had several cases where the saved wave front would have an inverted sign for SA (that was true and not a mistake) when nearly a sphere. That is because the surface became oblate. While it was large oblate that was obvious to me but not to DFTFringe in auto invert on conic mode. It would invert when I did not want it to. Then when nearly a sphere again the wave front became ambigous because the analysis might invert because it analyzed the wrong side of the wave front. I would have liked a mode it does not have. The Warn mode.

That is one use case for Warn.

You are drifting away from the discussion about what I think is the solution to your problem.

Let's talk about my solution first. What you don't understand about it if any.

[atsju]

Loading wft shall not invert wavefront and not ask about it. As you said , sign might look wrong but it's correctly saved by you. Correct ?

I'm not sure if I'm drifting to my need or if it's something else, but I don't feel like we need a popup "warn". Why not using auto and give more information to user to easily manually invert wft that are wrong ? Probably I missed something. => Kindly explain how DFTFringe chooses sign when you are not in auto mode. I was thinking it's a simple 50/50 chance and there is no rule.

From my understanding the main requirement is "ensure user get correct sign". Having a popup is one solution but maybe not the only one. More often than not it breaks the analysis flow when auto would be just fine.

[gr5]

I'm confused about the "ask". What is the "ask"? Is this large 4 button dialog the "ask" or is it a simpler "It looks like this is inverted..." warning?

I was expecting that after you choose one of these 4 things the dialog goes away until restarting. Why would you want the dialog to come up a second time? Or are these 3 radio buttons going into the registry? The text just below the 3 radio buttons implies that it does not go into the registry.

It sounds like we have consensus that simulations and loaded wavefronts should not be inverted and should bypass this process. Please clarify if I missed something -- maybe dale prefers a warning in these cases.

I guess I'm confused about the whole "ask" aka "warn the user" feature for a freshly processed igram. 50% of the time, DFTF will pick the correct lobe and the wavefront won't need inverting and 50% of the time it will need inverting. So why are we randomly warning the user only 50% of the time depending if DFTF randomly picked the correct lobe? Should we warn 100% of the time? Again - why warn the user only 50% of the time, randomly?

Please explain these radio buttons better. I also still think the 3rd choice is redundant as "manual" does the same thing so we could get rid of one or the other, right? Or is one stored in the registry and the other is not?

On another note I have a new idea to add to an older idea. The older idea:
I think everyone likes the idea that if null and SA are both > (some threshold) it just auto inverts. (except maybe the radio buttons affect this as I don't understand the radio buttons)
The new idea:
I'd like to propose an additional similar feature: if conic is non zero but very small e.g. abs(conic)< 0.01 then that implies the user is an expert and we just automatically do the "conic" option. (again, maybe the radio buttons affect this)

[atsju]

I strongly agree with first part. You put finger on what we don't understand

Only last §, I don't think we should rely on a value to get that user is expert. Many things are already inaccessible when you don't know. Make things into advanced settings menu if you want but do it explicitly

[githubdoe]

George. Lets talk on the phone. Set up a time. Atjsu let George and I discuss this. I'm sorry you just don't understand the principles of the issue and trying to explain them to you just gets in the way of my conversation with George.

[atsju]

Please share a short written summary on the issue and the proposed solution after your call so I can understand.

[gr5]

I'm not ready to summarize what we talked about. I need a break and I'll think about it all tomorrow. The conic<.01 thing is out though so don't worry about that.