-
Notifications
You must be signed in to change notification settings - Fork 2
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.
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
coordinate system mismatch: line graphs y axis flipped #601
Comments
Heh, I can't tell yet if we're fixing a bug or changing how features work with this Issue. Basically, this happened because we had a loose specification and no tests. |
We call this a “flipped coordinate system.”
In general, computers use flipped coordinate systems for screens and printouts. However, they are confusing for mathematical applications, so we should never use them in our application.
… On Oct 18, 2024, at 11:41 AM, Steve Barber ***@***.***> wrote:
So, it turns out that in the x, y vs time line graphs that the y axis values go down as the marked points move up in physical space, and vice versa.
This happens because in video frames the origin point (0,0) is the upper left corner of the frame.
However, it is extremely likely that the vast, vast majority of botany-oriented users of these videos are going to expect that (0,0) is the lower left corner of the frame. For example, Eric and JoAnn were very surprised to see the y values being graphed in the opposite direction of the way the plant was moving in physical space, where we think of height values increasing as we go, well, higher.
It's easy enough to flip the direction of the graph's y-axis. That is, we multiply y * -1 before we feed the data to the graph.
That said, does this (literal) difference in perspective mean that we should also be changing how the tracked data values are communicated to the user, for example in the CSV download files. That is, is it OK for the y pixel values to be going down while the y mm values are going up? Should we report the pixel values as if the frame origin were lower-left, as well?
What's the desired result here?
—
Reply to this email directly, view it on GitHub <#601>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMFHLGA66KUBDLRB4P745LZ4ET4HAVCNFSM6AAAAABQGG56IGVHI2DSMVQWIX3LMV43ASLTON2WKOZSGU4TOOBVGY3DAMI>.
You are receiving this because you are subscribed to this thread.
|
And yet we have been and we do:
So, I think we have to decide about how and where to translate between the flipped movie frame coordinate system (because all the graphics and video libraries use that system), and the non-flipped user presentation coordinate system. |
Well, it is fine to just flip them when you show them to the user. You just
have to be careful about it.
Back on my NeXT machine, it was a system property, whether a View was
flipped or not. It still is…
https://developer.apple.com/documentation/appkit/nsview/1483532-isflipped
https://developer.apple.com/documentation/appkit/nsgraphicscontext/1531568-isflipped
…On Sat, Oct 19, 2024 at 9:48 AM Steve Barber ***@***.***> wrote:
we should never use [flipped coordinate systems] in our application.
And yet we have been and we do:
- Marker positions are stored and displayed to the user as flipped
coordinates
- Tracepoint x,y values are saved to the DB as flipped coordinates
- The "Download CSV" csv files contain flipped coordinates
- The *2 x,y vs t* line graphs use and display flipped coordinates
So, I think we have to decide about how and where to translate between the
flipped movie frame coordinate system (because all the graphics and video
libraries use that system), and the non-flipped user presentation
coordinate system.
—
Reply to this email directly, view it on GitHub
<#601 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAMFHLHNUQ34H6V2L45OMKLZ4JPIFAVCNFSM6AAAAABQGG56IGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRTHA3TKMBZHE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
@ericdbrenner and I met yesterday and had a discussion about this topic. His take is that presenting the flipped-coordinate system values is never going to be interesting, or even clear, to Plant Tracer users, and that the user's perspective is that the origin point of the video frames will be the lower left corner of the the frame, and that any graphs and charts use this coordinate system. He further suggests the downloaded tracepoint data contain movement trace values that are relative to the position of the tracked markers in frame 0 of the analysis, and that the relative position of the frame 0 is (0,0), as we have already implemented in the x vs t and y vs t line graphs. Thinking this through afterwards, it's not that simple, as there are several places where we present/expose marker location data where having both the lower left corner and the position of a marker in frame 0 both being (0,0) are going to conflict. Plus, leaving the calibration markers aside for the moment, we already have partial support for multiple markers (for example, Apex and Apex2 for tracking two different plants' apexes in one movie or Apex and InflectionPoint for a single plant gravitropism analysis) and of course the interesting movement calculations are going to change for different types of movement (circumnutation compared to gravitropism, for example). So, I guess we are not done thinking this through. |
So, it turns out that in the x, y vs time line graphs that the y axis values go down as the marked points move up in physical space, and vice versa.
This happens because in video frames the origin point (0,0) is the upper left corner of the frame.
However, it is extremely likely that the vast, vast majority of botany-oriented users of these videos are going to expect that (0,0) is the lower left corner of the frame. For example, Eric and JoAnn were very surprised to see the y values being graphed in the opposite direction of the way the plant was moving in physical space, where we think of height values increasing as we go, well, higher.
It's easy enough to flip the direction of the graph's y-axis. That is, we multiply y * -1 before we feed the data to the graph.
That said, does this (literal) difference in perspective mean that we should also be changing how the tracked data values are communicated to the user, for example in the CSV download files. That is, is it OK for the y pixel values to be going down while the y mm values are going up? Should we report the pixel values as if the frame origin were lower-left, as well?
What's the desired result here?
The text was updated successfully, but these errors were encountered: