fluid-work IRC Logs-2012-09-13

[10:30:38 CDT(-0500)] <Justin_o> jhung: are we only supporting cameras connected by usb?

[10:43:58 CDT(-0500)] <colinclark> jhung: Any time you want, fire me links to the libraries we're using that you were wondering about

[10:44:09 CDT(-0500)] <colinclark> and if it's not too much trouble, links to places in the source code where we actually use them

[10:50:02 CDT(-0500)] <colinclark> hey alexn1

[10:50:15 CDT(-0500)] <colinclark> really sweet pull request for FLUID-4779

[10:50:17 CDT(-0500)] <colinclark> nice work

[10:50:19 CDT(-0500)] <colinclark>

[10:51:18 CDT(-0500)] <alexn1> thx colinclark ! it is sweet mostly because of your feedback

[10:51:25 CDT(-0500)] <alexn1> colinclark: and another one is coming very soon

[10:52:31 CDT(-0500)] <colinclark> cool, thanks

[12:27:43 CDT(-0500)] <jhung> colinclark: I'll send you references to lines and files once I've talked to Martin about it.

[12:28:31 CDT(-0500)] <jhung> justin_o: re: support for only USB cameras - yes.

[12:29:01 CDT(-0500)] <jhung> What other kinds of camera were you thinking of justin_o?

[12:29:53 CDT(-0500)] <Justin_o> jhung: just checking.. i suppose there could be firewire, thunderbolt… don't know if there are wifi or bluetooth cameras

[12:30:04 CDT(-0500)] <Justin_o> doubt those would have a high enough resolution anyways

[12:30:58 CDT(-0500)] <jhung> At least not for our application (although 4K thunderbolt cameras are probably sufficient .

[12:31:06 CDT(-0500)] <Justin_o> jhung:

[12:45:28 CDT(-0500)] <colinclark> jhung: In absence of links, I just dug up Martin's bitbucket and had a look myself

[12:45:40 CDT(-0500)] <colinclark> The problem library is pyVLFeat

[12:45:46 CDT(-0500)] <jhung> yes

[12:45:49 CDT(-0500)] <colinclark> which is indeed licensed under the GPL 2

[12:46:00 CDT(-0500)] <colinclark> It's a Python binding for a C library called VLFeat

[12:46:07 CDT(-0500)] <colinclark> which, interestingly enough, is BSD licensed

[12:46:25 CDT(-0500)] <colinclark> Since it's a language binding, we clearly use it as a direct linkage

[12:46:46 CDT(-0500)] <colinclark> a basic rule of thumb with the GPL is that if you link your code with GPL code, your code has to itself be distributed as GPL

[12:47:01 CDT(-0500)] <colinclark> It's often why library authors use LGPL or a non-"viral" license

[12:47:06 CDT(-0500)] <colinclark> Martin uses it one spot

[12:47:18 CDT(-0500)] <colinclark> In order to access VLFeat's sift algorithm

[12:47:25 CDT(-0500)] <colinclark> We have two options:

[12:47:47 CDT(-0500)] <colinclark> 1. Contact the authors of pyVLFeat and politely ask them if they'd consider sharing it with us under the BSD or another license

[12:48:12 CDT(-0500)] <colinclark> 2. Martin could use VLFeat directly, probably with a bit more inconvenience

[12:48:28 CDT(-0500)] <colinclark> Since he's only binding to a single function on pyVLFeat, he may not find that to be too difficult

[12:48:43 CDT(-0500)] <jhung> okay.

[12:48:46 CDT(-0500)] <colinclark> But unfortunately we can't distribute Decapod with the current dependency in place as-is

[12:48:59 CDT(-0500)] <colinclark> If we decide to go for #1, I'm happy to send a note to the authors

[12:49:07 CDT(-0500)] <colinclark> I've had a fair bit of success doing so in the past

[12:50:30 CDT(-0500)] <colinclark> He might be able to make his own Python bindings for VLFeat's sift function as easily as anything else

[12:50:38 CDT(-0500)] <colinclark> I believe Thomas has a fair bit of experience in this regard

[12:50:43 CDT(-0500)] <jhung> Ok. I'll pass that along to Martin and see what he prefers.

[12:50:45 CDT(-0500)] <colinclark> and Python programmers do this quite a bit

[12:50:46 CDT(-0500)] <colinclark> great, thanks

[12:50:58 CDT(-0500)] <colinclark> good catch, jhung

[12:51:32 CDT(-0500)] <jhung> thanks colinclark. Your dark knowledge of open source licenses has proven useful once again.

[13:05:05 CDT(-0500)] <Justin_o> jhung: cindyli and i are looking at want info to return for the cameras

[13:05:37 CDT(-0500)] <Justin_o> jhung: where are all the critical pieces of info that should be returned? do we need to return all the info the gphoto2 knows about a camera?

[13:10:22 CDT(-0500)] <jhung> Not necessary. We need MP count. Remote capture and download capability. Model.

[13:11:35 CDT(-0500)] <Justin_o> jhung: don't seem to have anything for MP count

[13:15:04 CDT(-0500)] <jhung> Resolution?

[13:16:50 CDT(-0500)] <Justin_o> jhung: don't see that either

[13:18:16 CDT(-0500)] <jhung> justin_o: really?

[13:18:19 CDT(-0500)] <jhung> oh brother.

[13:18:36 CDT(-0500)] <jhung> I guess we can do a test capture and download and check it ourselves.

[13:20:29 CDT(-0500)] <Justin_o> jhung:

[13:20:45 CDT(-0500)]

[13:21:16 CDT(-0500)] <yura> https://github.com/joyent/node/wiki/modules

[13:22:33 CDT(-0500)] <jhung> justin_o: What do you mean by that?

[13:22:45 CDT(-0500)] <colinclark> michelled, yura: Specifically, https://github.com/joyent/node/wiki/Modules#wiki-web-frameworks-static

[13:22:59 CDT(-0500)] <colinclark> It's one of those things you can whip up easily

[13:23:01 CDT(-0500)] <colinclark> but badly

[13:23:10 CDT(-0500)] <colinclark> I forget which ones seemed reasonably sensible to me

[13:23:44 CDT(-0500)] <Justin_o> jhung: directing the user to manually query the camera

[13:23:53 CDT(-0500)] <michelled> thanks colinclark

[13:24:12 CDT(-0500)] <colinclark> node-static might be the one, michelled

[13:24:30 CDT(-0500)] <jhung> justin_o: haha.

[13:24:40 CDT(-0500)] <jhung> justin_o: I don't think that will be reliable.

[13:25:08 CDT(-0500)] <jhung> System: "Please check your camera's megapixels."

[13:25:15 CDT(-0500)] <jhung> User: "Mega-what?!"

[13:25:41 CDT(-0500)] <Justin_o> jhung:

[13:25:58 CDT(-0500)] <jhung> Well, we have to do a capture-and-download test anyway...

[13:26:03 CDT(-0500)] <Justin_o> jhung: we might be able to use PIL to get the information.. well it can tell the size of an image, so we can do some math on that

[13:26:07 CDT(-0500)] <jhung> so we can determine the resolution from that.

[13:26:14 CDT(-0500)] <Justin_o> jhung: what do you mean we have to?

[13:26:20 CDT(-0500)] <jhung> Well...

[13:26:54 CDT(-0500)] <jhung> libgphoto claims to support certain cameras, but in reality you don't know unless you call the options you want through the script.

[13:27:29 CDT(-0500)] <jhung> the way we did it in Deca 0.4 was to do an actual capture-and-download test as part of the calibration.

[13:27:51 CDT(-0500)] <jhung> just to make sure we can actually trigger and download over USB.

[13:28:12 CDT(-0500)] <Justin_o> jhung: hmm.. but we are trying to separate those things now

[13:28:21 CDT(-0500)] <Justin_o> calibration and capture anyways..

[13:28:29 CDT(-0500)] <Justin_o> we are trying to make something that just controls the cameras

[13:28:45 CDT(-0500)] <Justin_o> and then that will be used for generating the calibration info and taking actual captures

[13:29:32 CDT(-0500)] <Justin_o> i guess we might just have to do this as part of the summary process

[13:29:54 CDT(-0500)] <jhung> Okay. Then Capture should do a check to make sure the cameras are supported before we pass things on to Calibration.

[14:34:55 CDT(-0500)] <colinclark_> hey alexn1, one quick question for you about this really great pull request

[14:34:57 CDT(-0500)] <colinclark_> https://github.com/fluid-project/videoPlayer/pull/45/files#L3R196

[14:35:05 CDT(-0500)] <colinclark_> I see you're using fluid.COMPONENT_OPTIONS here

[14:35:19 CDT(-0500)]

[14:35:21 CDT(-0500)] <colinclark_> Did that not work?

[14:35:24 CDT(-0500)] <colinclark_> and if so, how come?

[14:35:44 CDT(-0500)]

[14:35:53 CDT(-0500)] <alexn1> and he suggested using this fluid.COMPONENT_OPTIONS

[14:36:04 CDT(-0500)] <colinclark_> how come it didn't work, yura?

[14:36:27 CDT(-0500)]

[14:37:19 CDT(-0500)]

[14:51:07 CDT(-0500)] <colinclark> ok

[14:51:08 CDT(-0500)] <colinclark> thanks

[15:01:15 CDT(-0500)] <colinclark> alexn1 and michelled: Can I run a quick question past you both?

[15:01:22 CDT(-0500)] <alexn1> colinclark: for sure !

[15:01:24 CDT(-0500)] <michelled> yes

[15:01:32 CDT(-0500)] <colinclark> I'm contemplating this line now: https://github.com/fluid-project/videoPlayer/pull/45/files#L2R42

[15:02:42 CDT(-0500)] <colinclark> These are the minor details

[15:02:47 CDT(-0500)] <colinclark> i like the pull request as-is

[15:02:52 CDT(-0500)] <colinclark> but while testing, I got to thinking

[15:02:59 CDT(-0500)] <colinclark> so we create a video tag here

[15:03:10 CDT(-0500)] <colinclark> and then test it to see if it has a requestFullScreen method on it

[15:03:22 CDT(-0500)] <colinclark> which is sensible, in the sense that the current implementation will do exactly that

[15:03:40 CDT(-0500)] <colinclark> Now that we know more about requestFullScreen, I guess we can foresee that we'll actually be calling this on some other element

[15:03:42 CDT(-0500)] <colinclark> whatever it may be

[15:04:06 CDT(-0500)] <colinclark> I'm wondering if you think it makes more sense to test for the requestFullScreenMethod on some other element?

[15:04:08 CDT(-0500)] <colinclark> Such as, say, the body

[15:11:55 CDT(-0500)] <colinclark> after testing it, i realize that the body element doesn't even exist this early in the process

[15:12:00 CDT(-0500)] <colinclark> so the current implementation is sound

[15:46:06 CDT(-0500)] <colinclark> michelled: https://developer.mozilla.org/en-US/docs/DOM/TimeRanges

[15:58:11 CDT(-0500)] <colinclark> alexn1: Congrats, your FLUID-4779 pull request is in

[15:59:39 CDT(-0500)] <colinclark> alexn1: You said you were going to work on this one next, right? https://github.com/fluid-project/videoPlayer/pull/56/files

[16:00:05 CDT(-0500)] <alexn1> colinclark: yay ! it is finally in after so many discussions… I think I'm getting emotional here

[16:00:12 CDT(-0500)] <colinclark>

[16:00:20 CDT(-0500)] <alexn1> colinclark: yes it will be next one since it is very related to the one which just got in

[16:00:25 CDT(-0500)] <colinclark> ok