Meeting on September 8, 2009

Agenda

1. Attendance
2. Announce agenda
3. Approve August 24, 2009 Meeting Notes. Ask for review and address any problems seen in the notes.
4. Discuss and vote (as necessary) on wizard improvements.
5. Discuss alternate tie point list implementations.
6. Open Questions
7. Summary and closing

Notes

Attendance

• tclarke
• rforehan
• mconsidi
• dadkins
• dsulgrov
• raevans

Summary

The wizard improvements were discussed and there seemed to be no dissenting ideas so tclarke will update the OPTICKS-713 design to reflect the feedback. Interested parties can watch the JIRA issue for changes and final design information.

Ideas and questions about tie points were brought up and discussion will move to the mailing list. There will not be a redesign immediately but a general direction is needed for the simple API design discussions.

Decisions

tclarke will update the OPTICKS-713 design.

Logs

2009-09-08T11:00:40 <tclarke> here
2009-09-08T11:00:42 <rforehan> here
2009-09-08T11:00:43 <mconsidi> here
2009-09-08T11:00:44 <dadkins> here
2009-09-08T11:00:45 <dsulgrov> here
2009-09-08T11:00:48 <tclarke> 1. Attendance
2009-09-08T11:00:48 <tclarke> 2. Announce agenda
2009-09-08T11:00:48 <tclarke> 3. Approve August 24, 2009 Meeting Notes. Ask for review and address any problems seen in the notes.
2009-09-08T11:00:48 <tclarke> 4. Discuss and vote (as necessary) on wizard improvements.
2009-09-08T11:00:48 <tclarke> 5. Discuss alternate tie point list implementations.
2009-09-08T11:00:48 <tclarke> 6. Open Questions
2009-09-08T11:00:49 <tclarke> 7. Summary and closing
2009-09-08T11:00:50 <raevans> here
2009-09-08T11:00:53 <tclarke> the last meeting notes are here https://wiki.ballforge.net/confluence/display/opticksChat/August+24%2C+2009+Meeting+Notes
2009-09-08T11:00:58 <tclarke> please fix any errors
2009-09-08T11:02:09 <tclarke> ok, the first item deals with wizard improvements....this is JIRA issue OPTICKS-713
2009-09-08T11:02:25 <tclarke> I posted to the mailing lists about this
2009-09-08T11:02:28 <tclarke> and placed a prototype build on builds.ballforge.net
2009-09-08T11:02:43 <tclarke> I received some feedback on the design and wanted to finalize the discussions here
2009-09-08T11:02:46 <tclarke> this involves two main pieces
2009-09-08T11:02:53 <tclarke> allowing the user to enter wizard value item values when the wizard executes
2009-09-08T11:03:03 <tclarke> and allowing the wizard designer to more easily create value items.
2009-09-08T11:04:29 <tclarke> the second part seems pretty straight forward and had no major feedback
2009-09-08T11:04:41 <tclarke> basically, you'll be able to double click an input node and the wizard builder will automatically create a value item
2009-09-08T11:04:52 <tclarke> any further thoughts on part 2 before I summarize part 1?
2009-09-08T11:05:12 <tclarke> ok, part 1
2009-09-08T11:05:17 <tclarke> a number of methods have been discussed to solve this one
2009-09-08T11:06:27 <tclarke> the prototype modifies the functionality of value item
2009-09-08T11:06:33 <tclarke> when a value item is in batch mode, it behaves as it does now
2009-09-08T11:06:48 <tclarke> in interactive mode, the user is prompted for a value at execution time...if a value is set in the value item before hand, it is used as a default
2009-09-08T11:07:01 <tclarke> the prototype uses a wizard dialog (next, back, finish buttons) for input
2009-09-08T11:07:20 <tclarke> this was mostly for ease of implementation....it seemed like those in the discussion agreed some sort of grouping is needed
2009-09-08T11:08:42 <tclarke> one idea was to allow multiple items to have the same "ordering" number
2009-09-08T11:08:59 <tclarke> another idea was to create a special "grouping" operation in wizards to explicitly group
2009-09-08T11:09:08 <tclarke> a third was to create a new kind of wizard item which contains multiple values
2009-09-08T11:09:14 <tclarke> thoughts?
2009-09-08T11:09:33 <dadkins> or to use consecutive ordering numbers to implicitly group
2009-09-08T11:10:51 <tclarke> yes...correct
2009-09-08T11:11:05 <tclarke> personally, I like that idea....there would need to be significant changes to the wizard framework to support multiple items with the same order
2009-09-08T11:11:14 <tclarke> but consecutive ordering gives the same effect with only minor changes
2009-09-08T11:13:07 <dsulgrov> what are the Back and Next buttons for?
2009-09-08T11:13:13 <tclarke> to cycle through available value items
2009-09-08T11:13:20 <tclarke> i.e. I have 3 values I want input on....each would show up on a different page
2009-09-08T11:13:22 <dsulgrov> when would the dialog be displayed?
2009-09-08T11:13:28 <dsulgrov> i.e. which spot in the execution order
2009-09-08T11:13:35 <tclarke> currently, it's at the beginning of execution
2009-09-08T11:13:42 <tclarke> with grouping, it would display when that group's execution position is executing
2009-09-08T11:13:49 <dsulgrov> this might not be desirable if the user is waiting for output from one item before specifying input for another item
2009-09-08T11:15:27 <tclarke> my proposed changes would be to use the consecutive item ordering
2009-09-08T11:15:41 <tclarke> an put all items from a single group on a dialog...it would have a max size so if you had a lot of items in a group you might get scroll bars
2009-09-08T11:15:48 <tclarke> the dialog would show up when the first item in the group is evaluated
2009-09-08T11:15:52 <dsulgrov> yes, it seems like having multiple wizard pages would only be appropriate with consecutive value items
2009-09-08T11:17:29 <tclarke> I'd also add value item editors for more types
2009-09-08T11:17:32 <dsulgrov> but I think that we shouldn't "run"| the value item dialog before its spot in the execution order
2009-09-08T11:17:45 <tclarke> specifically, DataElements....you'd get a selection box for the data element type requested with all the available elements of that type
2009-09-08T11:17:48 <tclarke> agreed
2009-09-08T11:17:59 <dsulgrov> when using multiple pages, we should probably list that value item name and execution order number on each page
2009-09-08T11:18:01 <tclarke> I'd disallow interactive value items for certain types which can't be edited (like Progress)
2009-09-08T11:18:11 <tclarke> it's currently listing the name....it shouldn't be difficult to add the execution order
2009-09-08T11:18:25 <tclarke> currently these types can't have value items created...I'd continue that constraint
2009-09-08T11:20:07 <tclarke> any other ideas to throw in the pot?
2009-09-08T11:20:23 <tclarke> I'll write up a revised design for OPTICKS-713....anyone can review it and be informed of changes by watching the jira issue
2009-09-08T11:20:45 <tclarke> it seems there are no real contrary ideas so we won't have a formal vote to recommend a design, I'll just interpret the ideas I've received
2009-09-08T11:21:55 <tclarke> let's move on
2009-09-08T11:21:57 <tclarke> tie points....
2009-09-08T11:22:04 <tclarke> I also sent a little background info on this issue to the mailing list
2009-09-08T11:22:08 <tclarke> there was some confusion so I'll clarify
2009-09-08T11:22:25 <tclarke> I'm not planning on reimplementing tie points right now, but I'd like a general idea of how we'd like to proceed so I can reference design ideas in the simple API writeup
2009-09-08T11:22:34 <tclarke> the problem is that the currentl tie point system is designed for a specific tie point generation algorithm and coregistration algorithm
2009-09-08T11:22:49 <tclarke> I'm not sure what they are but I suspect it's eithe SIFT or something similar
2009-09-08T11:24:16 <tclarke> that detail is unimportant...the problem is that the current implementation is not general enough
2009-09-08T11:24:19 <tclarke> to be very useful outside this one set of algorithms
2009-09-08T11:24:30 <tclarke> and users can't manually create a tiepoint list without a special (currently nonexistent) plug-in
2009-09-08T11:24:38 <tclarke> even tho it appears they can until you actually try to do it
2009-09-08T11:24:48 <tclarke> I'd like to rememdy this and make tie points more useful to a broader range of algorithms
2009-09-08T11:24:54 <tclarke> anyone have input on requirements for tie points?
2009-09-08T11:26:20 <rforehan> should be able to use tie-points to warp imagery to a map.
2009-09-08T11:26:24 <rforehan> or other image
2009-09-08T11:26:27 <tclarke> specifically how....what types of warping?
2009-09-08T11:26:40 <tclarke> usually affine is a good minimum...but should it support more non-linear warping?
2009-09-08T11:26:50 <rforehan> Have to ask user base that one.
2009-09-08T11:27:09 <tclarke> I'd say the developer base is more appropriate...many analysts won't know the difference....this sort of warping is generally an algorithmic problem
2009-09-08T11:28:41 <rforehan> Then I'd like to see non-linear supported.
2009-09-08T11:29:11 <tclarke> should tie points be expandible to allow for algorithm specific data values? or should we choose a set of values (x, y target x, y confidence/error)
2009-09-08T11:29:19 <tclarke> I'm leaning towards a fixed set of values for efficiency
2009-09-08T11:29:30 <tclarke> 100k+ tie points would not be uncommon for two images with vastly different sensor geometries
2009-09-08T11:31:03 <rforehan> Fixed sounds fine to me.
2009-09-08T11:31:04 <tclarke> should we allow tieing together different frames in the same dataset? or just different datasets?
2009-09-08T11:31:14 <tclarke> I'm not sure on this one...
2009-09-08T11:31:22 <tclarke> might need more thought...but I'm leaning towards the latter
2009-09-08T11:31:38 <rforehan> different frames as in animation or bands?
2009-09-08T11:32:59 <rforehan> Nevermind, I misread that
2009-09-08T11:33:00 <tclarke> most likely an animation...but perhaps bands if you have a sensor with multiple focal planes which are represented as bands
2009-09-08T11:33:20 <tclarke> ok...I think we've thrown out enough ideas and questions to generate some discussion on the mailing lists....anything else anyone would like to add?
2009-09-08T11:33:31 <tclarke> ok, on to open discussion
2009-09-08T11:33:45 <tclarke> the Python issue I raised on the mailing list this morning and discussed on IRC has been resolved...I found a way around the problem mentioned...just wanted to follow up
2009-09-08T11:33:47 <tclarke> any other issues to discuss?
2009-09-08T11:35:31 <tclarke> ok....the only action is for me to update the OPTICKS-713 design with input from this meeting and the maling list
2009-09-08T11:35:40 <tclarke> look on dev@opticks for meeting notes...the next meeting will be two weeks from yesterday at the normal time