[biowolp@madison AncesTree]$ java -cp ij.jar:LSM2ZIP.jar LSMReaderFrontEnd /nfs/gs2/shared/waterston/image-series/2color/toolstest112305/lsm 112305_end1red_L1_B1_G1_R1.lsm /nfs/gs2/shared/waterston/image-series/2color/toolstest112305/lsm 112305_end1red_L1_B1_G1_R1.lsm
If we look at the command line as a space delimited series, here are the pieces.
A typical 2 color lsm file will produce 30 green channel tifs and 30 red channel tifs. The program outputs a '*' character to the terminal window (or its UI window) for each tif it creates.
[biowolp@madison AncesTree]$ java -cp .:ij.jar Zip2Tif /nfs/gs2/shared/waterston/image-series/2color/toolstest112305/zipr /nfs/gs2/shared/waterston/image-series/2color/toolstest112305/tifr 10 Zip2Tif: start: Wed Nov 30 12:35:16 PST 2005 tif exists in series proceeding anyway file count: 385 file: 112305_end1red_L1-t001-p01.zip .... Zip2Tif: end: Wed Nov 30 12:36:16 PST 2005 Zip2Tif: start: Wed Nov 30 12:35:16 PST 2005 [biowolp@madison AncesTree]$
Items 2 and 3 are the classpath input to java. You need ij.jar.
Notice that the current directory is the first item in the classpath.
Item 4 is the name of this one class application; the file Zip2Tif.class is in the
directory where this is run.
Item 5 is the path to the zip files to be converted.
Item 6 is the path to where the tif files are to be placed.
Item 7 is the highest time zip file to be converted.
This can be larger than the highest time in the directory if you
are converting everything.
For two color series, it would be necessary to run this program twice to convert both colors. However, if only StarryNite is to be run, only the green channel (zip) needs to be converted.
The output shown above gives some feeling for the time to do conversions. It seems that about 5 files are converted per second. One period is printed for every 100 files converted.
[biowolp@madison AncesTree]$ java -cp .:ij.jar Tif2Zip /nfs/gs2/shared/waterston/image-series/2color/toolstest112305/tifr 1 10 Tif2Zip.main: 3 Tif2Zip /nfs/gs2/shared/waterston/image-series/2color/toolstest112305/tifr 1 10 Wed Nov 30 13:13:21 PST 2005 baseDir: /nfs/gs2/shared/waterston/image-series/2color/toolstest112305 file count: 385 file: 112305_end1red_L1-t001-p01.tif .... end at : Wed Nov 30 13:15:13 PST 2005 start at: Wed Nov 30 13:13:21 PST 2005 count of files converted: 350 [biowolp@madison AncesTree]$If we look at the command line as a space delimited series, here are the pieces.
Items 2 and 3 are the classpath input to java. You need ij.jar.
Notice that the current directory is the first item in the classpath.
Item 4 is the name of this one class application; the file Tif2Zip.class is in the
directory where this is run.
Item 5 is the path to the tif files to be converted.
Item 6 is the first time point to be converted.
Item 7 is the last time point to be converted (can be a large number if all
tifs are to be converted).
For two color series, it would be necessary to run this program twice to convert both colors. Also note that if the tif directory is tifr then the zips will be put in zipr.
The output shown above gives some feeling for the time to do conversions. It seems that about 2 files are converted per second. One period is printed for every 100 files converted. Notice that Tif2Zip is only half as fast as Zip2Tif.
It can be run with a command line like:
java -cp SNLauncher.jar SNLauncher test/parameters/lit1-parameters
It will present a dialog that permits the numerical values in the snite parameters file to be adjusted. When the user clicks the "update" button on the dialog, the parameters file is edited and snite is launched. When snite completes, the output nuclei files are gathered together with the parameters file and the log file into a nuclei zip file suitable for AceTree. Also, an AceTree configuration file is produced. If you leave everything where it is and point AceTree at that config file you will bring up AceTree with the results of the snite run. It deletes the nuclei files themselves after zipping them up.
Here is a sample situation. In the directory shown, there is a copy of the StarryNite executable called StarryNight-060305, a test directory containing the raw material of a snite run, and a copy of SNLauncher1.jar.
-rwxrwxr-x 1 biowolp biowolp 137310 Jun 7 11:43 StarryNight-060305 drwxrwxr-x 4 biowolp biowolp 4096 Jun 8 08:00 test -rw-rw-r-- 1 biowolp biowolp 15806 Jun 10 14:44 SNLauncher1.jarThe test directory internals look something like that shown below.
test/centroids: lit1-t001-p01.tif lit1-t003-p13.tif lit1-t005-p25.tif lit1-t008-p09.tif ... lit1-t003-p12.tif lit1-t005-p24.tif lit1-t008-p08.tif lit1-t010-p20.tif test/parameters: lit1-parameters lit1-parameters~In that case, the minimum command line needed for SNLauncher is:
This will bring up a dialog which contains four fields specifying paths to be used in the operation. Only the third path, that labeled Parameters file will be filled in with the "test/parameters/lit1-parameters string. The other three, labeled Snite executable, tiffs path, and zip file come up with a string of asterisks. You MUST fill in those fields for a successful run.
In the present instance, if we fill in those three such that the four edit fields in the top section of the dialog are all filled in, then those four edit fields will then have:
[biowolp@madison snLauncher]$ java -cp SNLauncher1.jar SNLauncher test/parameters/lit1-parameters SNLauncher 1118440827859 Fri_Jun_10_15:00:27_PDT_2005Now, having ensured that valid paths to StarryNight and the data are in, you can edit any of the parameters in the parameters file using the set of edit fields below that top set.
If you lose your nerve, you click the "X" box in the upper right corner of the dialog and the run is cancelled without any action having been taken.
If, on the other hand, you come up with a set of edits that you think will work well, click the "Update" button at the bottom of the dialog. This will write an edited version of the paramters file on top of the original and will launch snite. There is no progress bar at present so you must have faith and maybe some inkling of how long snite will take. I suggest practicing up on a small number of time points.
When the run completes, the terminal window will look like:
[biowolp@madison snLauncher]$ java -cp SNLauncher1.jar SNLauncher test/parameters/lit1-parameters SNLauncher 1118441700273 Fri_Jun_10_15:15:00_PDT_2005 execIt entered 1118441752665 program: ./StarryNight-060305 test/centroids/lit1 . test/parameters/lit1-parameters execIt:start time 1118441752 execIt:end time 1118441770 returnCode: 20 end 1118441770700 [biowolp@madison snLauncher]$
Note a couple of things. First, StarryNight produces a return code of 20. If you see the program return real fast and a returnCode of 1 that means something did not look good to snite. Second, the tiff path entry that one uses is the one that one would have used as the fourth argument to snite in a command line execution.
Now, assuming things seemed to work, consider the directory afterward:-rw-rw-r-- 1 biowolp biowolp 15806 Jun 10 14:44 SNLauncher1.jar -rwxrwxr-x 1 biowolp biowolp 137310 Jun 7 11:43 StarryNight-060305 drwxrwxr-x 4 biowolp biowolp 4096 Jun 8 08:00 test -rw-rw-r-- 1 biowolp biowolp 263 Jun 10 15:16 yourFavoriteNameForNucleiZipFiles.dat -rw-rw-r-- 1 biowolp biowolp 5487 Jun 10 15:16 yourFavoriteNameForNucleiZipFiles.zipTwo new files are present. Both have the name you provided for the zip file. The ".zip" version is a proper nuclei zip file for use in AceTree. The ".dat" version is a proper config file for use in AceTree. In other words, you can now run AceTree using the ".dat" file as the config file.
One other consideration. The parameters file in test/parameters, namely lit1-parameters has been modified to include the changes you entered on the dialog. This parameters file is also in the the paramters directory of the ".zip" and that directory has the log file from the snite run also.
OK, I plan to base the test set on
/nfs/gs/shared/waterston/2color/112305_end1red
I moved 31 lsm files into the lsm directory. I am testing the lsm project from eclipse. It looks like it will take 12 minutes. Also, it looks like the source now only does lsm to zip conversions. This seems a bit unsatisfactory so I will need to look into it. The run I made was from the gui.
When I tested with a reduced number of files where I left gaps in the lsm series, the program ran OK. What it does is process the lsm files in alphabetical order by name. However, it assigns the tif names sequentially so in this case it looks like I have a valid tif(zip) series but it really jumps around in time -- the next sequential time may be many minutes beyond the previous one. I suppose this is OK but it should be kept in mind.
Each lsm files contains data for all the planes in use. Also, it may contain one or two channels. Now we are probably going to see mostly 2 channel data. So, an lsm might produce 60 or more zipped tifs.
addTimePointTif() is the original function that would produce the 60 tifs. Now there is also addTimePointTifZip().
It looks like I converted the program from tif extraction to zipped tif extraction without making a provision for the program to do either. However, we have a previously created LSM2TIF.jar so for now I will leave things as they are. If there need to be changes to the tif creation program I will address the issue of providing proper buildable source for it at that time.