line graphs for x and y vs time

[sbarber2]

The legacy iOS app had line charts for x and y movement in pixels or mm vs frames or time.

This issue requests the replication of that functionality in PlantTracer/webapp.

x,y vs. time graphs for both gravitropism and circumnutation in the legacy iOS app have the initial position of the apex as the origin point (0,0) of the graph, so that's how these graphs should look as well.

Sub-tasks:

• [x] Make the y axes be mm rather than pixels if Ruler markers are available
• [x] Make the graph origin the initial position of the apex
• [x] Graph axes should display the units in use.
• [x] Merge main into the working branch. @sbarber2 will help
• [x] Use the current position of Ruler markers to calculate pixel -> mm scaling, not just the position of the Ruler markers from the first frame.
• [ ] Graph layout: under the Marker table/widgets where possible. Make it reasonable on laptop, tablet, smartphone.
• [ ] DEFERRED: ~Add an input text box for the frame rate and use that to make the x axes be minutes rather than frames, when a value is present. Otherwise, the x axes are in units of frames.~

[JoAnnJuzefyk]

Replicating the legacy graphs can be done with the data we are currently collecting in CSV file? Actually, without the timestamps those graphs cannot be created.

Maybe we need another issue generated to work on getting timestamps from the movie? Graphing the rate of motion over time is essential to comparing one plant to another.

I can put together a mock up of graphs that I can come up with from data (currently collected or possible to collect). I will use Excel to create these examples. Then we can share them with Eric and Simson to consider what is feasible based on the data available and the current code to collect the data.

[simsong]

@JoAnnJuzefyk — it would be useful if you could do some experiments with LapseIt and find out if it always does the same reduction in speed, or if there are several settings that it tends to make available. Also to investigate the metadata of the lapseIt files to see if it records anything.

Timestamps can always be inferred. And the old graphs can be created with a different X axis, can't they?

[sbarber2]

The legacy app would simply use the frame # for the x axis if no frame rate is available. That's fine in the interim. Frame # can be considered just a different unit of time.

78 has a picture of the x and y vs time graphs from the legacy app, for

the gravitropism type.

Here https://github.com/Plant-Tracer/webapp/blob/main/docs/media/image29.png is a picture of the circumnutation type in case that was different.

Yes we should get further guidance from @Eric Brenner @.***> on what graphs are useful today, but these legacy ones can be a starting point for work/discussion. I recall validating these with Eric some time ago and then legacy app graphs were still basically what he is looking for.

So it's like this:

• if we don't have the pixel -> mm conversion info, we chart in pixels on the charts' y-axis. (That is, the movement in the x or y dimension in 2-D plant space.) If we do have the conversion, we chart in mm.
• if we don't have a time-lapse rate, the x-axis of the chart is in frame

  . Otherwise, it's in seconds (or minutes or hours, depending on the

  time-lapse rate and # of frames we have -- adjusting that at graph time another discussion -- for the initial work I guess minutes makes the most sense as a default).

On Wed, Jun 12, 2024 at 11:15 AM JoAnn Juzefyk @.***> wrote:

Replicating the legacy graphs can be done with the data we are currently collecting in CSV file? Actually, without the timestamps those graphs cannot be created.

Maybe we need another issue generated to work on getting timestamps from the movie? Graphing the rate of motion over time is essential to comparing one plant to another.

I can put together a mock up of graphs that I can come up with from data (currently collected or possible to collect). I will use Excel to create these examples. Then we can share them with Eric and Simson to consider what is feasible based on the data available and the current code to collect the data.

— Reply to this email directly, view it on GitHub https://github.com/Plant-Tracer/webapp/issues/425#issuecomment-2163299177, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFQOB4RHBQWRUAHV3VUEQ3ZHBQ2JAVCNFSM6AAAAABJGQHV4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRTGI4TSMJXG4 . You are receiving this because you authored the thread.Message ID: @.***>

[JoAnnJuzefyk]

The x axis could be frame number, I guess. The important issue is to be able to compare any 2 plants so the timestamp is important.

[sbarber2]

Timestamps can always be inferred. And the old graphs can be created with a different X axis, can't they?

Yes, if we have no time rates, we can use frame #s on the x axis of the graphs.

On Wed, Jun 12, 2024 at 11:58 AM Simson L. Garfinkel < @.***> wrote:

@JoAnnJuzefyk https://github.com/JoAnnJuzefyk — it would be useful if you could do some experiments with LapseIt and find out if it always does the same reduction in speed, or if there are several settings that it tends to make available. Also to investigate the metadata of the lapseIt files to see if it records anything.

Timestamps can always be inferred. And the old graphs can be created with a different X axis, can't they?

— Reply to this email directly, view it on GitHub https://github.com/Plant-Tracer/webapp/issues/425#issuecomment-2163402631, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFQOB6F6JA3UWBQP3UIMPLZHBV37AVCNFSM6AAAAABJGQHV4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRTGQYDENRTGE . You are receiving this because you authored the thread.Message ID: @.***>

[sbarber2]

The important issue is to be able to compare any 2 plants so the timestamp is important.

The most important issue is that the app produces a reasonable graph with the information we have on hand. Not to say it isn't important to use the elapsed timestamp for each frame, but as a matter of application design, we can proceed if we don't have it.

Yes, I'll make an issue to get the time rates/timestamps available in the app.

On Wed, Jun 12, 2024 at 12:06 PM JoAnn Juzefyk @.***> wrote:

The x axis could be frame number, I guess. The important issue is to be able to compare any 2 plants so the timestamp is important.

— Reply to this email directly, view it on GitHub https://github.com/Plant-Tracer/webapp/issues/425#issuecomment-2163418861, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFQOB57ZPVIWUFAA4OLNALZHBWYXAVCNFSM6AAAAABJGQHV4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRTGQYTQOBWGE . You are receiving this because you authored the thread.Message ID: @.***>

[JoAnnJuzefyk]

I am trying to code a graph on chart.js using the csv files I have already downloaded from analysis I have done.

from stack overflow: Chartjs doesn't support direct CSV files. So you have to convert it to JSON-like format. What you can do is create a server side script in php/nodejs that will convert csv to json on the go. Then give that data to chartjs

$file="1_23.csv"; $csv= file_get_contents($file); $array = array_map("str_getcsv", explode("\n", $csv)); $json = json_encode($array); print_r($json);

Can I get the data directly from a JSON? Just for a demo, what is the format of the JSON? Is the JSON used to create the csv files? Can you point to where I would find the creation of the JSON in the source code (just so I can learn a bit more about how and when the JSON is created)?

[sbarber2]

Can I get the data directly from a JSON?

I don't understand where you are going with this question; please elaborate.

Just for a demo, what is the format of the JSON?

In the example code in your comment, the JSON string's format is determined by the line that starts with $array.

Can you point to where I would find the creation of the JSON in the source code (just so I can learn a bit more about how and when the JSON is created)?

