r1 - 19 Jul 2006 - 11:55:33 - ScottLawrenceYou are here: TWiki >

LIAS Web > ProjectDiary2005

Project Diary 2005

This is just an informal way to keep the team appraised of your projects and progress. We're growing, we're distributed, and we're collaborating. So, tell us what you're working on, finished, or starting!

This is an archive of the diary from the year 2005. The current ProjectDiary has links to newer items and such.

-- PatrickStein - 08 Sep 2005
- Larch Data Ingestion
  - Wrote a crawler to put data from a flight into a DB.
  - Currently does:
    - Figures out flight legs
    - Figures out clusters of legs in the same area
    - Calculates bounding polygons for each cluster
    - Adds each image, flight leg, flight cluster, and flight to the DB
  - Need to:
    - Add thumbnail images to DB
    - Add auxilliary data files to DB
    - Work on the client side for awhile
-- ScottLawrence - 26 Aug 2005
- AdpGui^?
  - Terrapix Color imager done - It displays the thumbnail (VNIRS) data as generated for me, but then i force a brightness adjustment on it, so instead of it looking muddy green and muddy brown, it looks bright muddy green and bright muddy brown. In any event, it works
  - Fire imager done - first version It has some hardcoded things in there for now... all parameters for it are fixed until next week, when i add in sliders and such to let you adjust the settings. It displays SWIR as red, LWIR as blue, and fire as green... thresholded. everything below 100 is black, everything above 100 is GREEN. This also triggers the blue streak as used elsewhere, and it also triggers a wide vertical bar. Since the streak might only be one pixel tall, and might get lost in the image shrinking, this bar really points out where the fires are detected. It should be noted that the SWIR and LWIR are normalized to fixed values, predetermined. This will be adjustable later.
  - EO Parameters are also now displayed on the EO tab. It displays both the SWIR and Fire image datasets' EO Parameters. They probably will always be the same.
  - command line parser has been changed from a hack to something that works well
  - command line option added to set the adpgui2.conf file to be loaded in (for testing, etc)
  - name changed to AdpGui2^?, since the structuring of many aspects of it are different now.
- AdpConfigurator
  - Fire startup stuff has been added (parameters)
  - AdpGui2^? parameters and startup method have been changed
- Misc
  - Jar filenames have changed. wasp.jar became wasp_corba.jar ImgApp^?.jar became AdpGui2^?.jar This was necessary since the structuring and such are very different now, and I didn't want there to be any bad collisions and such.
  - I finally figured out the proper way to do Java classpaths in .jar files, and how they all work. Once Vulcan comes back, some things will be adjusted to accomodate this new knowledge. It's to the point where the .jar files are double-clickable to launch them, but the environment isn't set up, so it won't work properly.
- Next
  - manual adjustment of normalization
  - figure out why histogram displays bog down the system so much, perhaps rework that part of the design?
  - Map Data plots onto the canvas properly
  - when Vulcan returns, adjust the wasp user's environment to let the observer just double-click the configurator.jar file.

-- HarveyRhody - 26 Aug 2005
- BillHoagland^? sent the following message about registration and fire detection. It looks like good results. The attached fireTest.pdf shows that the fire layer contains a range of integer values from 0 to 156. Those above zero correspond to some kind of detection. The fire pixels have values above 90 on this scale. I have shown detection images thresholded at (GE 0) and (GE 120). The 120 threshold captures most of the fire pixels and eliminates, with some margin, the nonfire pixels. This points to the opportunity to do a final thresholding operation at the production step.

ScottLawrence - 24 Aug 2005
- In the process of switching over the namespace/package name for all of the java stuff. While restructuring the gui, i settled upon Lias.Wasp.Adp.xxxx for the namespace for all of the items in the gui. I twiddled some CVS stuff in the repository for the configurator to reflect this, so you should probably do a make clobber before updating. I'm also going to be moving over the IDL generation stuff to fit in this namespace instead of the current wasp.xxxx to make it all fit together better.

BillHoagland - 24 Aug 2005
- The fire detection output looks plausible but I still get differences between registered images from Harveys code vs. the ADP. I am proceeding to test against the latest collect.

BobKrzaczek - 24 Aug 2005
- Documented installation of Leica libraries at InstallingLggm
- Made a "real utility" out of the perl hack I wrote back in June to generate event data for Imagine out of the Applanix data.
- Hooked it into the adp-postflight script. This is one more thing "ready to go" after a flight, and one less thing for Janno or Jason to deal with.
- Created a "patch kit" for vulcan that contains these changes, plus the fixed Indigo band registration tool, plus the adp script patched to call the reg tool correctly.
- This is the first "patch" we've generated for a target ADP system. It was pretty easy to do, now that we've got silvanus all set up. It should also be easier to generate these patches in the future.

BobKrzaczek - 23 Aug 2005
- Updated aplxsim utility. A new option -w will make it wait until the first connection, +10 seconds, before it sends data. This makes a "one shot" replay of a flight leg a lot more convenient.
- Updated reg to perform rotation of the MWIR and LWIR data differently.
  - Previous method was "table based rotation".
  - New method is "image based rotation" (one might also call it "brute force rotation" instead).
  - New method is based on a hunch by BillHoagland about why the registered data seemed to be off more than it's been with their test data and programs.
- Replayed yesterday's flight and registered the data. It's available for now at http://lias.cis.rit.edu/collects/08-22-05/products/
- Updated AdpConfigurator with new reg options.

