Importing csv with 2.0 beta

[Willie]

Sometimes I want to add a column using a spreadsheet.  Then I export the spreadsheet to csv format and import it into Astro ImageJ.  With AIJ 1.0 this worked as expected.  However, in 2.0 the data is rounded to three decimal places.  Has this been seen by anyone else?  I am going to try and attach two screenshots showing the results of each import.



Then the same file imported using AIJ2.0



Thanks,

[karenacollins]

Willie, sorry for the trouble with the .csv file format. I tried a .csv file here, and I have not been able to duplicate the problem (all 6 decimal places were retained). I sometimes add new columns using a spreadsheet, but I always have to manually set the number format to use 6 decimal places for all data columns after I open the original file, since it seems to default to 3 places. If you did set the number format to 6 decimal places before you saved the .csv file, could you open the .csv file with a text editor of your choice, and verify that all 6 decimal digits are saved into the .csv file? If they are, could you send me a portion of your file to karenDOTcollinsATinsightbbDOTcom so I can test with it here. Also, if you are able to save from the spreadsheet as a tab-delimited file, could you try that and see if you have the same problem? As a final comment, I am adding a feature to the AIJ plot facility to allow users to save a plotted dataset (i.e. after magnitude conversion, operations, normalization(another new feature), etc) back to the table as a new data column. My goal is to avoid the need to go into a spreadsheet to tweak datasets. Is there a specific calculation on the data that would prevent you from having to use a spreadsheet program to manipulate the data? If it is a simple enough and generally useful to the typical AIJ user, I may add it to the final AIJ 2.0 release.

[Willie]

karenacollins wrote

I tried a .csv file here, and I have not been able to duplicate the problem (all 6 decimal places were retained). . . . it seems to default to 3 places. If you did set the number format to 6 decimal places before you saved the .csv file, could you open the .csv file with a text editor of your choice, and verify that all 6 decimal digits are saved into the .csv file?

Thank you for the thorough response.  It does seem to default to 3 places.  My copy of 1.0 does not do that.  I had to change the decimal place setting after opening the file.  I had not tried that.  I just checked that I had asked for 8 decimal places and there were that many in the original data.  After asking for 6 places it switched to 6 places.  Then when I asked for 8 places it gave me 8.

karenacollins wrote

As a final comment, I am adding a feature to the AIJ plot facility . . . My goal is to avoid the need to go into a spreadsheet to tweak datasets. Is there a specific calculation on the data that would prevent you from having to use a spreadsheet program to manipulate the data? If it is a simple enough and generally useful to the typical AIJ user, I may add it to the final AIJ 2.0 release.

I like the idea of not having to use a spreadsheet.  Here we have a new camera and custom software is being written to drive it in the way the PI wants.  Our primary package calculates JULIAN and adds a header for each file with that info.  So ImageJ has no problem using that header.

The new software package creates two headers called UT_DATE & UT_TIME.  For some reason ImageJ returns NaN in those columns.  Therefore I have not figured out how to calculate JD for the x axis.  I use hedit to export the times of each file and then paste them into a new column on the xls file.  Then I paste in a formula to all the JD-240000 cells and export it to csv to reopen with multi plot.  I am getting pretty fast at doing this, but would prefer to find an alternative.

Here is a sample of the headers as they are written.

UT_DATE = '2012-08-30'         / Exposure start date (GPS)                      
UT_TIME = '07:24:00'           / Exposure start time (GPS)                      

I am not sure why they do not import into ImageJ.

Thanks again,