In the example above (if that's what you mean by "the source code"), the JSON string itself is created in the line that starts with $json

If you take that example and print out the results of each step (including the explode() call), I think it will become clear to you how it works.

Is the JSON used to create the csv files?

Well, in your example, it's the csv file's contents that is used to make a JSON string.

[sbarber2]

My guess without running the example code is that it works something like this:

If the contents of 1_23.csv is:

"x","y"
"1","2"
"3","4"

then the resulting JSON string will be something like:

[ {"x": "1", "y": "2"}, {"x": "3", "y": "4"}]

[simsong]

That’s what I would expect. It’s a pretty standard representation. However, it would be best to put together a small demo program.On Jun 13, 2024, at 11:48 AM, Steve Barber @.***> wrote: My guess without running the example code is that it works something like this: If the contents of 1_23.csv is: "x","y" "1","2" "3","4"

then the resulting JSON string will be something like: [ {"x": "1", "y": "2"}, {"x": "3", "y": "4"}]

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[sbarber2]

On the dev call today, Eric reminded us/clarified for us that for circumnutation graphs, at least, the starting position of the Apex should be considered the origin point of the graph (0,0) and subsequent motion tracked from that origin, positive or negative. Satisfying that bit of functionality I think can be within the scope of this issue. Editing the description accordingly.

[sbarber2]

Reconfirming that these graphs for gravitropism also had the graph origin as the initial position of the apex.

[sbarber2]

Quick status. @JoAnnJuzefyk is doing the work for this issue on the graphing-frame_number-vs-apex-x-and-y branch. As of today on this branch, the two graphs appear on the analyze page always, with no button or other control toggle them on or off as we can't get that to work well, perhaps for the same reason the Download Trackpoints button doesn't work at the moment (#471).

JoAnn's next task is to get the graphs to appear below the Marker table/CRUD affordances, which hopefully is just a matter of figuring out what HTML or CSS hacks we need.

[sbarber2]

Here's how the graphs look at the moment:

[sbarber2]

We committed a new version that uses the first frame's Apex as the graphs' origin, and also handled arbitrary "Ruler XXmm" marker labels, including have 0-N such markers. If there are at least two Rule XXmm markers, then these will be used to convert pixels to mm on the vertical axes of the graphs.

We need to make is so the graph axes display the appropriate units. Adding to task list.

[sbarber2]

I made a fix to the graph logic (real_distance was wrong).

I've also started to code up the frames per minute capture rate calculation but the way we refresh graphs needs a re-think so I've left the code there but it is hidden for now.

[sbarber2]

Here is what the graphs look like now with the first frame origin and mm calculation.

[sbarber2]

Also, in the most recent commit the axes will be labelled with the appropriate units.

[simsong]

That’s really great. Now we just need to do the 3-D.!

On Tue, Sep 24, 2024 at 5:59 PM Steve Barber @.***> wrote:

Also, in the most recent commit the axes will be labelled with the appropriate units.

— Reply to this email directly, view it on GitHub https://github.com/Plant-Tracer/webapp/issues/425#issuecomment-2372461227, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMFHLCWHWQ5252A5D3RJSDZYHOD5AVCNFSM6AAAAABJGQHV4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZSGQ3DCMRSG4 . You are receiving this because you commented.Message ID: @.***>

[sbarber2]

It occurs to me that scaling calculation for pixels -> mm currently uses the "Ruler XXmm" marker x,y positions from the first frame in the movie rather than the x,y positions of the current frame.

The calculations I think would be "more correct" if we used the Ruler marker positions from each frame. There's no reason to believe that the camera position is absolutely fixed from the beginning to the end of a time-lapse recording. This idea has been discussed before, we just haven't incorporated it into the current implementation.

I'll note that even in the circumnutation sample movie we use for testing, the x positions of the Ruler markers vary by one pixel over the course of the movie.

Adding a task for this.

[simsong]

Correct. The version that I was working on tracks the ruler for this reason. You want to recalc every frame.

On Sep 25, 2024, at 8:22 AM, Steve Barber @.***> wrote:

It occurs to me that scaling calculation for pixels -> mm currently uses the "Ruler XXmm" marker x,y positions from the first frame in the movie rather than the x,y positions of the current frame.

The calculations I think would be "more correct" if we used the Ruler marker positions from each frame. There's no reason to believe that the camera position is absolutely fixed from the beginning to the end of a time-lapse recording. This idea has been discussed before, we just haven't incorporated it into the current implementation.

I'll note that even in the circumnutation sample movie we use for testing, the x positions of the Ruler markers vary by one pixel over the course of the movie.

Adding a task for this.

— Reply to this email directly, view it on GitHub https://github.com/Plant-Tracer/webapp/issues/425#issuecomment-2373933722, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMFHLCLFYDJFFTP3D3OZILZYKTGZAVCNFSM6AAAAABJGQHV4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZTHEZTGNZSGI. You are receiving this because you commented.

[JoAnnJuzefyk]

I did mention that as a comment next to the code to calculate the scale. I can move the lines of code into the forEach() and have the scale conversion calculated on every frame.

[JoAnnJuzefyk]

I failed to get the scale for conversion from pixels to mm on all frames. I have a section (commented out, line 502) in canvas_tracer_controller.js that attempted to recalculate the scale on each frame. The branch graph_2 is up to date with main and works (on my machine).

[simsong]

Well, if it is not available on a frame, can you grab it from the previous frame?

On Sep 29, 2024, at 5:45 PM, JoAnn Juzefyk @.***> wrote:

I failed to get the scale for conversion from pixels to mm on all frames. I have a section (commented out, line 502) in canvas_tracer_controller.js that attempted to recalculate the scale on each frame. The branch graph_2 is up to date with main and works (on my machine).

— Reply to this email directly, view it on GitHub https://github.com/Plant-Tracer/webapp/issues/425#issuecomment-2381621317, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMFHLEUHEQCWBKQB6YCOQ3ZZBYF5AVCNFSM6AAAAABJGQHV4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBRGYZDCMZRG4. You are receiving this because you commented.

[sbarber2]

Hi JoAnn,

Thanks for the report. It reads like a pure status update of a work in progress, but just checking -- is there something we might assist you with here? Or are you saying you want to be done with this Issue and we should merge as is?

And you know, "failed" is such a harsh word to apply to one's efforts!

-Steve

On Sun, Sep 29, 2024 at 5:45 PM JoAnn Juzefyk @.***> wrote:

I failed to get the scale for conversion from pixels to mm on all frames. I have a section (commented out, line 502) in canvas_tracer_controller.js that attempted to recalculate the scale on each frame. The branch graph_2 is up to date with main and works (on my machine).

— Reply to this email directly, view it on GitHub https://github.com/Plant-Tracer/webapp/issues/425#issuecomment-2381621317, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFQOB7WZXPR3R2FMKAB66DZZBYF3AVCNFSM6AAAAABJGQHV4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBRGYZDCMZRG4 . You are receiving this because you were mentioned.Message ID: @.***>

[sbarber2]

Oh, apologies, I see your message to me about this elsewhere. Got it.

On Mon, Sep 30, 2024 at 9:11 AM Steve Barber @.***> wrote:

Hi JoAnn,

Thanks for the report. It reads like a pure status update of a work in progress, but just checking -- is there something we might assist you with here? Or are you saying you want to be done with this Issue and we should merge as is?

And you know, "failed" is such a harsh word to apply to one's efforts!

-Steve

On Sun, Sep 29, 2024 at 5:45 PM JoAnn Juzefyk @.***> wrote:

I failed to get the scale for conversion from pixels to mm on all frames. I have a section (commented out, line 502) in canvas_tracer_controller.js that attempted to recalculate the scale on each frame. The branch graph_2 is up to date with main and works (on my machine).

— Reply to this email directly, view it on GitHub https://github.com/Plant-Tracer/webapp/issues/425#issuecomment-2381621317, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFQOB7WZXPR3R2FMKAB66DZZBYF3AVCNFSM6AAAAABJGQHV4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBRGYZDCMZRG4 . You are receiving this because you were mentioned.Message ID: @.***>

[sbarber2]

Not sure off hand why the new per frame ruler marker code didn't work for (assuming your test markers were at 0 and 20 mm), but two quick observations:

• The per frame ruler marker code in the commit has ruler distance numbers hard-coded to 0 and 20, which is something we are going to not do.
• It's time to refactor this code so we put the determination of the start and end Ruler markers for a frame into its own function.

My QA-brain asks these questions to help ensure that the code is as robust as we can reasonably make it:

• Can the marker labels ever change throughout the course of a movie (say, through partial re-tracking)? For example, on a 200 frame movie, frames 1-100 have markers Ruler 0mm and Ruler 10mm, and frames 101-200 have markers Ruler 0mm and Ruler 11mm? (To answer my own question: yes, this can happen. I know because I just made such a tracked movie and that's what I got!)
• And if so, is that a case we want to support? (I don't see why not, the results should be valid and the calculations no more complicated. Anyway, if we re-find the start and end markers on each frame by parsing the labels as we already do for frame 0 (or is it 1? heh), then It Should Just Work.)

[sbarber2]

OK, we fixed the per frame position axis calculation.

We observed that deleting markers from a traced movie affects only the current frame of the trace points, so handling that case is not something we do well yet.

Closely related, deleting markers mid-movie could conceivably change the units we can graph mid-graph, which we don't want to support. We should default the graph back to pixels if we detect a change from mm->pixels mid-movie.

[sbarber2]

Deferring frame rate input out of this issue.

[JoAnnJuzefyk]

The scale is now a function and calculates in Frames.forEach(). The last issue is to fix the position of the canvas for the 2 graphs.