BobKrzaczek - 22 Aug 2005
- New ADP flight checklist.
- New adp script for starting the system. Can now optionally start fire detection and Indigo registration.
- New adp-preflight script for clearing the C:/adp directory on vulcan prior to a flight. Data is cleared from the directory and preserved elsewhere; not deleted.
- New adp-postflight script for transferring data from the ADP onto removable media of some kind. Leaves the C:/adp directory in a good state for future flights.
- All tools installed on vulcan (thanks to Jason and the pilot from Landcare, who let me do some quick hacking on vulcan in the plane after today's test flight).

BobKrzaczek - 19 Aug 2005
- silvanus will now support WASP ADP development, just like vulcan does.
  - Footlocker, previous flight data, and other directories were copied over.
  - Naming Service is set up and running.
  - Leica software won't install for some reason, but that's the only problem. We'll fix it later.
  - vulcan is good to go.
  - Verified and running on silvanus: aplxsim controller reg mon filer
- Monday (or Tuesday, or Wednesday, or whenever weather permits), we'll make an update to vulcan before the test flight. Will support in flight registration and maybe even fire detection.

BobKrzaczek - 18 Aug 2005
- Going to write a standalone program for Leica, so they can reproduce the problem.
- The Leica code throws an exception at random times, and once it starts, it always fails thereafter. The exception gets more likely as the process size grows, but it's long before memory is actually exhausted in some cases.
- Tried, but failed, to run the Spencerport 10k data through georectification with a DEM. Loading the DEM takes about 10 or more seconds (depending on if the file is cached in memory), and always causes the Leica code to melt on the very first rectification. The process size immediately ballons to >300MB (with a peak of >700MB while the DEM is being loaded), so I suspect it's related to the general exception throwing issue.
- Using a DEM is also incredibly sloooowwwwwwwwww.
- Fixed an issue with the message queue in the geo process; now, we work with much smaller messages. Small messages mean we can enqueue more work during a backlog from the cameras. This is a good thing.
- Geo processing just can't avoid a memory leak in the Leica code. Not much I can do about it. I'll fire off a report to Jason. I've been trying things all day, including some suggestions from Bill (like, delete and create new georeference servers every 10th image). The memory appears to be leaked out during geo-rectification, and there's no handle to it I can find to manually release it for them. Foo.
- Want to finish off silvanus, but the remote desktop problem causes us to have a tug-of-war with other users of the system.
- Added -w option to registration process; output from registration can be saved to a certain directory on the system, instead of relying on an external filer process. This will lessen the load a little bit on the communication layer.
- Fixed a minor typo in the ENVI header generation. Doesn't fix the Imagine issue from last night.
- Double checked presence of fpatemp in raw camera output files, since we introduced ImgWriter a while back.
- Starting AdpBugs topic because my pad is starting to lose track.

BillHoagland - 17 Aug 2005
- Fixed remaining problems with LSR to UTM conversion. Sanity testing with other conversion methods shows agreement. Later today we should produce and check some ENVI output.

BobKrzaczek - 17 Aug 2005
- Moved camera interior orientation into Wasp ImgData; this effectively "carries" the interior orientation along with the image data as it moves through the system. Thus, when data goes through the reg object, it can change the interior orientation principal points and coeffs to reflect the processing that's been done to it.
- Moved interior orientation initial value out of the code and into the electronic footlocker.
- Moved boresights out of the code and into the electronic footlocker. Updated ElectronicFootlocker accordingly.
- fixed Bill found a bug with boresights units (degrees in some places, radians in others). Made changes to the way boresights are loaded in the system controller.
- fixed Found another bug where kappa and phi were being swapped, per Jason and Shari and Janno's suggestion.
- Did a lot more cleanup in Leica's georectification. Almost convinced myself that the remaining memory leak is in their code. It's good for a run of 10-12 images, on average, before dying. The death isn't due to a lack of memory, though; it looks like Imagine's DLLs choke when the process size climbs to 300kB or so. I'll report this to Leica.
- Other cleanup in the way that Eo and Io data is managed. Overall result is that we're damn close to emitting geo-rectified data in a way that Imagine can use it.
- Worked with Bill and added footlocker support to the fire detection framework; this in turn will support fire parameters.
- fixed A difference in the way that the compiler optimized a certain expression in the triangle registration made it work under Solaris and fail under Windows. Failure made the image look like it came out of a disco ball! New expression is 100% legal C++.
- Lots of CVS cleanup tonight, keeping chapman and vulcan in sync.
- Example of georectified data can be found at http://lias.cis.rit.edu/wasp/spencerport-10k-geo/ If your viewer chokes, edit the .hdr files and change Meters to meters.
- Created a "hacked" version of the Camera Control utility on vulcan that should be able to access COM3 through COM6.

BobKrzaczek - 16 Aug 2005
- Work on the geo rectification server continues. It runs for a handful of frames before it starts to crash. Looks like a memory leak to my eyes.
- Added preliminary support for map info and geo points tags in the ENVI headers for rectified files. ENVI parses it, but it's clearly not correct (not even close). This is as far as I'm going to do with this task; someone else needs to pick this up, who understands the ENVI headers better than I do. See aid/imgwriter.nw for details, look for the enviHdrEO function.
- An example geo-rectified (without DEM) multi-band registered image can be opened at http://lias.cis.rit.edu/wasp/mendon-reg-fire-geo/ Go ahead, take a look.
- Configured an SSH daemon for vulcan You can log onto the wasp account on vulcan via SSH. If you aren't familiar with SSH key management, talk to Bob; otherwise, add the public key you'll be using to ~/.ssh/authorized_keys in the wasp account on vulcan, and you'll be all set.
- fixed UTM for Imagine session initialization is now supported from the commandline.
- fixed Georectification objects are now named according to the source of data they connect to.
- fixed Georectification now really accepts data from any image source.

BobKrzaczek - 15 Aug 2005
- Progress on import of geo process continues. Because there's so many different ways for the Leica code to fail, I'm doing a lot more exception catching/processing than I planned. Bleah.
- Defined an interior camera orientation over in ElectronicFootlocker. This is required for the new Leica geo server.
- Produced a run of the RIT 5K test flight (from July) that includes Applanix data, Applanix events, raw camera data, registered data, and "fake fire" detected imagery. This gives JasonFaulring something to use in determining his "end of flight" manual processing, and HarveyRhody something to examine in the meantime to check out our registration results.
  - /lias/wasp2/wasp_collects2/07-11-05/regtest
- Made a minor code change to the fire detection server. I split the main fire processing into two pieces: one that understands the CORBA side of the house, and one that just works in pure pixel_t pointers. The former takes care of all the network and IDL stuff; the latter is a super clean and simple interface for BillHoagland to plug the fire detection algorithms into.
- Added the support for LSR to UTM conversion in the Georectification server. Bill, in the ngeo directory, look for the geo.cc file. In it, you'll find a function setutm that's a part of the Geo class API. Should be fairly self explanatory; if you need values from the commandline, or from the footlocker, let me know and I'll show you how to do that.
- I briefly tested the Launcher aka the Configurator. Wow! That's much farther along than what I was led to believe. I couldn't do much in depth testing, but what I saw looked good, and the commandline generation and editing is a great idea. I have high hopes that even in its unfinished state, this is going to be a big win. Thanks, Scott!
- News! The georeference server is running. It doesn't crash. And it even appears to be doing some kind of image mapping (I managed to pick test images that are close to nadir and flying sorta north, so there isn't much for it to do). More testing tomorrow, but I can't tell you how good this makes me feel!
  - The rewrite is already helping it; I accidentally caused a backlog, and the server just kept chugging.
  - The rewrite also has one other nice feature we lacked before: you can connect this server to almost any Data Provider in the system. If you connect it to cameras, you get single band geo-rect'd images. If you connect it to the reg server, you get all three Indigo bands mapped. If you connect it to the fire server, you get all four bands (3 cameras + fire probability) rectified to the ground. Nifty!

