Posted by
Wayne Rasband-2 on
Mar 14, 2019; 5:01pm
URL: http://imagej.273.s1.nabble.com/Add-data-labels-within-the-Plot-lists-tp5021900p5021902.html
> On Mar 14, 2019, at 10:10 AM, Michael Schmid <
[hidden email]> wrote:
>
> Hi Philippe,
>
> yes, I agree it would be nice to have nicer headings when listing data!
> Before doing this, there are a few issues to think about:
>
> (1) Plot.getResultsTable() is a public method; so there will be plugins and JavaScript/Python/etc. code that rely on the current column header names. We have to keep it compatible, so it has to be a new method like
> Plot.getResultsTable(boolean writeFirstXColumn,
> boolean useVariableLabelsAsColumnHeadings)
> and the current getResultsTable(boolean writeFirstXColumn) has to be mapped to
> Plot.getResultsTable(writeFirstXColumn, false)
It would be better to have a new Plot.getResultsTableWithLabels() method that avoids mysterious boolean arguments that make the code hard to understand.
> (2) Up to now, ResultsTable headings are single words that follow variable name syntax. The "Apply Macro" of ResultsTables can work around this limitation. We have to check whether having arbitrary names can cause problems elsewhere.
>
> @Wayne: are you aware of any limitation in this respect?
Labels with spaces and special characters might be a problem. Plot.getResultsTableWithLabels() could replace them with underscores.
> (3) We have to take care of duplicate labels in the legend (which is allowed). Column headings in a ResultsTable must be unique.
>
> (4) I guess it would be best to have the x name from the x axis label and the y name from the legend (name of the data set), but what to do in case of multiple x columns? "x_datasetName"?
>
> (5) Plot.add(type, xValues, yValues, datasetName) :
> In Java, we have already
> addPoints(float[] xValues, float[] yValues, float[] yErrorBars, int shape, String label)
> where "label" is the name of the data set (it will go into the legend).
It would be best to have a single new method like Plot.setLabel(label) that sets the label of the last object added, and not add an string argument to the many existing methods that draw objects.
-wayne
> In Plot.java, we have more than half a dozen other methods to add data (different data formats float[], double[], ArrayList; without error bars, without x values, String or integer for the shape=symbol).
> It would be a bit much to duplicate them all, adding versions with a label.
> I think it would be more economical to have something like setLastDataSetLabel(String label).
> For adding the macro function, we would need to add to Plot.java only one more:
> Plot.add(String type, double[] xvalues, double[] yvalues, String labels)
>
> --
>
> The macro language already has a function
> Plot.setLegend("label1\tlabel2...", "options")
> which is translated to Java
> Plot.addLegend(String labels, String options)
> and there is the Java method
> Plot.setLegend(String labels, int flags)
> where flags=0 just adds the labels (tab- or linefeed-delimited) without showing the legend.
>
> Is your suggestion of Plot.setLegend() meant as a macro function to hide the legend? We could simply add a "hide" or "off" keyword to the options of
> Plot.addLegend(String labels, String options)
> and the "hide" or "off" would translate to flags=0.
>
>
> Best,
>
> Michael
> ________________________________________________________________
>
> On 14.03.19 14:14, Philippe CARL wrote:
>> Dear all (probably mostly Michael and/or Wayne),
>> What do you think about adding labels for the data within the plots so that
>> when you list the plot data there is the possibility to not anymore read: X0
>> Y0, Y1,… but instead attributed data names.
>> This could for example be done by extending the "Plot.add(type, xValues,
>> yValues)" method by something like "Plot.add(type, xValues, yValues, "Data
>> name")".
>> And a method "Plot.setLegend()" could as well be added.
>> Indeed, in the case there is only 1 to 3 data sets the way the code is now
>> is in not an issue, but with more data it becomes easily difficult to
>> understand and interpret the listed data.
>> Also do you see any issue which could limit or prohibit such an update?
>> If not I could generate the needed code and submit it to you guys for
>> validation.
>> Bien cordialement,
>> Philippe
>> Philippe CARL
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html