Skip to end of metadata
Go to start of metadata

[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 (smile)

[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 (smile) 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: (smile) 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 it's only on the first capture, right?

[11:01:26 CDT(-0500)] <Justin_o> but that will just be for the first capture

[11:01:30 CDT(-0500)] <Justin_o> yes

[11:02:45 CDT(-0500)] <jhung> But for the web-user, they will only have to experience this delay once. The only way if this were to happen more than once in a session is if someone were using the restful API directly, correct?

[11:03:55 CDT(-0500)] <Justin_o> jhung: hmm.. i guess if they go back to another page or something.. and probably depending on how stereo works to verify the validity of the cameras

[11:05:59 CDT(-0500)] <jhung> justin_o: But checking for validity of the cameras for stereo will likely only happen before calibration. So either way, the delay is unlikely / rare.

[11:06:15 CDT(-0500)] <jhung> So this makes me think that auto-unlocking is acceptable. Does that make sense?

[11:06:28 CDT(-0500)] <Justin_o> jhung: i think so.. we'll go with that

[11:08:19 CDT(-0500)] <jhung> great justin_o. Thanks!

[11:25:29 CDT(-0500)] <alexn> colinclark: I made some changes to https://github.com/fluid-project/videoPlayer/pull/58 . For interim step - there are functions to setup staticEnvironment, run tests and finally clear up after each test. This code change is only for VideoPlayerHTML5CaptionatorTests. I want to know what you think before changing other test files.

[13:01:15 CDT(-0500)] <jhung> justin_o, cindyli - I just thought of another error we need to catch.

[13:01:49 CDT(-0500)] <jhung> in stereo capture, it's possible that the user disconnect both cameras and plug in a support pair of a different model.

[13:02:08 CDT(-0500)] <jhung> We need to catch this and encourage the user to recalibrate.

[13:07:10 CDT(-0500)] <cindyli> jhung: ya, that is on our list. once any of the cameras is disconnected, no matter if it's reconnected afterwards, the recalibration is encouraged as the camera might have been moved. is that right?

[13:07:36 CDT(-0500)] <jhung> yep.

[13:07:52 CDT(-0500)] <jhung> But should we have a special case for the different model scenario?

[13:09:39 CDT(-0500)] <cindyli> jhung: once the cameras are reconnected, the different ports will be assigned as well as a new set of captures anyway. is it necessary to make the special case for that?

[13:10:40 CDT(-0500)] <cindyli> Justin_o: what do you think?

[13:14:14 CDT(-0500)] <Justin_o> cindyli: we should try to see what happens when we use the usb ports directly on your computer

[13:14:18 CDT(-0500)] <Justin_o> instead of through the hub

[13:14:55 CDT(-0500)] <jhung> ^justin_o, cindyli and I are talking about a special case of camera reconnection...

[13:15:35 CDT(-0500)] <jhung> what if the user replaces the cameras with a different pair of supported cameras? Should the user be presented with a different error message, even though the course of action should be the same.

[13:17:43 CDT(-0500)] <jhung> For example, when the user reconnects a different model, an error message can say: "Different Cameras Detected. Run calibration to ensure proper results." Otherwise if we go the generic route, the error message will say "Camera Reconnected. Run calibration again if the cameras moved or changed."

[13:31:07 CDT(-0500)] <cindyli> jhung: Justin_o is trying with a desktop to make sure gphoto behaves same in the way that it always re-assign port at a disconnection, rather than just in a VM. Regrading the case you mentioned that the cameras are replaced while they stay connected, I agree it would be helpful for users if we auto-detect it and encourage the recalibration. Our documentation should make it clear that the users would need to recalibrate whenever any of the c

[13:32:01 CDT(-0500)] <jhung> ok

[13:36:43 CDT(-0500)] <cindyli> jhung: Justin_o's got the test result that even if the USB cable stays connected, if you unplugged camera from the other end, this is considered a disconnection and a new port will be assigned when the camera is put back. so seems we don't need to make a special case for camera switch

[13:37:04 CDT(-0500)] <jhung> ok

[14:33:14 CDT(-0500)] <Justin_o> cindyli: i pushed up my code for the function to return a list of image paths by index. I haven't yet written any tests.. should probably do some more refactoring of it too.. it could probably be a utility that function and then it could be called by something in convention to wrap up the data into a dictionary.. i'll have to work this out a bit more tomorrow, but you can try it out now if you need to..

  • No labels