BobKrzaczek - 13 Aug 2005

Finished the rewrite of the geo-rectification service into the framework that the new registration object, and the new fire detection object, all use. This is getting easier and easier.
fixed This move of the geo server fixes an important bug in the previous geo service: if the system ever got bogged down, the geo service would start losing frames. The new server maintains a ``work queue'' and strictly processes one frame at a time. It can't load the system down when there's a backlog, and it won't drop data on the floor.

Changed ExtOrient in the WASP IDL from a simple structure to a union, based on yesterday's discussion with BillHoagland and JasonFaulring about LSR and UTM and such. Here are what old and new definitions resemble (IDL for Unions is more involved and verbose, so I'm omitting details here in order to get the point across):

struct !ExtOrient {
   boolean valid;
   double x, y, z;
   double o, k, p;
};

enum !EoKind { !NoEo, !LsrEo, !UtmEo };
enum !UtmHemisphere { !NorthHemi, !SouthHemi };
union !ExtOrient switch( !EoKind ) {
case !LsrEo:
   double x, y, z;
   double o, k, p;
   double ax, ay, ax;
case !UtmEo:
   double x, y, z;
   double o, k, p;
   unsigned short zone;
   enum !UtmHemisphere hemi;
};

All ADP developers must CVS update their entire tree and rebuild from scratch. Sorry. That's what happens when you change fundamental structures and classes, like ExtOrient.
Got brought up to date regarding the launcher and the gui by ScottLawrence before he left for vacation. He wasn't able to complete testing, so that's my main to-do for Monday the 15th.
fixed While propagating the WASP IDL changes throughout the ADP, I discovered a bug in the registration object, where it was failing to propagate the SWIR navigation solution to the RegIR image cube. That's why I no longer shy from these system-wide changes anymore, they tend to force a review of previously written code.
done Propagated ExtOrient change through the system. I updated and tested: idl aid mon filer controller ntreg nfire ngeo gui (Updating the gui wasn't a fraction as hard as I thought it would be; nice job, Scott!)
Pushed to CVS.
next Further testing on Leica's geo rectification service.

ScottLawrence - 12 Aug 2005
- AdpConfigurator and Adp Gui
  - Both are connected up to each other such that parameters from the configurator are passed into the gui
  - Configurator loads and saves mission files (simple dtd-less xml file, also used for my .conf files)
  - Configurator is set up for: controller, reg, fire, geo, gui
  - haven't tested the launching of fire, geo, and reg yet
  - it should launch them fine based on prior testing. Commands are generated near the top of Lias/Adp/Configurator.java
  - in order to retrieve environment variables, it needs to be run from a shell/command prompt. To see if it inherited the environment properly, run it, and click on "get nameservice from environment".
  - I spent some time last night trying to get it to launch properly from doubleclicking a .jar file. It worked great on osx, but not on windows. I spent time trying to figure out why the windows JVM seems to ignore the default-class tag in the manifest file (or whatever), as well as why it couldn't find the proper jar files for the classpath. The classpath in the manifest needs to be non-specific to the sytem, with relative paths. I think i left the manifest file generation in an incorrect state, although it does run on windows from the command line.
  - I found that you can install .jar files into an ext directory to have them automatically searched on jvm startup, but I couldn't find which =ext directory to use. (I found one, but it didn't seem to change anything.) (I believe it was ext... it was pretty late at night...)
- Note for when i get back: I need to re-structure the gui to be layed out more like the way the configurator is... also some of the design of it is rather messy.
- LlamaGui has also changed... You will need to make install to get the new updated jars

BobKrzaczek - 11 Aug 2005
- With vulcan back in the lab, been retesting the ADP from the "ground up". Don't want to see a repeat of yesterday.
- Everything, rebuilt from CVS, seems to be running correctly again. Tested:
  - aplxsim
  - controller
  - mon
  - filer
  - reg
- EO calculations still look bogus, though, from the controller. This is a recent checkout from CVS, and includes the 08/09 bugfixes.
- Can't test Leica geo-rectification until eo calculations work.
- Tested that band-to-band registration works.
- fixed Shari's DEM files do work in the Leica software, now that the rrd is provided as well.
  - roc_49dem works, and yields MapInfo^? bounds of (704200, 4.80891e6) and (797600, 4.70809e6)
  - roc_drg does not load... should it?
- fixed BillHoagland found the remaining EO glitch, and exterior orientations are now working right.
- bug The Leica geo-rectification won't run. Again. Debugging it now.
- done I wrote a new fire processor using the new framework.
  - Presently, it just draws a gradiant circle in the center of the image as the fire probability. Center of the image: 100% Edge of the image: 0% Size of circle: approximately 25% of the image.
  - This kind of test image will let ScottLawrence test how he displays Fire maps in-flight.
  - Properly generates 4 band data: SWIR, MWIR, LWIR, Fire.
  - Properly saved to ENVI format: I was able to display them, multiply the bands together, and other common operations.
  - Pixel values are 16 bit unsigned, in the range [0,255] (this is easiest for ScottLawrence to process in Java).
  - Will be easy for BillHoagland to drop the new fire detection code into.
- bug Either reg or fire isn't copying the NavSol forward from the SWIR camera. By the time we have fire data, we have exterior orientation, but not the original navigation solution that generated it. No one cares about this except me, I bet.
- Started the AdpConfigurator topic referenced below by ScottLawrence. Currently contains a partial (but mostly complete) listing of the things that the launcher really needs to provide to the end user. We'll undoubtedly add more stuff later, but this is enough to keep that ball rolling for now.

BobKrzaczek - 10 Aug 2005
- Crisis: none of the ADP runs on vulcan, suddenly. Worse, connecting to any network object from vulcan will get hung. It's like vulcan has the CORBA "touch of death".
- Crisis averted: Okay, here's what's happening.
  - vulcan is in the roof lab.
  - Its primary network interface is unplugged.
  - Its secondary network interface is plugged into the building, and has an IP address given to it by DHCP. (Normally, this has a 10.* address, not 129.21.*)
  - For whatever reason, Windows has decided that this is good enough, and that the system should use the name "vulcan".
  - Thus, whenever vulcan gives its name out to anyone on the network (say, a remote CORBA object), it's giving the wrong address.
  - When it's in the plane, it uses the name "localhost". For some reason, in the roof lab, it's using "vulcan".
  - analogy Vulcan calls up another object on the net, and tells it to call it back at a certain phone number, giving the wrong number. Vulcan proceeds to hang, waiting for a phone call that never comes. The other system also hangs, waiting for vulcan to answer a phone call it never gets.

