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.

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

Open
sbarber2 opened this issue Oct 18, 2024 · 5 comments
Open

coordinate system mismatch: line graphs y axis flipped #601

sbarber2 opened this issue Oct 18, 2024 · 5 comments
Assignees
Milestone

Comments

@sbarber2
Copy link
Contributor

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?

@sbarber2 sbarber2 self-assigned this Oct 18, 2024
@sbarber2 sbarber2 added bug Something isn't working high priority and removed bug Something isn't working labels Oct 18, 2024
@sbarber2
Copy link
Contributor Author

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.

@simsong
Copy link
Member

simsong commented Oct 18, 2024 via email

@sbarber2
Copy link
Contributor Author

sbarber2 commented Oct 19, 2024

we should never use [flipped coordinate systems] in our application.

And yet we have been and we do:

  • Marker location values are stored and displayed to the user as flipped coordinates
  • Tracepoint x,y values are always internally represented in 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.

@sbarber2 sbarber2 changed the title line graphs y axis flipped coordinate system mismatch: line graphs y axis flipped Oct 19, 2024
@simsong
Copy link
Member

simsong commented Oct 19, 2024 via email

@sbarber2 sbarber2 added this to the Dec2024 milestone Oct 25, 2024
@sbarber2
Copy link
Contributor Author

sbarber2 commented Oct 26, 2024

@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.

@sbarber2 sbarber2 modified the milestones: Dec2024, Nov2024 Oct 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants