fluid-work IRC Logs-2012-09-17

Owned by Fluid IRC Log Bot
Last updated: Sept 17, 2012Version comment

[02:16:24 CDT(-0500)] <thealphanerd> shana tova

[07:59:04 CDT(-0500)] <jhung> cindyli and justin_o: do you want to meet some time this morning to discuss Capture UI?

[07:59:41 CDT(-0500)] <Justin_o> jhung: sure..

[08:00:09 CDT(-0500)] <jhung> 10a after coffee walk?

[08:01:02 CDT(-0500)] <Justin_o> jhung: sounds good

[08:15:39 CDT(-0500)] <cindyli> jhung, Justin_o, fine with me

[08:15:55 CDT(-0500)] <jhung> great

[08:16:56 CDT(-0500)] <jhung> justin_o and cindyli, I'm going to be updating the timeline with the feedback from the IUPR team.

[08:17:12 CDT(-0500)] <cindyli> ok. thanks, jhung

[08:19:07 CDT(-0500)] <Justin_o> jhung: thanks

[08:29:23 CDT(-0500)] <Justin_o> cindyli: have you pushed up all of your changes to your bitbucket repo?

[08:29:49 CDT(-0500)] <cindyli> Justin_o: your bitbucket repo is the latest

[08:30:12 CDT(-0500)] <Justin_o> cindyli: oh (smile) i guess i'm still trying to remember what happened on Friday

[08:32:23 CDT(-0500)] <Justin_o> cindyli: right.. remember now.. we left off working on the config file

[08:32:34 CDT(-0500)] <Justin_o> and were experimenting with ways to add custom configuration to it

[08:32:43 CDT(-0500)] <Justin_o> i guess we need to decide on a namespace for our changes

[08:33:42 CDT(-0500)] <cindyli> yes, exactly, Justin_o

[09:07:48 CDT(-0500)] <Justin_o> cindyli, jhung: i'm back now

[09:08:13 CDT(-0500)] <jhung> k. give me a sec justin_o cindyli.

[09:08:21 CDT(-0500)] <jhung> I'll ping you both in a minute

[09:08:37 CDT(-0500)] <Justin_o> jhung: sure, sounds good

[09:12:54 CDT(-0500)] <jhung> cindyli, justin_o, ready. Skype?

[09:13:09 CDT(-0500)] <cindyli> ya, jhung

[09:14:41 CDT(-0500)] <cindyli> Justin_o is not at his desk. let's wait, jhung

[09:15:00 CDT(-0500)] <jhung> okay

[09:15:50 CDT(-0500)] <Justin_o> jhung: are you screen sharing?

[09:15:55 CDT(-0500)] <jhung> yep

[09:16:07 CDT(-0500)] <Justin_o> i guess cindyli and I should share a machine

[09:16:15 CDT(-0500)] <jhung> sure

[09:16:54 CDT(-0500)] <jhung> should I call you justin_o?

[09:17:37 CDT(-0500)] <Justin_o> jhung: we're switching rooms

[09:48:47 CDT(-0500)] <jessm> fluid-everyone: jameswy just showed me that our wiki got shrinkidinked. probably a template issue we'll need to have a look at in the next few days

[09:49:02 CDT(-0500)] <colinclark> jessm: Yes, that's right

[09:49:15 CDT(-0500)] <colinclark> It looks like our custom theme is incompatible with the latest Confluence

[09:49:24 CDT(-0500)] <colinclark> and it might be time to consider if we even like our custom theme very much

[09:49:26 CDT(-0500)] <colinclark> (wink)

[09:49:37 CDT(-0500)] <jessm> colinclark: i was thinking the very same thing

[09:49:43 CDT(-0500)] <jessm> custom comes with costs

[09:49:48 CDT(-0500)] <jessm> this is one of them

[09:51:17 CDT(-0500)] <colinclark> cool

[10:27:18 CDT(-0500)] <jhung> cindyli, justin_o: looks like calibration is already very optimized. So 6 minutes to run calibration is as fast as we're going to get.

[10:27:58 CDT(-0500)] <jhung> also, 22 pairs for calibration accounts for error. If you have 22 pairs, 5 pairs can be "bad" (i.e. grid not completely visible) and calibration would still work.

[10:28:49 CDT(-0500)] <Justin_o> jhung: okay.. thanks

[10:29:07 CDT(-0500)] <Justin_o> lets hope people don't have to calibrate often (smile)

[10:43:39 CDT(-0500)] <alexn> michelled: this is the JIRA http://issues.fluidproject.org/browse/FLUID-4787 and this is the commit which got merged into demo branch cc955fe. I will try to find a link in a github for it

[10:44:26 CDT(-0500)] <michelled> thx alexn

[10:44:56 CDT(-0500)] <alexn> michelled: https://github.com/fluid-project/videoPlayer/commit/cc955fe12a02f641a3165967257cb21159498ef4

[10:46:31 CDT(-0500)] <michelled> alexn: FLUID-4582 is about adding UIO to the video player demo - Bosmon had to do some refactoring of the code to make that possible

[10:46:46 CDT(-0500)] <alexn> great

[10:48:14 CDT(-0500)] <alexn> michelled: it could be split into few separate ones though

[10:48:26 CDT(-0500)] <alexn> I dunno just an idea (smile) for any future work like that

