Number of points should be capped at line length

[psobolewskiPhD]

trafficstars

At first I didn't 'get' what number of points did. But now I see it, it's the plotting points. However, if the line length is less than the number of points, default 100, then artifacts are produced: y-values are just duplicated to 'fill' the empty points, so those flat sections aren't real.

Here's the actual data with Num points = to actual number of pixels measured. Careful inspection of the image layer confirms that this is the correct plot, not the one above for 100 points. Number of points should thus cap at the number of pixels of the line, the number of actual data points. I can understand downsampling the plot in the case of long lines and many points, such that less points are plotted than measured, but the other direction is definitely not correct. BTW Perhaps downsampling is a better way of conveying what 'Number of points' is supposed to do?

[haesleinhuepf]

I see your point @psobolewskiPhD. What would you think of solving the interpolation problem (#2) so that these artifacts disappear?

[psobolewskiPhD]

So you want to estimate the extra points when (nr points) > (nr of pixels)? So essentially you want to upscale the data (pixels) to match the number of points in the plot? When would this be desired vs. just plotting the data?

I mean there's all sorts of curve fitting techniques, like LOESS & splines, that can draw nice smooth curves through data, but is that something that should be in the data viewer? I think that's something one could apply to the exported data in the program of their choice. But, if you do want to implement something like that, I think it should be an extra option that plots the curve onto the data. At least for me this is a tool to inspect the data in a helpful manner, so preserving the fidelity of the data is crucial. (As I said above, for me downsampling to plot is OK, because the points are still representing actual pixels in the image.)

Edit: I guess in the end it depends on the use case and how advanced you want the plugin. I think the more advanced options should be that, options, and by default the plot should present the data, so no downsampling or upscaling. Plot points = pixels.

[haesleinhuepf]

Plot points = pixels.

What if the line does not align parallel with the pixel grid?

[haesleinhuepf]

Btw @psobolewskiPhD , this project is open for contributions. Feel free to build an option in the dialog here: https://github.com/haesleinhuepf/napari-plot-profile/blob/main/napari_plot_profile/_dock_widget.py#L46

And compute step length according to the option here if you like: https://github.com/haesleinhuepf/napari-plot-profile/blob/main/napari_plot_profile/_dock_widget.py#L228

I bet there are also users who would like to measure intensity just every 5 micron for example 😉

[psobolewskiPhD]

Regarding your first question, you mean when our lovely Shape vector line overlaps multiple pixels because it's at an angle and doesn't obey the pixel grid? So this is indeed a case where some manipulation is needed. I think it's better to put my thoughts in the other issue #2

I do agree that downsampling can be useful, but just honestly can't see a case where I would want to upsample on the plot only (which is what number > line length does).

[haesleinhuepf]

but just honestly can't see a case where I would want to upsample on the plot only (which is what number > line length does).

In case you plot intensity along two images with different pixel size that's quite handy. E.g. PET-CT imaging

[psobolewskiPhD]

You're always thinking big! Yes, of course if your "channels" are physically the same but with different scales so different pixel sizes then you need could something about that too to make a nicer plot. I'm not sure it's totally needed and again would rather it not be the default. I see no issue with one plot being sparser than the other, just showing the measurements for the given physical distance, with no interpolation. The data is the data after all, but someone may prefer to have them look more matched—which does sort of imply the resolution of the modalities was the same...

[haesleinhuepf]

Sure @psobolewskiPhD, like mentioned above, this project is open for contributions. Just file a pull-request with a user interface with more options. I don't insist in the current way of plotting as default, but I like the functionality :-)