fluid-work IRC Logs-2012-09-24

[08:21:42 CDT(-0500)] <jhung> justin_o and cindyli - I've been thinking over this calibration issue. I'm wondering if you guys can look into live capture?

[08:22:38 CDT(-0500)] <Justin_o> jhung: okay.. but i figure that will also be quite dependent on the camera

[08:24:08 CDT(-0500)] <jhung> that's right justin_o. Basically I want to find out if it's possible to live view both cameras and then automatically trigger a capture if it detects the grid. The detection of the calibration grid will use opencv and we'll ask Martin to help with that.

[08:24:24 CDT(-0500)] <jhung> Do a quick feasibility check.

[08:24:35 CDT(-0500)] <jhung> Try not to spend too much time. lol

[08:26:14 CDT(-0500)] <Justin_o> jhung: okay.. we'll take a look.. i'm not sure we'll be able to display it on the web page though

[08:26:30 CDT(-0500)] <jhung> Ah.

[08:27:50 CDT(-0500)] <jhung> True. I wonder if calibration can be standard app / script?

[08:29:16 CDT(-0500)] <jhung> I guess let's not think about that until we know a little more. Thanks justin_o, cindyli.

[09:31:53 CDT(-0500)] <alexn> colinclark: I have the pull request fixing timestamps in transcript JSON and VTT files as well as other files. https://github.com/fluid-project/videoPlayer/pull/62

[09:32:24 CDT(-0500)] <alexn> actually just JSON and VTT

[09:33:28 CDT(-0500)] <colinclark> ok. thanks

[09:46:15 CDT(-0500)] <Justin_o> jhung: could you chat with cindyli and I about what you want for this automatic trigger

[09:46:24 CDT(-0500)] <jhung> sure

[09:46:51 CDT(-0500)] <jhung> skype

[09:46:51 CDT(-0500)] <Justin_o> jhung: we're just going to relocate and then we can skuype

[09:46:52 CDT(-0500)] <jhung> ?

[09:46:53 CDT(-0500)] <Justin_o> skype

[09:46:58 CDT(-0500)] <jhung> okay

[10:32:57 CDT(-0500)] <jessm> fluid-everyone: standup?

[10:44:42 CDT(-0500)] <michelled> colinclark: is now a good time to meet with anastasiac and me?

[10:45:12 CDT(-0500)] <colinclark> i'm just in a call with jutta

[10:45:22 CDT(-0500)] <colinclark> but i should be free shortly

[10:45:35 CDT(-0500)] <michelled> ok, ping us when you're ready

[10:47:53 CDT(-0500)] <Justin_o> jhung: hi, cindyli and I have another question regarding the multi camera capture

[10:49:20 CDT(-0500)] <jhung> sure justin_o

[10:49:38 CDT(-0500)] <Justin_o> jhung: if you remember what we were talking about for the multi camera capture on friday..

[10:49:53 CDT(-0500)] <Justin_o> jhung: anyways.. the method requires us to lock the cameras

[10:50:11 CDT(-0500)] <Justin_o> jhung: this means that during that time you wouldn't be able to do a single camera capture, or even check the camera summary

[10:51:31 CDT(-0500)] <Justin_o> jhung: cindyli and I are trying to think of ways to manage this, we'll probably have some sort of locked flag on the server or something like that. So the question is what should happen if a user tries to access the summary for example when the cameras are locked

[10:52:07 CDT(-0500)] <Justin_o> should we just return an exception/error response and then if they want they can make another call to unlock

[10:52:27 CDT(-0500)] <Justin_o> or should it auto unlock the cameras and then perform the requested action

[10:53:10 CDT(-0500)] <jhung> justin_o: I don't quite understand why the user would care if the cameras are locked or not. Can you explain why it matters?

[10:53:26 CDT(-0500)] <Justin_o> jhung: well.. if they wanted to check the camera summary

[10:53:39 CDT(-0500)] <jhung> And why would they do that?

[10:53:40 CDT(-0500)] <Justin_o> if the cameras are locked it won't work.. we'd have to unlock them first

[10:53:58 CDT(-0500)] <Justin_o> jhung: to be able to take the captures at the same time, we have to lock the cameras

[10:54:07 CDT(-0500)] <jhung> I don't think the user will want the camera summary.

[10:54:08 CDT(-0500)] <Justin_o> most of this is hidden from the user.. and is only on the server

[10:54:29 CDT(-0500)] <jhung> All they care is if their cameras work and they can use it to capture, export, and recalibrate if needed.

[10:54:30 CDT(-0500)] <colinclark> michelled, anastasiac: Now is good. Call me up when you're ready

[10:54:41 CDT(-0500)] <Justin_o> jhung: just to be clear, not only talking about the user of the web page, but also of the RESTful webservice

[10:54:55 CDT(-0500)] <Justin_o> http://wiki.fluidproject.org/display/fluid/Proposed+Decapod+Camera+Control+Server+Architecture

[10:55:07 CDT(-0500)] <anastasiac> colinclark, michelled has stepped away for a minute when she's back, we'll give you a call

[10:55:16 CDT(-0500)] <colinclark> k

[10:55:41 CDT(-0500)] <jhung> justin_o: okay got it. I didn't know you were talking about the server API.

[10:56:04 CDT(-0500)] <Justin_o> jhung: yah.. kind of both

[10:56:21 CDT(-0500)] <Justin_o> but really just because the web works through the server api

[10:57:14 CDT(-0500)] <jhung> justin_o: locking the cameras sound okay. I think for majority of the use cases it'll be fine.

[10:57:44 CDT(-0500)] <Justin_o> jhung: okay.. but should we auto unlock.. or force the user to decide if they really want to unlock the cameras and do something else

[10:59:51 CDT(-0500)] <jhung> justin_o: auto-unlocking sounds good since having cameras locked sounds like a hassle. What are the consequences of auto-unlocking?

[11:00:24 CDT(-0500)] <Justin_o> jhung: well.. i guess the biggest consequence is that it will take a bit longer for their first capture the next time through

[11:00:47 CDT(-0500)] <jhung> how much longer justin_o?

[11:01:18 CDT(-0500)] <Justin_o> jhung: i guess the 5 seconds or so that cindyli had shaved off

[11:01:25 CDT(-0500)] <jhung> and