[10:48:57 CDT(-0500)] <michelled> yes, I agree - we should work in small pieces where ever possible

[10:50:22 CDT(-0500)] <alexn> michelled: thanks to SourceTree I managed to update file by file from 1 commit to another to narrow down the issue. Even though I'm trying to stay away from the SourceTree as much as I can (smile)

[13:28:30 CDT(-0500)] <Justin_o> jhung_away, cindyli: it doesn't look like we can have the cameras capture simultaneously.. the closest i found was this suggestion, which seems a bit of a hack for our particular use case http://comments.gmane.org/gmane.comp.multimedia.gphoto.user/4472

[13:32:46 CDT(-0500)] <jhung_away> justin_o: hmmm… that's not ideal. :/

[13:33:00 CDT(-0500)] <cindyli> Justin_o: ok, seems we have to manually trigger the cameras one after the other

[13:33:34 CDT(-0500)] <jhung> I guess it'll be like how we did it in Deca 0.4

[13:33:46 CDT(-0500)] <Justin_o> jhung, cindyli: yep

[13:34:09 CDT(-0500)] <jhung> At least capturing happens fairly quickly. In the grand scheme, it'll feel blazingly fast compared to dewarping and calibration. (big grin)

[13:36:25 CDT(-0500)] <Justin_o> jhung: that's true (smile) calibration is going to be such a pain to have to trigger 22 captures and then wait for 6 minutes for 6 minutes while they process

[13:36:44 CDT(-0500)] <jhung> I know. :/

[13:52:17 CDT(-0500)] <Justin_o> jhung, cindyli: (sad) if you specify a capture with a port that doesn't exist, it doesn't fail.. it just picks one of the existing cameras

[13:52:39 CDT(-0500)] <jhung> justin_o: no error?

[13:52:39 CDT(-0500)] <cindyli> interesting

[13:52:53 CDT(-0500)] <Justin_o> jhung: no error

[13:53:59 CDT(-0500)] <Justin_o> jhung: if there are no cameras then it complains, but that's it

[13:54:21 CDT(-0500)] <cindyli> Justin_o: everytime before firing a capture, we check if the port is still available

[13:54:30 CDT(-0500)] <Justin_o> cindyli: right.. so i guess that's enough

[13:54:43 CDT(-0500)] <jhung> okay that sounds okay.

[14:12:32 CDT(-0500)] <jhung> justin_o: Is it possible that we display any given image? Example: After user deletes Image #3, Image #2 should be displayed.

[14:13:27 CDT(-0500)] <Justin_o> jhung: you mean if they delete the existing image, then the preview reverts to show the one before?

[14:15:53 CDT(-0500)] <Justin_o> cindyli: what do you think of calling the multi camera captures function "captures"

[14:16:00 CDT(-0500)] <Justin_o> the current single capture is called "capture"

[14:16:09 CDT(-0500)] <Justin_o> do you think that would be confusing and/or error prone

[14:17:10 CDT(-0500)] <jhung> @justin_o: yep.

[14:18:45 CDT(-0500)] <Justin_o> jhung: hmm… in our current design of the server it probably won't be so trivial..

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

[14:19:20 CDT(-0500)] <Justin_o> jhung: so what happens is that the captureIndex always increments, and a separate counter for number of captures is kept separately

[14:19:42 CDT(-0500)] <Justin_o> jhung: that way someone could theoretically delete an image from anywhere in the stack

[14:19:56 CDT(-0500)] <Justin_o> jhung: the consequence of this is that we don't really know what the previous image is

[14:19:57 CDT(-0500)] <cindyli> Justin_o: captures sounds and looks quite similar with the one without "s". what do you think about "multiCaptures"? too long?

[14:20:52 CDT(-0500)] <Justin_o> i was thinking about something like that too, but am a bit worried that people may confuse it with capturing multiple times from the same camera.. although captures doesn't help that either

[14:21:00 CDT(-0500)] <Justin_o> cindyli: maybe multiCameraCapture

[14:21:16 CDT(-0500)] <cindyli> ok, Justin_o

[14:21:24 CDT(-0500)] <Justin_o> cindyli: thanks

[14:21:27 CDT(-0500)] <cindyli> np

[14:26:25 CDT(-0500)] <jhung> justin_o: okay. I'll see if I can design something that doesn't require showing the previous capture.

[14:28:22 CDT(-0500)] <Justin_o> jhung: thanks.. if you really need it, cindyli and i can rework the server spec

[15:19:25 CDT(-0500)] <Justin_o> cindyli: i'm heading out now but i added a multi camera capture function to the cameraInterface

[15:19:32 CDT(-0500)] <Justin_o> it's pushed to my bitbucket repo now

[15:31:21 CDT(-0500)] <alexn> colinclark: I think I found another flaw in captionator

[15:32:02 CDT(-0500)] <alexn> colinclark: it loads all captions and tracks asynchronously but there is no callback to call when the load is complete

[15:32:41 CDT(-0500)] <alexn> colinclark: I'm writing tests for our caption part in the videoPlayer and have to write setTimeout to be sure that captions are loaded

[15:32:44 CDT(-0500)] <alexn> (sad)

[15:32:48 CDT(-0500)] <alexn> very awful