Results to Excel Column Exception

Hi all,

I apologize if this has been answered already, but I’m finding myself unable to use the “Read to Excel” plugin properly as a result of an exception raised:

java.lang.IllegalArgumentException: Column not defined: 0
at ij.measure.ResultsTable.getStringValue(
at ij.IJ.runUserPlugIn(
at ij.IJ.runPlugIn(
at ij.Executer.runCommand(

I assume this is because the first column of my results data is null (it’s just a placeholder for numbering), but I’m not sure how to rename it or whether that’ll solve the problem.

Can anyone help?


  • Jake

If you use the ImageJ macro language to generate the table recently @Wayne added Table API commands to the macro language like:

Table.set(columnName, rowIndex, value)

For more see:


Hi Bassitenor,

I noticed this about a week ago, so I am not sure if it was there when I released the last version after bkromhout ( added the cool optional parameters and the filehandling modes or if it is related to an update to the imagej api (probably the former and my shoddy real-world testing). After discovering the issue, no immediate coding solution popped into my mind or resulted in a satisfactory outcome when I tried a fix.

Line 109 is the last of this nested loop, when data is extracted from a copy of the results data:

 for (int row = 0; row < numRows; row++)
            for (int col = 0; col < numColumns; col++)
                results[row][col] = resultsTable.getStringValue(headers[col], row);

Where ‘numRows’ and ‘numColumns’ are previously defined by:

        ResultsTable resultsTable = Analyzer.getResultsTable();
        int numColumns = resultsTable.getHeadings().length;
        int numRows = resultsTable.size();
        String[] headers = resultsTable.getHeadings();

and for reasons you have already speculated, the api command ‘getStringValue’ in the extraction loop doesn’t seem to like the null. Oddly enough, in my testing last week, a native results table column can be totally empty and the export works. I also tried to introduce a null check in the loop (something like this…):

if (resultsTable.getStringValue(headers[col], row) == null) {
   resultsTable.setValue(headers[col], row, "none");

which compiled but didn’t solve the issue.

Basically, I need to do more testing and tweaking to fix this issue but I have included the above breakdown in case an easy solution pops into a more experienced mind that might be reading this.

As @Bio7 points out, in the macro you could also seed the empty results table cells with something prior to the export. Another quick alternative would be to delete the column altogether or to export using imagej’s native saveas .csv.

As I mentioned, I will have another look over the plugin for a proper fix, but if anybody else wants to suggest ideas, that’s also super.

Kind regards.

Hello again,

Bare with me here, but I have a suspicion the error you are getting is related to something else. If you have installed the plugin from bkromhout’s update site ( instead of mine ( then there is another export issue related to the imageJ api that I don’t think he has addressed yet. I logged a pull request on his github to change:

 results[row][col] = resultsTable.getStringValue(col, row);


 results[row][col] = resultsTable.getStringValue(headers[col], row);

as I noticed that former api command is accessing hidden values (not precise explanation as this is an old observation I am having to remember).

Anyway, if you are using bkromhout’s update site, could you try removing it from your updatemanager and instead try mine. This will either fix your issue, or result in my error message instead :wink: (I still have to work on my issue)

@Bio7 and @antinos,

Thanks so much for your help!

I haven’t tried Bio7’s solution, yet (I got all of these replies at once), but I suspect it would do the trick in a pinch.

Uninstalling the dated versions of Read_and_Write_Excel (and all the related jars) and replacing them with those from your site, antinos, appears to have solved the problem–I’ll post again if anything additional shows up related to the error you mentioned, but so far, so good! ^^

Thanks again,