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)] <Justin_o> jhung: how about ?
[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)] <colinclark_> I remember vaguely that yura's example used a reference to instead
[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)] <alexn1> colinclark: actually yura was the one who was helping me there since did not work
[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)] <alexn1> I saw the later in cspace in lots of places but never , to be honest
[14:37:19 CDT(-0500)] <yura> i think that pathway did not work, i believe it works when merging all options but not as options: " "
[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