17:10:18 <darci> #startmeeting
17:10:18 <tota11y> Meeting started Fri Mar 22 17:10:18 2013 CET.  The chair is darci. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:10:18 <tota11y> Useful Commands: #action #agreed #help #info #idea #link #topic.
17:10:38 <darci> amber do you want to go first?
17:10:44 <john> I didn't do much due to other obligations (read: school) but I did get a chance to poke around, and have a few questions (for amber probably)
17:11:04 <darci> sure
17:11:25 <amber> ok.
17:11:49 <amber> i started working on remaking the ocvfw
17:12:05 <amber> have a rough start that i uploaded to github
17:12:21 <heidi> So how much of a "remake" is this? Can you explain a bit?
17:12:37 <amber> it would replace the existing ocvfw
17:13:02 <amber> right now it contains a camera.py, camera_backend.py and a controller
17:13:05 <darci> #info amber has a rough "first start" to a remake of ocvfw to replace the current one
17:14:00 <darci> how much are each of these fleshed out?
17:14:10 <amber> very rough stages
17:14:28 <amber> i havent had too much time to work on it due to finals
17:14:47 <john> Drexel on a quarter system?
17:14:57 <amber> yes
17:16:09 <darci> john: were you able to start documenting main
17:16:17 <john> So I looked at the source for main.py and several others in /src/, and they seem to already be documented? I've added a few lines to clarify what this or that is for, but I'm not sure if that's what you're looking for?
17:16:41 <john> Basically I'm more "commenting", not "documenting" if you know what I mean
17:17:12 <amber> i think heidi has moved it to another page
17:17:38 <amber> we still need the methods and major variables documented
17:17:51 <heidi> What did I move?
17:18:26 <amber> the mousetrap classes detail
17:18:41 <amber> i think that was your commit?
17:18:46 <heidi> The one concern that I have is that we need to do a redesign, rather than simply "converting" the existing files.
17:18:50 <john> It already has documentation -- just generate a PyDoc on it…?
17:18:53 <heidi> Yes, I did move some of the mousetrap detail.
17:18:55 <john> Example,
17:18:57 <darci> are you referring to this?
17:19:06 <john> def script(self):
17:19:06 <john> """
17:19:07 <john> Returns the main script class object.
17:19:09 <john> Arguments:
17:19:10 <john> - self: The main object pointer.
17:19:11 <john> """
17:19:12 <john> return get_script_class(self.cfg.get("scripts", "name"))()
17:19:37 <john> for example. All methods has it
17:19:40 <amber> the comments are scarce and none-descriptive
17:19:46 <heidi> Yes, right.
17:19:46 <amber> non*
17:20:37 <amber> the docs that i have up for the ocvfw are a lot more informative
17:20:47 <amber> than what pydocs will be able to generate
17:20:47 <heidi> Yes.
17:20:51 <john> I don't know what a "main script class" object is. Nor do I know you can use a pointer to main (is that even possible?)
17:21:30 <amber> i guess they are describing it as a controller class
17:21:54 <amber> it "points" to the other modules to start the program
17:23:42 <darci> john: have you seen the docs that amber has for the ocvfw?
17:24:24 <john> Yes
17:24:50 <darci> and how do they compare to the ones you've been looking at (in main for example)?
17:25:57 <john> Not much different...
17:27:41 <john> a random example;
17:27:46 <john> def get_haar_roi_points(self, haarCascade, rect, origSize=(0, 0), method=co.cv.CV_HAAR_DO_CANNY_PRUNING):
17:27:47 <john> """
17:27:48 <john> Search for points matching the haarcascade selected.
17:27:49 <john> Arguments:
17:27:51 <john> - self: The main object pointer.
17:27:52 <darci> So does it makes sense to move on to the other files and document there (in particular, the methods and major variables as amber pointed out)?
17:27:52 <john> - haarCascade: The selected cascade.
17:27:53 <john> - methode: The search method to use. DEFAULT: co.cv.CV_HAAR_DO_CANNY_PRUNING.
17:27:54 <john> Returns a list with the matches.
17:27:55 <john> """
17:28:43 <john> Sure, I'll check them out
17:28:45 <darci> sorry, my question ended up in the middle of your example
17:29:08 <amber> john, we also need to know the order that main is calling the other object
17:29:12 <amber> objects*
17:29:25 <john> what do you mean?
17:29:39 <amber> things that would help in the redesign
17:30:00 <amber> main is responsible for calling the methods to start the camera, bring up the window, etc
17:30:50 <amber> i did put up pydocs for mousetrap already, its on github under the /docs folder
17:32:33 <amber> #link https://github.com/amberheilman/mousetrap/tree/fix_install/docs/pydoc
17:32:45 <amber> it may help with the documentation
17:33:01 <john> Didn't see anything? The folder was last updated 4 years ago
17:33:41 <amber> https://github.com/amberheilman/mousetrap/tree/fix_install/docs/html
17:33:45 <amber> sorry wrong link
17:34:41 <heidi> I think that we need to reverse engineer the algorithm. We need to focus on _what_ the current algorithm is doing and not fuss the _how_ for now.
17:35:19 <amber> i dont understand?
17:36:12 <heidi> So if I understand correctly, CV2 is significantly different than CV.
17:36:34 <heidi> Different enough that we should relook at how the ocvfw works and perhaps do a redesign.
17:36:49 <heidi> And in order to do that, we need to understand what the current design does.
17:37:14 <heidi> This would typically involve creating a class diagram of the existing back end.
17:37:30 <heidi> And then a high-level algorithm for what goes on.
17:37:51 <john> Why can't we just use something like this and be done with it? http://jayrambhia.com/blog/face-tracking-with-camshift-using-opencvsimplecv/
17:38:13 <heidi> E.g.,   1. Camera focuses on forehead, 2. The center of the forehead is determined (by the app), etc.
17:38:24 * heidi looking
17:38:43 <heidi> This is still too low level.
17:39:29 <heidi> We need to do a design step that allows for future development of MouseTrap.
17:40:02 <heidi> For instance, how would the example that you provided work with tracking a finger (which is hypothetically supposed to be supported).
17:40:09 <heidi> I don't know the answer to this.
17:40:50 <heidi> But I think we need to do a high-level design then a detailed-level design.
17:41:05 <heidi> You folks have done an excellent job with the code. I'm really proud of you.
17:41:25 <heidi> And I think we've come to realizing that the existing code is too broken to be fixed.
17:41:32 <amber> yes
17:41:48 <amber> but the methodology they have is something we can replicate
17:41:50 <heidi> When that happens in a software project, rather than try to make the fix using code, the better bet is to take a step back and do design.
17:42:54 <heidi> Sure, so lets document it at a high level so that we can make sure that it is the best approach.
17:43:51 <heidi> I'm really not trying to put a damper on things and I think you're doing a great job.
17:43:56 <john> I might be wrong, but this is probably way beyond our capabilities (tracking fingers, etc). That's cutting-edge tech that MIT folks work on… heh
17:44:16 <heidi> I'm not thinking about rewriting the algorithms.
17:44:25 <amber> the fundamentals are here though john
17:44:26 <heidi> Yes, that is beyond our current capabilities.
17:44:28 <darci> I think this makes sense
17:44:34 <darci> john was looking more closely at the code in an attempt to learn Python
17:44:53 <heidi> And yes, definitely. John is doing a great job in learning a language in a difficult context.
17:44:58 <amber> they already have haars defined, which is what the mit guys do
17:46:39 <amber> so are we saying we should stop what were doing and do a high-level assessment ?
17:46:48 <amber> then come up with a design?
17:47:20 <heidi> Yes, that would be good.
17:47:44 <heidi> Sorry, I'm in a f2f meeting so I've been catching up.
17:48:11 <heidi> It seems to me that the first step is to come up with a high-level document that describes the current design.
17:48:12 <amber> ok, should i continue with my redesign attempt?
17:48:30 <heidi> I think we should do the assessment first to make sure we're going in the right direction.
17:48:51 <john> assessment of what the program does, or what the code does?
17:48:54 <amber> ok, do we have some design models to choose from?
17:50:11 <darci> heidi: have you already started doing some of this at http://foss2serve.org/index.php/MouseTrap_Dev_Help/mousetrap_internals#MouseTrap_Structure
17:50:31 <heidi> I think we need to see what we have first. What does the current code do?
17:50:33 <heidi> Yes, exactly!
17:50:48 <heidi> The diagram I did shows all of the major code units and their containment.
17:51:12 <heidi> Now we need to take the OCVFW part and do a class diagram.
17:51:38 <heidi> What are the classes/modules, their main responsibility (one-two sentences), and how are they related?
17:52:02 <heidi> A picture, I'm meaning.
17:52:16 <heidi> With boxes and arrows. UML class diagram would work.
17:52:19 <heidi> Does this make sense?
17:53:02 <amber> im not really sure, all of those things are already there
17:53:18 <heidi> Can you point me to the class diagram for OCVFW?
17:53:21 <heidi> Did I miss it?
17:53:24 <darci> don't we already have a it http://foss2serve.org/index.php/MouseTrap_Dev_Help/mousetrap_internals#OpenCV_Framework_.28ocvfw.29
17:53:55 <heidi> Yes, this is a start.
17:54:03 <heidi> But it doesn't have all of the code included.
17:54:38 <amber> they are the classes that are mostly used, besides the idms
17:54:41 <heidi> Where is the IDM stu?
17:54:46 <heidi> "stuff"?
17:54:54 <heidi> Right, I'm only getting a partial picture.
17:55:00 <darci> idm?
17:55:07 <amber> image detection module
17:55:08 <heidi> Sorry, maybe I'm slow but I need the big picture in order to understand.
17:55:13 <heidi> :-)
17:55:16 <darci> oh
17:55:56 <heidi> So it may be that we can keep the current design. But we should document it for newbies like me :-)
17:56:26 <darci> ok...it's almost 1 o'clock...thoughts for next steps?
17:56:37 <amber> document mousetrap?
17:56:39 <heidi> I'm tied up all weekend so I won't get to look at this until Tuesday.
17:56:48 <heidi> In particular, document the OCVFW.
17:56:52 <darci> should the big picture documentation that heidi started continue
17:56:58 <heidi> Yes.
17:57:38 <heidi> And yes, I need to leave at 1:00. Sorry.
17:57:51 <darci> john: do you think you can help some in this respect...especially if you start with the Pydocs?
17:58:06 <heidi> If anyone comes up with a box and line draft of what is going on in ocvfw, please circulate. And I'll do the same if I get to it first.
17:58:15 <amber> we already have an epydoc
17:58:35 <heidi> Yes, do we have a graphic as well?
17:58:42 <amber> sure heidi, i might get around to it in the next few days
17:58:45 <heidi> A box and line diagram?
17:58:56 <amber> no, it wouldnt generate
17:58:59 <heidi> Sure, that would be most helpful. And if you don't, I'll work on it next week.
17:59:03 <heidi> Right, ah, I remember this.
17:59:04 <amber> ok
17:59:10 <heidi> So lets see if we can construct one.
17:59:37 <heidi> And when we're convinced we like that design, we can go back to the code level.
17:59:48 <amber> alright
17:59:51 <heidi> :-)
17:59:59 <amber> ill make sure it gets done quickly then :)
18:00:09 <darci> ;-)
18:00:13 <heidi> I understand the process may feel a bit stop and go with some dead-ends, but we're making progress!
18:00:19 <heidi> :-)
18:00:23 <darci> yes!
18:00:25 <heidi> OK, I need to go.
18:00:31 <darci> me too
18:00:34 <heidi> Yes, I definitely feel like we're making headway.
18:00:37 <darci> thank you all!
18:00:37 <heidi> Bye all!
18:00:43 <amber> bye bye!
18:00:44 <heidi> Yes, thank you!
18:01:11 <darci> john did you still want to ask amber some questions?
18:01:22 <darci> or are you good for today?
18:01:25 <john> Already did
18:01:34 <darci> ok...then I'll end the meeting
18:01:42 <darci> bye
18:01:48 <darci> #endmeeting