BobKrzaczek - 09 Aug 2005
- Fixed generation of multiband ENVI files.
- Fixed Terrapix in-place decode and downsampling code.
- Added Harvey's suggestion to let reg perform rotation on LWIR and MWIR images.
- Argh, vulcan is offline. Can't get back to the Leica stuff or the general rebuild of everything from CVS.

ScottLawrence - 08 Aug 2005
- AdpConfigurator ...TPFKA "The Launcher"
  - Spent some time today trying to get the environment to go down to an application. I have an idea to try out tomorrow, but if that doesn't work, I have a simple hack in place, based on BobKrzaczek's suggestion of using /bin/env
  - The basic GUI layout is on its way. The interface for launching Controller is done.
  - Next: I'll be putting in Loading/Saving of the Mission files.
- AdpGui^? (To do...)
  - Needs to load in the above Mission file
  - Needs to be updated to use the changes to the IDL:
    - Pull position information from the Image metadata, display position and aircraft orientation
    - Pull FPA Temps from the Image metadata
  - Finish up and test the color image data viewer (Terrapix VNIRS data)
- AdpFootlocker^? (To do...)
  - Need to figure out all of the required files for all of the modules
  - Integrated the above data into the AdpConfigurator

PatrickStein - 08 Aug 2005 (Since I've never written to this page, it'll be hard to give any sort of current state without also mentioning things that have been done for a few weeks... so I didn't really do all of this this weekend.)
- Formalized the initial database schema that I'm going to go with. See LarchDataIndexing.
- Implemented a tiny language to use to create database access classes. (May want to move this to XML sometime, but at the moment, it's just line-based ASCII. See LarchDBAcessLang
- Created a test database at home using PostgreSQL
- Tested the generated database access classes using said database
- Started working on a crawler to load in the WASP flights
- Next steps:
  - complete geolocation of corners and center of each WASP frame
  - make a bounding-polygon-builder class that I can feed points into and pull out a useful bounding polygon

BobKrzaczek - 08 Aug 2005
- Major changes through the weekend. You're going to need to update your whole ADP tree from CVS, and rebuild everything.
- Added a NavSol structure to ImgData frames in the system IDL. In this way, the original navigation solution is carried with each raw camera image as it travels through the system.
- Added "valid" flags to the NavSol, ExtOrient, and GeoMapping structures. When set, you can use the structure. When false, don't even look at it.
- Added fpatemp to ImgData. For the Indigo frames, this will be set and thus FPA temperature is carried in each image data frame.
  - ScottLawrence: Feel free to take advantage of this in the GUI. This might make things simpler for you, instead of calling the controller via separate functions to get the FPA temp. Now, they're carried with each image frame.
- Factored the VNIR downsampling code into a separate function in the system controller, called downVNIR. This is meant to do an "in place" downsample and Bayer decode.
- Factored out the image writing code in the flight recorder, and added it to the aid library as an ImgWriter class. Understands ImgData objects directly, as well as exposes its subfunctions so that you can slice up the objects yourself.
- This leads to many parts of the ADP all writing ENVI data files for their outputs, using common code, instead of everyone having their own file formats (raw, PGM, ENVI).
- Added an assemble function in the system controller that builds an ImgData frame from all the components that used to be sent to the flight recorder manually.
- Added new send methods to the system controller that work with the new ImgData methods.
- Updated the filer object to use the common ImgWriter class.
- Image registration might be working. It's hard for me to verify, because I'm not writing 100% perfect ENVI files yet.
- WASP Geo rectification is working, in the old framework, but only if I copy the executable into the Imagine tree (specifically, bin/ntx86). Can't proceed on testing this further until the Exterior Orientations are fixed (current values just crash the Leica code outright).
- Next:
  - Someone (anyone) can jump into imgwriter.nw and update the enviHdrGeo and enviHdrEO functions to write their data in a way that ENVI and Imagine will use. Recent emails from JangHoPark and BillHoagland tells me they know more about this than I do.
  - Add rotation hack to the tables that are loaded by the band-to-band registration object.
  - Add the test executable back into the new triangle registration object directory.
  - Write up a wiki page detailing the kinds of options that ScottLawrence needs to offer in his launcher.
  - Set up the Name Service on silvanus. Document it onto the wiki (didn't I do that? can't remember.)
- Bugs:
  - Registered IR images, written via enviHdrRegIR in the aid library, don't seem quite right. Imagine and ENVI only open about 1/3 of each band, which tells me I'm not writing band-interleaved image cubes correctly. BillHoagland could you lend a hand here?
    - fixed In adapting to "minimum" sizes (sometimes the Indigo images might be short, sometimes the tables might be short, sometimes both, sometimes neither), there's a few places where we artificially shorten the length of a loop or an image, based on the minimum sizes. One of those sizes didn't take into account the "three samples per pixel" rule in the tables; hence, everything off by a third.
  - downVNIR is emitting crap again. Or, maybe enviHdrVnirS is at fault. Either way, neither ENVI nor Imagine can open VNIRS color imagery.
    - fixed I never noticed that downsampling only worked on vulcan and not chapman... duh. The code, as I had written it, assumed little endian byte order. Wrote an alternate code path for downVNIR that is used on big endian machines. Slower, but not as bad as it would be, otherwise. Now the VNIRS images look right on both kinds of systems.

BobKrzaczek - 26 July 2005
- Implemented Footlocker class for use by ADP processes to access what will become the electronic footlocker.
- Started some initial notes on what goes in the ElectronicFootlocker.
- Changed ADP IDL to report FPA actual and set temperatures as double Kelvin, rather than unsigned int milliKelvin.
- Changed ADP GUI to work with doubles instead of ints, accordingly.
- Updated ADP Controller to provide FPA temperatures on the network.
- Reviewed triangle registration; I'll have the new updates all set and on the network in the morning (27th).
- Unable to test FPA temp changes; vulcan's hardware is just in a weird state.
  - Noticed a bug: when cameras are all at different baudrates, controller just can't seem to make the right guesses... need to think about baudrate detection some more.
- Want to add NUC table display and selection to the ADP controller as well.

BobKrzaczek - 24 July 2005
- Completed the new applanix simulator the other day.
- Completed the "replay" camera driver.
- Fixed some of the command line awkwardness in the ADP controller.
- Simulation driver development is complete.
- Went to build the Leica LGGM component, but LggmGeoreferenceServer.h can't be found. Must have been a problem with the reinstall a little while back. I'll pick this up Monday morning, first thing.
- Oh, I think I see what happened. The old vulcan had so many different installs on it, that the old directory paths were bound to find it somewhere. The new, clean setup has very specific locations for different include files and libraries and such... and, of course, it doesn't make sense. Anyway, I see what to do, and I'll fix it in the morning.

BobKrzaczek - 21 July 2005 - 4:41am
- The new simulator code is coming along. We need this in order to host the development and testing of the Leica LGGM modules (e.g., geo rectification). It took me longer than I expected to get back into this, but things finally started coming together around midnight. I should be able to have the simulator back up and running (remember, the old simulator doesn't work anymore, since we changed so many things about the ADP over the past couple months) sometime on Thursday.
- In theory, testing the Leica code should be easy, since it did used to run, and very little about that part of the system has changed in recent months. We'll know where we stand on Friday of this week, I'm confident.

BobKrzaczek - 06 July 2005
- 5:05am Yup. The ugly hack appears to work. Now, to figure out how to plug it into the ADP...
- 4:40am Not going well.
  - Windows has an event model that just doesn't work right with serial ports. Basically, unlike other operating systems that have a uniform way of dealing with file descriptors (be they network sockets, files, serial ports, etc), Windows forces entirely different code and API onto you. So you can't integrate reading from a serial port in the same event handler that listens to network activity.
  - Not all is lost. I think I can arrange a hack by using blocking IO in a separate thread, per serial port. It's ugly, but it might work. Writing test code now.

BobKrzaczek - 05 July 2005
- Installation of WASP delayed until tomorrow, July 6. Last chance to get the RTIE support into WASP (to get the FPA temperatures and NUC tables).
- 11:39pm Finally got the serial protocol, CRC hacking, and so forth worked out. I can, with a test program, obtain the FPA temperature and status, get the current NUC, get the list of all loaded NUCs, and test the protocol.
  - I moved the serial ports around. LWIR is at COM3, MWIR is at COM4, SWIR is at COM5.
  - For reasons I don't understand, the LWIR and MWIR cameras are talking at 115,200 baud. The SWIR camera is talking at 19,200 baud. It looks like I'm going to have to probe each device at start up, and keep trying different baud rates until we find one that's valid for the camera. Just one more hassle to deal with.
  - They're using the CCITT "zero" variant of the CRC16 algorithm.
  - Now I've got to noodle a little bit about the ADP. Now that I understand the serial protocol they use, it's going to be a little odd to wedge it into the ADP's listener loop. At least, I think I'm going to put it in to the same ACE reactor as the Applanix listener uses.

BobKrzaczek - 04 July 2005
- Lots of stuff happened, it's covered in email, let me know if you need a copy.
- I'm looking over the current status and remaining tasks, and I have to change my assessment of where we are regarding the WASP install scheduled for today (Tuesday). I'd like to ask you all that we move the WASP install to Wednesday (tomorrow). Too much has changed at the last minute, and I'd like some integration and testing before we make the big MISI/WASP swap. More, I spent all the time I allocated this weekend on unplanned hardware debugging and other related integration tasks, and never got any time to work on the Indigo serial development (supporting FPA temps and NUC tables) that we planned on Friday. It's going to be quite hard to develop that last functionality against Indigo cameras if the hardware isn't here.

BobKrzaczek - 03 July 2005
- 5:30pm
  - Finished CORBA definitions that ScottLawrence wanted.
  - Retested controller on WASP hardware. JasonFaulring came in and worked his magic earlier today.
    - good: Terrapix is firing.
    - good: Indigos are firing.
    - good: Applanix sees the events and returns both event 1 and event 2 notices.
    - not so good: All three Indigo cameras are now 8x1 cameras (instead of 640x510 or 640x512). What the...?
    - not so good: Running all four cameras, I can't achieve our 4.5-4.7 second triggering period. It seems that the Terrapix is taking too long to expose here in the lab. This ought to be fine once we're outside, but... what's different now? Why was the lab "bright enough" before, but not bright enough now? We're in the 5-6 second range right now.
  - I think there's just a configuration change that's left to be made to the Indigo cameras, and we can do a data collect (sans FPA temperature) right now.
- 8:30pm
  - Was still getting 8x1 data from the cameras, after a possible fix from Jason.
  - I proceeded to plink around on my own for a while... I found the PhoenixCAM utility, pointed it at COM3, and found that it was set to "non-imaging mode". I switched it to "imaging", went back to the ADP controller, and now the camera reports itself as 640x514. Yeah, 514. Toggling it back to "non-imaging" yields a camera that claims its size is 640x512, just like the source windows says it should. (Not that it didn't say that to beging with; it did.) So, I did nothing except toggle it back and forth, and it made a difference.
  - Then, the Applanix started sending me a constant stream of group 206 messages; it wasn't doing that before! Then I found that the camera on COM4 was set to external triggering, and the camera on COM3 was set to internal triggering. Worse, video was enabled on all cameras; I killed that and the AGC while I was in there. How was this not happening this afternoon, but happening now?
  - So, after about 12,000 or so event 1's were sent to the Applanix (you may think I'm exaggerating; I'm not)... anyway, I think I've got all three cameras working right. At least, I'm getting data off them, it's the right size, one of the channels actual gives me an image of the lab table (the other two cameras give me the familiar "vertical streaks" pattern). I hit all three cameras, so, Jason, expect to find COM3 and COM5 swapped, since the Phoenix program can't deal with COM5.

BobKrzaczek - 01 July 2005
- 4:10pm At the 3pm meeting, we were told that all the National Instruments software was installed on vulcan. Turns out that's not true; maybe it just wasn't checked close enough. Anyway, I went back upstairs, pointed out the glitch, and mentioned that without it, the ADP controller can't trigger the Indigo cameras.
- 4:30pm Janno fixed the NI software! Yay. I completed the build of the ADP controller. Seems to work under Windows with all devices simulated.
- 6:10pm Finished trying to get it working. By 4:50pm, I saw we had problems.
  - Gimbal works fine.
  - Indigo cameras can't be opened: driver returns error BFF60027, which corresponds to "no interface found". With ScottLawrence's help, we found that the cameras are currently named img0, img1, and img2, instead of LWIR, MWIR, and SWIR. What the...? I've temporarily changed the ADP controller to use img0 for the longwave camera, and so on. I can now open the cameras, but...
  - The Applanix is not generating event data. I've enabled not only groups 206 and 207, but even groups 4 and 5. It generates lots of group 101 and group 99 records, so we know it's up and on the net and whatnot. It's got seven satellites in view, so it should be able to generate event data. But triggering the Indigo cameras does not yield an event from the Applanix. I can't tell: if this is because the cameras aren't actually being triggered from the IMAQ, or if the Applanix just isn't seeing it.
  - Terrapix camera can't be opened: driver returns error 2, which may mean "camera not attached". I can't be 100% certain of this, the MegaVision library isn't documented as well as the National Instruments library. Unlike the Indigo camera, neither Scott nor I have any idea how to proceed with the Terrapix hardware.

BobKrzaczek - 30 June 2005 - 19:17
- Recompiled ACE/TAO static and release. Previously, we worked with dynamic and debug.
  - static means that ACE/TAO do not use DLLs. This doesn't affect the rest of the system, but it's one less thing to deal with when building executables and giving them to other people to use.
  - release means we've turned the compiler optimizer on. This won't help too much since we're much more I/O bound than compute bound. Still, it will be nice to have.
- Fixed the CORBA Naming Service so that it's running again on vulcan.
  - I couldn't get it to start on the previous DLL build. Apparently, I must have hacked around this on the old vulcan by copying various DLL files to other places to get it all working. I didn't want to recreate that hack.
  - Reading its source, I found an undocumented feature: arguments for the naming service are loaded from the Windows registry under HKEY_LOCAL_MACHINE\SOFTWARE\ACE\TAO --- if a string parameter named TaoNamingServiceOptions is found, its value will be appended to the start-up arguments. So... that's what I did. And, surprisingly, it worked.
  - With the arguments now working, there's no reason to start it manually. Vulcan is now set to start a local naming service upon system boot.
- Fixed the triangle registration utility to work with the new(er) creo and library set up. Seems to work, tro runs on the PC lab machines without ACEd.dll or other malarky.

BobKrzaczek - 02 June 2005 - 12:43am
- It's working. Yep.
- I rewrote the driver loop; removed all the fat. Along the way, I rewrote the way that cameras store and report their status (camera status is ``am I acquiring an image?'' ``am I transferring the image to memory?'' ``do I have an image that hasn't been collected yet?'') The improvements were what I was expecting/hoping for.
- Driver pause functionality works exactly as expected: when the operator "unpauses" the system, it immediately takes a picture. Nice.
- We are limited by the Terrapix to a firing rate of once per 4.7s. This fits within JasonFaulring's 5 second window; we'll still have good overlap between images. This matches what I saw in the Warsaw flight; I feel good about this number.
- Hmm. Images don't look right. Terrapix looks pretty much random (it always does in low light), but the Indigo cameras are returning buffers of all zero. That's too perfect; something's amiss. I know we're getting data, we just must not be triggering the Indigo cameras correctly.
- Runs from both commandline and from the GUI.
- GUI has a number of slight startup problems; all correctable at run time by the operator, but the GUI should "start right".
- Leica geo-rectification modules dump core on live camera data. sigh We know we have a new library from them; we'll have to decide between:
  - Our first flight is just a "collect" flight; no geo-rect or other processing. Pro: sooner Con: less in-flight checkout.
  - Our first flight runs the whole suite of functionality. Pro: better checkout Con: more delay as we update the Leica libraries and propagate their changes through our system.
- Add a special flag to the controller that can leave a camera driver uninitialized, and the same thing for gimbaling, and then I'll test the "just nadir, just Indigo" speed for Don. I think it'll be good news.
- Modulo the missing data from the Indigos (which I suspect will be an easy fix), this system is running right!
  - No lock ups.
  - Nothing out of sync.
  - No pregnant pauses.
  - Runs as fast as the hardware will let it.
- w00t!

BobKrzaczek - 01 June 2005 - 1:19am
- Good news: Everything is running. Cameras fire, gimbals move, data flows.
- Bad news: Not at 4 seconds per exposure.
  - The gimbal takes 3.9 seconds to move from position 3 to position 0.
  - Changed the cycle time from 4 to 4.5 seconds. This matches the Warsaw flight data I investigated a few days ago.
  - But, even at 4.5 seconds, it's a little tight. Occasional lockup in the driver loop.
  - Aren't you glad I'm testing?
  - Since I doubt I'll be allowed to change the cycle time to much more than 4.5 seconds, I'm going to recode the driver loop, try to knock out as much wasted time as I can. It's too late to do this now; I'll hit it in the morning.
  - I think this nixes the idea for a Thursday flight.
  - Worry: if the WASP prototype was running at 4.5 seconds per trigger, what makes us think we can match that and geo-rectify and register and fire detect and...? Is vulcan going to prove to be that much faster than the WASP prototype computers?

BobKrzaczek - 30 May 2005
- Still can't get the Applanix to talk to me on the network.
- I'm beginning to doubt its manual. It's running, the Windows application tells me so, but I can't get it to put a single frame onto the network.
- BillHoagland said this thing works; I need to get his input on what I'm doing wrong.

BobKrzaczek - 27 May 2005
- Rewrote the driver loop today. Now it works great.
- Yes, that means that gimbal movement and camera triggering are done!
- In testing, I saw first hand the driver's attempt to space the camera firings out to 4 second boundaries. This never works if the Terrapix is activated, and works fine if only the Indigo cameras are driven.
  - The Terrapix is taking forever.
  - We're indoors. But listening to the shutter in the Contax, it doesn't sound like I'm waiting that much on exposure time.
  - I reviewed the Warsaw test data; looks like the cameras were firing around every 4.5 seconds on that flight.
  - Maybe I can get JasonFaulring or ScottLawrence to give me an improved "camera busy" function. I suspect a good chunk (all?) of the Terrapix wait time is just waiting for data transfer. Therefore, having the following knowledge will let me overlap gimbal movement with Terrapix data transfer.
    - Is the camera busy integrating?
    - Is the camera busy transferring data?
- Can't get the Applanix to tell me jack on the network. Until this works, I'm not receiving any camera data.

BobKrzaczek - 26 May 2005
- JasonFaulring suggested powering down and back up the whole WASP system, from vulcan to the cameras. That seemed to do the trick; at least the cameras aren't constantly hung busy.
- Still can't get the cameras to trigger reliably.
- The applanix simulator has actually become an annoyance, since it doesn't know what the gimbal is doing, the driver gets out of sync. Remember, it's trying to not fire the cameras while the gimbal is moving, but the applanix simulator is just spitting out fake camera triggering events whenever it wants.
- Going to start listening to the real Applanix, now that that's online.
- I'm sure I'll have the hardware issue straightened out tomorrow morning.
- Notes to self:
  - why is the Terrapix triggering at startup? Jason says it's not necessary.
  - Start system paused. Let it settle down. Then unpause it, as if the GUI said "go".
  - Sketch event sequence in Jerry's test code. Sketch the same in the ADP driver and listener loops. Which discrepancies matter?

BobKrzaczek - 25 May 2005
- We're on the hardware!!!
- We're not consistently triggering the cameras.
- We do consistently get data from the camera buffers, so we know that the buffer negotiation with the Indigo is correct.
- Symptoms: Terrapix triggers once, and once only. Indigo is hard to tell; do they trigger or not, there's no external indicator.
- Indigo cameras also don't seem to clear (Terrapix doesn't support a clearing step).
- I'm sure I'll have this straightened out in the morning. Well, maybe not, we've got a telecon with Leica. But shortly thereafter.

BobKrzaczek - 24 May 2005
- Based on advice from HarveyRhody, flight recorder now emits ENVI files instead of raw data for each camera frame. Wow. I should have looked at ENVI first; that was dead simple. Leica's Imagine format, by comparison, is a marvel of unnecessary complexity.

BobKrzaczek - 23 May 2005 - 4:54pm
- Wow. Same "minutes" field in the timestamp as my last update. Weird.
- Flight recorder is done. I'm recording raw camera data, applanix data, and even the calculated exterior orientations (though we don't have to), as well as the log of system events and some other miscellany.
- The flight-recorded camera data is "raw". I know Jason asked for Imagine or ENVI formatted data so that he could look at them "in the air". I'll add that later; for now, we'll post process on the ground and turn them into whatever's needed.
- Added functionality for the GUI, tested it as well.
  - pause/unpause in flight
  - gimbal movement from GUI (when system is paused)
- Did some more testing of the system, fixed a couple minor issues along the way. Portability stuff for Windows, performance stuff for file IO.
- Can't wait to test on hardware.

BobKrzaczek - 23 May 2005 - 1:54am
- New combined controller process works.
  - One process
  - Single instances of all hardware interfaces
  - Provides controller object to rest of ADP for pause/unpause and related control functions.
  - Provides camera objects to rest of the ADP for subscriptions and data.
  - Should fully support all three hardware systems: gimbal, indigo, and terrapix (can't test the last right now, will test as soon as WASP is back up and running on the bench)
- Upgrades to previous functionality
  - Null camera device provides simple checkerboard test images, including a silly bayer image for the terrapix.
  - Bayer processing and downsampling for the Terrapix data stream.
  - Flight recorder started! (This is the biggie; it's an object that records all sorts of useful information as the system flies; since the only thing that generates critical data is the controller (all other modules can be re-run on the ground), this is inside the controller at present.)
    - Support auto-unique directory for execution; no chance of running this flight program twice and overwriting a previous collect. Also makes in-flight restarts safer (god forbid we ever need that).
    - Support trace and debug messages throughout controller.
    - Will support Applanix data and Camera data after another hour or so.
- When the flight recorder is done, then I'll start thinking about the rest of the processing modules. We want to see registration, fire detection, and such in flight. But it's not crucial to a data collect; I want to get us to a point where we can start satisfying people's data collects.

BobKrzaczek - 16 May 2005 - 6:09pm
- Good news: the checkerboard test patterns display properly under the GUI. This further proves what I was testing last night.
- Bad news: there's a slow memory leak in the cams process. About 8KiB/4s when running three camera channels. Hmm, no data structure immediately springs to mind that's around 8/3KiB in size. Small leak, should be easy to find and plug.
- ScottLawrence tells me that JasonFaulring will debug the gimbal stuff tomorrow (Tue).
- BillHoagland tells me that the band-to-band registration is working for two channels right now.

BobKrzaczek - 16 May 2005 - 4:43am
- The controller process is working as of last week.
- The cams process is working as of ten minutes ago (doing some light testing).
- All processes are properly multithreaded.
- Fixed the object instantiation problem. The problem that was holding me back was the order of instantiation.
- Tested the CORBA layer; can't get a serious load on it yet, but overall performance looked really good. Leica's latest geo rectification may kill our runtime performance, but it won't be my code that's at fault.
- Plugged in the gimbal hardware code last Friday night. Did some debugging earlier this afternoon. It works... sometimes. ScottLawrence acknowledges that there's something strange going on with the gimbal hardware. JasonFaulring is going to swap firmware boxes on Monday, 16 May, and see if he can't isolate it.
  - gimbal often appears "stuck moving to home", even when it's already home.
  - gimbal moves to home at the indexing speed, not the calibration speed.
- Testing the hardware code during my debugging; uncovered another timing problem with Windows. The test code thinks it's strobing the hardware lines for 10ms, but I've tested my code and I've tested their test code. I'll bet you lunch that if you put a storage scope on the line, you'll see it strobed for 15ms, and there isn't squat you can do about it within Windows. Now probably isn't the time to remind everyone that Windows is not a real time operating system.
- But the timing probably isn't related to the gimbal issues, anyway.
- Next steps:
  - Bring Indigo code into ADP. (easy)
  - Bring Terrapix code into ADP. (easy)
  - Add "recorder to the ADP. (mostly easy)
  - Ping Scott, see how his stop/pause functionality in his GUI went, and make sure the controller is in sync with his expectations.
  - Think about pulling out some test code; I probably wrote the ADP too defensively, and that might hurt performance. Meh, wait until we see it running with Leica's software before worrying about that.
  - Can I clean up process exit before Wednesday? Things stop, but messily. It would be nice if the objects cleaned up and finalized pretty.

BobKrzaczek - 23 Apr 2005
- Changed the way I was setting up threads in the main loop of the controller; this facilitates CORBA by letting all the "non CORBA" parts of the controller "start up and get out of the way" before all the CORBA code comes along and takes over. This includes setting up more than one ACE reactor, running in multiple threads, while the process maintains another reactor somewhere else. Fun idea, I'm glad it worked out.
- Now I can reuse a lot of the CORBA code from the other objects in the system, and probably even use most of my TaoHelp class to implement what's left.
- Very close to fully functional. Encouraging.
- I have the EO code integrated from BillHoagland. We'll test it next week, after I plug some fixed navigation solutions into our Applanix simulator.
- ScottLawrence is almost done with hardware integration for the controller. We'll have some build issues to work out next week, but I should think it wouldn't take more than a day to deal with the remaining issues with Windows.

BobKrzaczek - 20 Apr 2005
- Fixed a ton of little bugs, including a downcasting bug that was causing Navigation Solution Message Block pointer to be null when created from ACE Message Blocks. Ugh. It took an embarassingly long time to understand what was going wrong. Basically: I was downcasting something that was never a NavSolMsgBlock to begin with, although it certainly looked like it.
  - Lesson learned: subclassing ACE Message Blocks is a bad idea, it creates a false sense of security. Better to work strictly within the Message Block model, and create an auxiliary class of utility functions for packing and unpacking navigation solutions into and out of a message block.
- The controller is running, everything up to and including fetching camera data, computing exterior orientations, driving the gimbal, listening to the Applanix, and so on. Many threads; should scale well to the multiprocessing system in the plane. It's all working smoothly as designed; I need to draw it so I can describe it better, since it's mutated quite a bit since the whiteboard design.
- This is a big milestone. Now I can get back to the CORBA work that I thought I was getting back to days ago. :-/ But I don't expect the CORBA work to be hard; we've been down that road before many times.
- Some things that ought to be parameters, like camera boresights, aren't. They're just compiled into the code. I'll make them tweakable later.
- 5am. Ugh. Need to catch some sleep before our 10am meeting.

BobKrzaczek - 19 Apr 2005
- Controller is working, multi-threaded, as intended.
- ScottLawrence will start integrating camera drivers tomorrow (20 Apr).
- BillHoagland will start integrating EO calculations tomorrow (20 Apr).
- I'll continue developing the communications further. Remaining mini-tasks:
  - Correctly unpack group 206 and 207 records, send real (not test) data to the underlying camera services. I've written them and tested them with faked group 5 data, so I can know even before we hook it up to the Applanix that the messaging will "do the right thing".
  - Add calls to the camera driver for unpacking real hardware data and sending it along to the rest of the ADP.
  - Add "record to file" to the camera service object.
  - Integrate the TAO event reactor with the ACE reactor. I can probably shortcut this for now by making the controller "send only". The only downside is that you won't be able to easily pause the ADP during flight turns and such. Later I can plug the TAO event reactor in and get things responding to messages from the GUI during the flight. But I don't want to hold up flights any longer.

BobKrzaczek - 12 Apr 2005
- Ahhhh... the problem is that adding a double to an ACE_Time_Value doesn't quite work the way you might expect it to. There is no operator+ defined for ACE_Time_Value that takes a double; nor is there a constructor that directly takes double. There are others, though, and you silently lose the fractions of a second when you try this. Oi. So, by redefining all my simulator delays as time vals instead of doubles, things work.
- The driver object is working correctly. I'm driving a simulated gimbal (that takes 1.0 sec to move) and four simulated cameras (that each take 0.30, 0.25, 0.20, and 0.15 sec to integrate), and the loop adjusts for the times correctly on each iteration. It's good to 1/100th of a second. That's a fixed skew, by the way: if you've asked for a 4 second cycle time, you get (in real time) 4.01 seconds. I'm going to see if I can't coax that out of the system.
- The overhead turns out to be in the combination of getting the current time and sleeping. One approach I've tried is to sample the calls before entering the loop, and then adjusting all sleeps by that overhead sample. It works remarkably well; my skew drops from +0.01 to -0.0001. Two orders of magnitude; that's pretty good, I say. I'm going to try an adaptive approach, though, just to see what it can do for me.
- Nope; the adaptive skew adjustment is too severe. It satisfies the timing over the long run, but there's too much jitter in the loop from trigger to trigger: instead of firing every four seconds, it winds up firing once, waiting 2 seconds, firing, waiting 6 seconds, firing, waiting 2, and so on. It succeeds at the macro level, but fails trigger-to-trigger. I know I could damp the skew adjustment, but I don't think it's worth it. Pre-sampling the system overhead is simpler, and yields a good enough correction; I think we'll go with that.
- Did some code cleanup, I'm outta here for the night. Tomorrow I'll add the network listener for the Applanix back in, after I fix the ACE Reactor startup.

BobKrzaczek - 11 Apr 2005
- Been a while, looks like I need to be writing my status down again.
- Got confirmation from Jason on the cameras. Despite what I was told before, the Indigo API has no idea if the camera is ready to fire or recently cleared or anything like that. All it knows is if the camera is integrating at present, or not. Actually, that works fine for me, as long as I have that nugget of information I can derive the rest when I need it.
- But it's likely that the support for the opportunistic camera triggering makes the other info moot, but depends on knowing if the cameras are busy. Funny how that works out.
- Got the main driver loop doing in the controller, but my initial tests make it seem like it's not pausing as long as it should after the test cameras fire. Need to introduce a really pregnant pause into the test cameras and see what that does.
  - Change void* arg argument of TestCamera^? ctor to accept a pointer to a double.
  - Change computation of done_exposing_at to use this argument.
- On the other hand, the gimbal logic looks sound.
- Other nice thing: the driver loop runs self contained in its own thread, doesn't need nor depend on the ACE Reactor, and thus shouldn't interfere at all with the CORBA hooks. But I need to make this loop something that can be switched on and off externally; ultimately, via CORBA. I'll probably just add a lock that CORBA can acquire/release when it wants the system to run.
- 1:45am, going home.

HarveyRhody - 10 Feb 2005
- Image registration files have been uploaded to Vulcan C:\harvey\bbreg. The file also contains an IDL script file imgreg that you can run by typing @imgreg at the IDLDE command line. This illustrates how to load an image and use the registration LUT files to do the radial distortion correction and the BB registration. Loading a different image file amounts to editing the directory and image index strings.
- The images need to be padded by adding two rows of pixels to the bottom to make the array 640x512. The LUTs won't work with 640x510 images. The images also have the first two columns replaced by average values because they contain junk. This is fixed in the new camera drivers. It would also be ok to replace the first two columns with any convenient constant.
- All "T" files are 3 columns by 327680 rows of Long Integers. All "C" files are the same size, but of floats.
  - - SWIR distortion correction uses TS512.dat and CS512.dat.
    - MWIR distortion correction uses TM512.dat and CM512.dat.
    - LWIR distortion correction uses TL512.dat and CL512.dat.
    - MWIR to SWIR registration uses TMS512.dat and CMS512.dat.
    - LWIR to SWIR registration uses TLS512.dat and CLS512.dat.
- Short algorithm description. Let A be an empty 640x512 array and let B be an image array (any kind of numbers) of the same size.
  - - For k=0L,327679 DO A[k]=B[T[0,k]]*C[0,k]+B[T[1,k]]*C[1,k]+B[T[2,k]]*C[2,k]

Row k of T contains the indexes and row k of C contains the weights to calculate the value for position k in array A. A row of C may be all zeros if it would correspond to a non-existent pixel. Oterwise each row of C adds up to 1.0 so the above formula can be reorganized to eliminate one multiplication.

- The process of generating the tables is not complicated if the coefficients for the distortion correction and projective transform are available. We may need to regenerate at least the projection tables as we get more refined measurements of image registration. That should not affect any of the registration code!

Older items can be found in ProjectDiary2004

fireTest.pdf: Illustrations of fire detection results

LIAS

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback