fluid-work IRC Logs-2012-09-21

[08:14:53 CDT(-0500)] <Justin_o> cindyli: hello.. i've refactored the get and set methods in model.py

[08:14:53 CDT(-0500)] <Justin_o> https://bitbucket.org/jobara/decapod-0.7-server-iteration1/src/07a03f27e6a3/utils/model.py

[08:15:21 CDT(-0500)] <Justin_o> cindyli: any thoughts

[08:19:08 CDT(-0500)] <Justin_o> cindyli: oops forgot to change get.. one second

[08:22:08 CDT(-0500)] <Justin_o> cindyli: okay it's up there now

[08:43:16 CDT(-0500)] <cindyli> it looks great, Justin_o

[08:43:43 CDT(-0500)] <Justin_o> cindyli: thanks.. i'm going to clean up the our changeApplier a bit too… did you want any changes there

[08:43:56 CDT(-0500)] <cindyli> no, Justin_o

[08:44:03 CDT(-0500)] <Justin_o> for example would you prefer to get something else passed into the event listener

[08:48:39 CDT(-0500)] <cindyli> looks like adding a new element onto a dict is handled by requestUpdate, which is fine. cannot think of anything to add, Justin_o, what you have is quite adequate i think

[08:56:55 CDT(-0500)] <Justin_o> cindyli: thanks.. i'm about to push up some refactored code for the removal, the only functional change would be that if you try to remove something that isn't there, it won't trigger the onModelChanged event

[08:57:15 CDT(-0500)] <cindyli> ok, Justin_o

[08:59:49 CDT(-0500)] <Justin_o> cindyli: it's all up now

[09:00:07 CDT(-0500)] <cindyli> thanks, Justin_o, i will merge it in

[09:00:18 CDT(-0500)] <Justin_o> cindyli: i'll pull down your changes and refactor the exporter to use the store we set up yesterday

[09:00:31 CDT(-0500)] <Justin_o> cindyli: let me know after you've merged and i'll pull down your merged changes

[09:07:52 CDT(-0500)] <cindyli> Justin_o: done, merged and pushed into https://bitbucket.org/cindyli/decapod-server-0.7-1

[09:08:20 CDT(-0500)] <Justin_o> cindyli: thanks

[09:08:38 CDT(-0500)] <cindyli> Justin_o: i will fix mockCameraInterface to parameterize the path to the mock images

[09:09:20 CDT(-0500)] <Justin_o> cindyli: that's great thanks..

[09:09:30 CDT(-0500)] <cindyli> np

[09:11:35 CDT(-0500)] <jhung> cindyli and justin_o: I have some more info about stereo calibration.

[09:12:27 CDT(-0500)] <jhung> We are using OpenCV for calibration so I looked up some examples. It seems the typical calibration routine involves the user keeping the cameras in a fixed position and the user moves the pattern around in front of the cameras. http://blog.martinperis.com/2011/01/opencv-stereo-camera-calibration.html

[09:13:12 CDT(-0500)] <jhung> Makes me wonder if we should re-think our approach...

[09:13:15 CDT(-0500)] <Justin_o> jhung: okay.. i think that's what we had initially though would be the approach

[09:13:22 CDT(-0500)] <jhung> yeah

[09:13:45 CDT(-0500)] <Justin_o> jhung: so the problem is having to capture while changing the pattern position?

[09:14:04 CDT(-0500)] <jhung> Justin_o: so maybe we ask the user to mark the edges of the frame of both cameras, and then have them move the pattern around in front until we get 25 samples?

[09:14:17 CDT(-0500)] <jhung> yeah. So maybe automatic countdown?

[09:14:55 CDT(-0500)] <Justin_o> jhung: the marking part might not be so easy either

[09:15:38 CDT(-0500)] <jhung> true justin_o. But it doesn't have to be exact. Just so they know roughly where the boundaries are.

[09:16:15 CDT(-0500)] <Justin_o> jhung: also i guess we should suggest that they mount the pattern to something rigid enough so that it doesn't curl when not lying flat to the surface

[09:16:26 CDT(-0500)] <jhung> The alternative is to have them move the tripod / cameras around which may have undesirable effects. Also like you said yesterday, there may not be enough room.

[09:16:42 CDT(-0500)] <jhung> Also from what I've been reading from OpenCV, a wide variety of shots is desirable.

[09:16:54 CDT(-0500)] <jhung> yes exactly justin_o.

[09:17:13 CDT(-0500)] <jhung> I figure the prep work is easier than adjusting the hardware during calibration.

[09:17:31 CDT(-0500)] <jhung> Also re calibration is easier.

[09:17:40 CDT(-0500)] <jhung> Because camera is fixed.

[09:18:24 CDT(-0500)] <jhung> and the user would have already marked boundaries to redo the calibration.

[09:19:17 CDT(-0500)] <Justin_o> jhung: true, that's a good benefit

[09:19:33 CDT(-0500)] <Justin_o> probably will help with capture too if they have the boundaries marked

[09:19:45 CDT(-0500)] <jhung> Yep

[09:20:58 CDT(-0500)] <jhung> So there are some possible issues arising from this approach:

[09:21:02 CDT(-0500)] <alexn2> colinclark: I managed to resolve FLUID-4793 and have a pull request https://github.com/fluid-project/videoPlayer/pull/61 all details are in the JIRA. Also, michelled I added FLUID-4796 and FLUID-4797 since I stumbled upon them while trying to fix FLUID-4793, managed to fix one of them and send a pull request but second is still present.

[09:21:25 CDT(-0500)] <jhung> 1. The user may be more prone to errors (may not be ready when the cameras fire).

[09:22:02 CDT(-0500)] <jhung> 2. How many shots do we need given the increased error rate?

[09:22:30 CDT(-0500)] <jhung> 3. The server architecture will need to change to accomodate automatic / countdown timer.

[09:22:43 CDT(-0500)] <Justin_o> jhung: i'm not sure we need the countdown timer

[09:23:05 CDT(-0500)] <Justin_o> jhung: we just get them to set it, take a picture.. repeat

[09:23:13 CDT(-0500)] <alexn2> colinclark: I also put text "(feedback)" http://wiki.fluidproject.org/display/fluid/Floe+Iteration+Plan for the pull requests for which I got comments on and currently working. Other 6 are still waiting for a review so let me know when you have time to look into them.

[09:23:37 CDT(-0500)] <jhung> so justin_o: one hand holding the pattern while the other presses the capture button?

[09:23:47 CDT(-0500)] <Justin_o> jhung: no, just leave it there

[09:24:13 CDT(-0500)] <Justin_o> and for the raised ones, they can just put something under the calibration pattern to prop it up

[09:25:49 CDT(-0500)] <Justin_o> this would also prevent the persons hand being in the calibration captures

[09:26:01 CDT(-0500)] <jhung> hmmm but we need a variety of positions justin_o, so the user will need to use different things to do the propping.

[09:27:17 CDT(-0500)] <Justin_o> jhung: not necessarily.. they could probably just use one thing and change its position.. so think of a little block.. if we lean the capture board against it at different angles, and different positions it should get your effect

[09:27:51 CDT(-0500)] <Justin_o> jhung: also, we could design a cardboard backing template that could have cutout tabs for the different propping orientations

[09:28:05 CDT(-0500)] <jhung> hmmm...

[09:33:31 CDT(-0500)] <Justin_o> cindyli: okay.. i renamed Events to Firer

[09:33:44 CDT(-0500)] <cindyli> thanks, Justin_o

[09:34:58 CDT(-0500)] <Justin_o> cindyli: i've merged in your changes now too, thanks

[09:35:18 CDT(-0500)] <cindyli> np, i've merged in your renaming, Justin_o

[09:35:33 CDT(-0500)] <Justin_o> cindyli: thanks

[09:35:37 CDT(-0500)] <cindyli> np

[09:43:47 CDT(-0500)] <cindyli> Justin_o: after looking into the parameterizing the mock image path, I think the proper way is to make the test has its own mock image dir, so that, 1. keep the interface of cameraInterface and mockInterface in sync; 2. separate out the data of regular process and tests. any thoughts?

[09:46:03 CDT(-0500)] <Justin_o> cindyli: it would probably be the simplest solution to those, the only downside is that we'd have to carry around 2 copies of the same files

[09:47:00 CDT(-0500)] <jhung> justin_o, cindyli - how quickly can we capture stereo images?

[09:47:00 CDT(-0500)] <Justin_o> cindyli: at this point though the duplication probably isn't too costly

[09:47:19 CDT(-0500)] <cindyli> agree, Justin_o.

[09:47:20 CDT(-0500)] <Justin_o> cindyli: i guess if we need more ima