From CwWiki

Julian,

I've checked a Corelyzer plugin that I wrote while I was in Germany. It consists of two projects: 1) a data model library for parsing directories of core images and 2) the actual plugin UI for displaying the directory of images. Below is a brief description of each:

plugins/DataModelLib:

This is a little library I put together for representing directories of core images as Java objects. It is very similar to the structure used by iCores and could possibly be merged with the code in the corelyzer.data package. Basically the library tries to parse core images by using a corelyzer.properties file in a directory. The properties file lets the user specify a regular expression to parse the depths out of the filename and also specify things like DPI X and Y orientation if they are known. If the filename contains two depths e.g. AND1_27.5-28.5.jpeg and the user doesn't specify the DPIs, then the library will calculate them for each image. If the filename only contains one depth e.g. AND1_27.5, then the user must specify DPIs and the library will calculate length for each image. At the very last resort, the library will use the DPIs specified in the file, but this will likely be an error. The DataModelLib also contains a simple dialog to assist the user in creating a proper properties file. I've tested the library with both naming schemes used by ANDRILL on ice and it works with both of them, so it will likely work for other projects. The library can also be used as the basis for creating scripts or a tool for generating iCores feeds.

plugins/DirectoryViewer:

This is just a simple plugin that provides the UI to the DataModelLib. I made it as a separate plugin because I didn't want to overwrite any work you were doing on iCores. If you open it up, you'll see that it is very similar to the iCores UI, so eventually we could merge it into the main iCores plugin. But for the time being, I've left as a separate project. One thing to note is that this plugin is track-aware so it will create new tracks for different directories. This allows it to work simultaneously with split core and whole core images as well as for separate holes.

My main motivation was to familiarize myself a bit more with the code base and come up with a solution that will allow the scientists who will be at the drill site this year to view their core images before I get them put into iCores back at McMurdo. The network connection between McMurdo and the drill site won't really be appropriate for sending large amounts of data back and forth, so they will have their own dedicated Corelyzer workstation out there and I will probably send out a hard drive daily with the split core images as we get them. They can just copy the images to a directory on the Corelyzer system and view them directly.

Cheers, Josh