Skip to end of metadata
Go to start of metadata

[08:14:53 CDT(-0500)] <Justin_o> cindyli: hello.. i've refactored the get and set methods in

[08:14:53 CDT(-0500)] <Justin_o>

[08:15:21 CDT(-0500)] <Justin_o> cindyli: any thoughts

[08:19:08 CDT(-0500)] <Justin_o> cindyli: oops forgot to change get.. one second

[08:22:08 CDT(-0500)] <Justin_o> cindyli: okay it's up there now

[08:43:16 CDT(-0500)] <cindyli> it looks great, Justin_o

[08:43:43 CDT(-0500)] <Justin_o> cindyli: thanks.. i'm going to clean up the our changeApplier a bit too… did you want any changes there

[08:43:56 CDT(-0500)] <cindyli> no, Justin_o

[08:44:03 CDT(-0500)] <Justin_o> for example would you prefer to get something else passed into the event listener

[08:48:39 CDT(-0500)] <cindyli> looks like adding a new element onto a dict is handled by requestUpdate, which is fine. cannot think of anything to add, Justin_o, what you have is quite adequate i think

[08:56:55 CDT(-0500)] <Justin_o> cindyli: thanks.. i'm about to push up some refactored code for the removal, the only functional change would be that if you try to remove something that isn't there, it won't trigger the onModelChanged event

[08:57:15 CDT(-0500)] <cindyli> ok, Justin_o

[08:59:49 CDT(-0500)] <Justin_o> cindyli: it's all up now

[09:00:07 CDT(-0500)] <cindyli> thanks, Justin_o, i will merge it in

[09:00:18 CDT(-0500)] <Justin_o> cindyli: i'll pull down your changes and refactor the exporter to use the store we set up yesterday

[09:00:31 CDT(-0500)] <Justin_o> cindyli: let me know after you've merged and i'll pull down your merged changes

[09:07:52 CDT(-0500)] <cindyli> Justin_o: done, merged and pushed into

[09:08:20 CDT(-0500)] <Justin_o> cindyli: thanks

[09:08:38 CDT(-0500)] <cindyli> Justin_o: i will fix mockCameraInterface to parameterize the path to the mock images

[09:09:20 CDT(-0500)] <Justin_o> cindyli: that's great thanks..

[09:09:30 CDT(-0500)] <cindyli> np

[09:11:35 CDT(-0500)] <jhung> cindyli and justin_o: I have some more info about stereo calibration.

[09:12:27 CDT(-0500)] <jhung> We are using OpenCV for calibration so I looked up some examples. It seems the typical calibration routine involves the user keeping the cameras in a fixed position and the user moves the pattern around in front of the cameras.

[09:13:12 CDT(-0500)] <jhung> Makes me wonder if we should re-think our approach...

[09:13:15 CDT(-0500)] <Justin_o> jhung: okay.. i think that's what we had initially though would be the approach

[09:13:22 CDT(-0500)] <jhung> yeah

[09:13:45 CDT(-0500)] <Justin_o> jhung: so the problem is having to capture while changing the pattern position?

[09:14:04 CDT(-0500)] <jhung> Justin_o: so maybe we ask the user to mark the edges of the frame of both cameras, and then have them move the pattern around in front until we get 25 samples?

[09:14:17 CDT(-0500)] <jhung> yeah. So maybe automatic countdown?

[09:14:55 CDT(-0500)] <Justin_o> jhung: the marking part might not be so easy either

[09:15:38 CDT(-0500)] <jhung> true justin_o. But it doesn't have to be exact. Just so they know roughly where the boundaries are.

[09:16:15 CDT(-0500)] <Justin_o> jhung: also i guess we should suggest that they mount the pattern to something rigid enough so that it doesn't curl when not lying flat to the surface

[09:16:26 CDT(-0500)] <jhung> The alternative is to have them move the tripod / cameras around which may have undesirable effects. Also like you said yesterday, there may not be enough room.

[09:16:42 CDT(-0500)] <jhung> Also from what I've been reading from OpenCV, a wide variety of shots is desirable.

[09:16:54 CDT(-0500)] <jhung> yes exactly justin_o.

[09:17:13 CDT(-0500)] <jhung> I figure the prep work is easier than adjusting the hardware during calibration.

[09:17:31 CDT(-0500)] <jhung> Also re calibration is easier.

[09:17:40 CDT(-0500)] <jhung> Because camera is fixed.

[09:18:24 CDT(-0500)] <jhung> and the user would have already marked boundaries to redo the calibration.

[09:19:17 CDT(-0500)] <Justin_o> jhung: true, that's a good benefit

[09:19:33 CDT(-0500)] <Justin_o> probably will help with capture too if they have the boundaries marked

[09:19:45 CDT(-0500)] <jhung> Yep

[09:20:58 CDT(-0500)] <jhung> So there are some possible issues arising from this approach:

[09:21:02 CDT(-0500)] <alexn2> colinclark: I managed to resolve FLUID-4793 and have a pull request all details are in the JIRA. Also, michelled I added FLUID-4796 and FLUID-4797 since I stumbled upon them while trying to fix FLUID-4793, managed to fix one of them and send a pull request but second is still present.

[09:21:25 CDT(-0500)] <jhung> 1. The user may be more prone to errors (may not be ready when the cameras fire).

[09:22:02 CDT(-0500)] <jhung> 2. How many shots do we need given the increased error rate?

[09:22:30 CDT(-0500)] <jhung> 3. The server architecture will need to change to accomodate automatic / countdown timer.

[09:22:43 CDT(-0500)] <Justin_o> jhung: i'm not sure we need the countdown timer

[09:23:05 CDT(-0500)] <Justin_o> jhung: we just get them to set it, take a picture.. repeat

[09:23:13 CDT(-0500)] <alexn2> colinclark: I also put text "(feedback)" for the pull requests for which I got comments on and currently working. Other 6 are still waiting for a review so let me know when you have time to look into them.

[09:23:37 CDT(-0500)] <jhung> so justin_o: one hand holding the pattern while the other presses the capture button?

[09:23:47 CDT(-0500)] <Justin_o> jhung: no, just leave it there

[09:24:13 CDT(-0500)] <Justin_o> and for the raised ones, they can just put something under the calibration pattern to prop it up

[09:25:49 CDT(-0500)] <Justin_o> this would also prevent the persons hand being in the calibration captures

[09:26:01 CDT(-0500)] <jhung> hmmm but we need a variety of positions justin_o, so the user will need to use different things to do the propping.

[09:27:17 CDT(-0500)] <Justin_o> jhung: not necessarily.. they could probably just use one thing and change its position.. so think of a little block.. if we lean the capture board against it at different angles, and different positions it should get your effect

[09:27:51 CDT(-0500)] <Justin_o> jhung: also, we could design a cardboard backing template that could have cutout tabs for the different propping orientations

[09:28:05 CDT(-0500)] <jhung> hmmm...

[09:33:31 CDT(-0500)] <Justin_o> cindyli: okay.. i renamed Events to Firer

[09:33:44 CDT(-0500)] <cindyli> thanks, Justin_o

[09:34:58 CDT(-0500)] <Justin_o> cindyli: i've merged in your changes now too, thanks

[09:35:18 CDT(-0500)] <cindyli> np, i've merged in your renaming, Justin_o

[09:35:33 CDT(-0500)] <Justin_o> cindyli: thanks

[09:35:37 CDT(-0500)] <cindyli> np

[09:43:47 CDT(-0500)] <cindyli> Justin_o: after looking into the parameterizing the mock image path, I think the proper way is to make the test has its own mock image dir, so that, 1. keep the interface of cameraInterface and mockInterface in sync; 2. separate out the data of regular process and tests. any thoughts?

[09:46:03 CDT(-0500)] <Justin_o> cindyli: it would probably be the simplest solution to those, the only downside is that we'd have to carry around 2 copies of the same files

[09:47:00 CDT(-0500)] <jhung> justin_o, cindyli - how quickly can we capture stereo images?

[09:47:00 CDT(-0500)] <Justin_o> cindyli: at this point though the duplication probably isn't too costly

[09:47:19 CDT(-0500)] <cindyli> agree, Justin_o.

[09:47:20 CDT(-0500)] <Justin_o> cindyli: i guess if we need more images we can think about having only one again, but for now it's probably fine

[09:47:43 CDT(-0500)] <Justin_o> jhung: i guess that might depend on the cameras, and the first shot is usually longer than the rest

[09:48:22 CDT(-0500)] <Justin_o> cindyli: do you think you could do a simple time estimate for how long the two captures and file saving takes?

[09:48:44 CDT(-0500)] <cindyli> we could, Justin_o

[09:49:20 CDT(-0500)] <cindyli> i'll try that and let you know, jhung and Justin_o

[09:49:30 CDT(-0500)] <jhung> thanks cindyli.

[09:49:42 CDT(-0500)] <cindyli> np

[09:49:44 CDT(-0500)] <Justin_o> cindyli: thanks

[10:07:10 CDT(-0500)] <Justin_o> cindyli: what do you think of something like this

[10:07:47 CDT(-0500)] <Justin_o> it would be a small status class that would take in a store, and optionally a dictionary.. then you could use this to manage your status

[10:12:12 CDT(-0500)] <cindyli> looks good, Justin_o. what is defaultModel? to keep track if the store is loaded? why do we need to track it?

[10:13:50 CDT(-0500)] <Justin_o> cindyli: i had forgotten to delete line 6, but it is so that you could pass in a default value for the model…. so like the initalStatus.. or if you a dictionary already that you want to use as the status, then you could pass this in and access it either through this class or though your dictionary directly

[10:15:25 CDT(-0500)] <cindyli> ok, i see, Justin_o. the class looks good to me

[10:16:10 CDT(-0500)] <Justin_o> cindyli: thanks, i'll create it now

[10:16:18 CDT(-0500)] <cindyli> thanks, Justin_o

[10:40:47 CDT(-0500)] <cindyli> jhung, Justin_o, taking 2 pics and saving status takes about 15 − 20 secs

[10:41:02 CDT(-0500)] <jhung> :O

[10:41:22 CDT(-0500)] <jhung> that's not good. (sad)

[10:41:22 CDT(-0500)] <Justin_o> cindyli: thanks

[10:41:44 CDT(-0500)] <jhung> 20s * 22 stereo pairs...

[10:41:45 CDT(-0500)] <cindyli> np

[10:42:03 CDT(-0500)] <Justin_o> jhung, cindyli: min calibration time would be 11 minus (sad)

[10:42:17 CDT(-0500)] <Justin_o> minutes

[10:42:27 CDT(-0500)] <jhung> 7 minutes to capture. 6 minutes to calibrate

[10:42:29 CDT(-0500)] <jhung> (sad)

[10:42:33 CDT(-0500)] <michelled> alexn2: what are you up to with amara json?

[10:43:20 CDT(-0500)] <alexn2> michelled: sorry I'm confused. what are we talking about ?

[10:43:25 CDT(-0500)] <alexn2> (smile)

[10:43:45 CDT(-0500)] <alexn2> do you mean the bug I was working on related to JSON transcripts ?

[10:45:21 CDT(-0500)] <michelled> I'm not sure, perhaps - you mentioned uni subs json in your stand up report

[10:46:28 CDT(-0500)] <alexn2> oh it is all related to

[10:46:36 CDT(-0500)] <alexn2> basically I found a core problem with this bug

[10:47:20 CDT(-0500)] <alexn2> I just said that JSON file for transcripts has different time stamps comparing to the captions pulled from UniSub

[10:47:56 CDT(-0500)] <michelled> oh, so you found an issue with our demo files

[10:48:01 CDT(-0500)] <alexn2> that is why when you click on a transcript file, different captions are shown

[10:48:05 CDT(-0500)] <alexn2> yes (sad)

[10:48:19 CDT(-0500)] <alexn2> and I found 2 other independent issues while trying to figure out what was going wrong

[10:48:50 CDT(-0500)] <michelled> cool, once we have better test coverage we should get to a point where we aren't finding so many issues every time we do anything

[10:49:23 CDT(-0500)] <alexn2> yes. but no worries I managed to send a pull request for one of the issues I found

[10:49:38 CDT(-0500)] <alexn2> and second one will fix as well once I refactor one of my pull requests (smile)

[10:49:49 CDT(-0500)] <colinclark> alexn2: On a somewhat related note, I'm wondering if you could, in plain old language, explain the nature of this algorithm here:

[10:50:18 CDT(-0500)] <colinclark> I'm a little puzzled by the choice to do string concatenation on data that is, at heart, numeric

[10:50:21 CDT(-0500)] <colinclark> but perhaps I'm missing something

[10:50:35 CDT(-0500)] <alexn2> oh it is basically 0 padding for a millisecond part

[10:50:49 CDT(-0500)] <alexn2> well we read string and convert it to numbers

[10:50:51 CDT(-0500)] <colinclark> why have you chosen to do it this way?

[10:51:59 CDT(-0500)] <alexn2> well it means that 1.7 or 1.70 or 1.700 will still be 1.700

[10:52:26 CDT(-0500)] <alexn2> and 1.07 or 1.070 will still be 1.070

[10:53:02 CDT(-0500)] <colinclark> My question is more, "why did you choose to do it by concatenating strings instead of doing actual math on numbers?"

[10:53:15 CDT(-0500)] <colinclark> it might be a perfectly valid choice, I just don't understand your motivation

[10:53:29 CDT(-0500)] <alexn2> well how would you do it with numbers ?

[10:54:06 CDT(-0500)] <alexn2> if you convert second part of 1.07 or 1.7 to a number it will be still 7

[10:54:28 CDT(-0500)] <alexn2> or 1.007 if you take 007 part and convert to numbers it will be still 7

[10:54:44 CDT(-0500)] <colinclark> okay, so your motivation was "this worked and I knew how to do it"

[10:54:45 CDT(-0500)] <colinclark> fair enough

[10:54:48 CDT(-0500)] <colinclark> let me think through this a little bit

[10:54:52 CDT(-0500)] <alexn2> well

[10:55:07 CDT(-0500)] <alexn2> I coud not come up with a "not overly complex" number solution

[10:55:28 CDT(-0500)] <alexn2> which does not require complex nested if statements

[10:56:05 CDT(-0500)] <colinclark> ok

[10:56:10 CDT(-0500)] <alexn2> this way it is simple and fast. Since we still have to convert string to a number - this solution would provide a reliable solution

[10:57:43 CDT(-0500)] <alexn2> colinclark: if you have in mind a working and simple solution using numbers and covering all the test cases I would love to see it (smile) since this solution is the most elegant I could come up with

[10:58:05 CDT(-0500)] <colinclark> yes, alexn2

[10:59:05 CDT(-0500)] <colinclark> alexn2: As a code reviewer, I have to look at the implementation and ask myself a few questions

[10:59:13 CDT(-0500)] <colinclark> 1. Why did the developer write it this way?

[10:59:13 CDT(-0500)] <alexn2> colinclark: using mod ?

[10:59:27 CDT(-0500)] <colinclark> 2. What tradeoffs does this particular implementation entail

[10:59:38 CDT(-0500)] <colinclark> 3. How does it relate to the standards and specifications we are using, etc?

[10:59:53 CDT(-0500)] <colinclark> So when I ask you questions about your motivation, that's part of my process of understanding your code

[11:00:16 CDT(-0500)] <colinclark> It really has nothing to do with whether the algorithm is "right or wrong"--that's a separate question

[11:00:30 CDT(-0500)] <colinclark> So, to answer questions #2 and #3, I'm taking a look at the WebVTT specification

[11:00:41 CDT(-0500)] <colinclark> to see how it approaches this question of parsing timestamps

[11:00:48 CDT(-0500)] <alexn2> colinclark: ugh my message probably sounded upset or angry… oh no worries. It is a good opportunity to learn for me and I do not mind any of your questions (smile)

[11:00:57 CDT(-0500)] <colinclark> this will give me a bit more perspective on the larger environment that the code lives in

[11:01:05 CDT(-0500)] <colinclark>

[11:02:26 CDT(-0500)] <colinclark> #15 in this process intrigues me

[11:02:30 CDT(-0500)] <colinclark> Am I understanding it correctly?

[11:03:15 CDT(-0500)] <colinclark> It seems to be suggesting that a WebVTT parser will actually throw an error if there aren't exactly three characters after the dot in a timestamp?

[11:03:45 CDT(-0500)] <alexn2> looks like it

[11:04:15 CDT(-0500)] <colinclark> So where do we get WebVTT times that have < 3 characters, out of curiosity?

[11:04:18 CDT(-0500)] <colinclark> Do we know?

[11:05:05 CDT(-0500)] <alexn2> Well the transcript JSON parser we have in a code base handles those cases. I found several tests for this and our initial JSON transcript files contain only 2 characters

[11:05:31 CDT(-0500)] <alexn2> but to think of an example where WebVTT will be returned < 2 characters...

[11:05:53 CDT(-0500)] <colinclark> michelled: Can you remind me of the context of this code?

[11:05:58 CDT(-0500)] <colinclark> I forget the whole flow of things here

[11:05:58 CDT(-0500)] <alexn2> maybe some other services or user written components or other applications… which did not catch up with standard ?

[11:07:20 CDT(-0500)] <colinclark> You can see here how Anne Van Kesteren's parser handles timestamps, alexn2:

[11:07:37 CDT(-0500)] <colinclark> So I guess the thing I need to better understand is how our different formats--JSON and WebVTT typically relate to each other

[11:07:46 CDT(-0500)] <colinclark> if one format is "canonical"

[11:07:58 CDT(-0500)] <colinclark> and if we actually have semantic differences in timestamps between the two formats

[11:09:39 CDT(-0500)] <colinclark> it's never simple, is it, alexn2?

[11:09:40 CDT(-0500)] <colinclark> (smile)

[11:09:48 CDT(-0500)] <michelled> colinclark: you will be sad to know that we are doing different things for transcripts and captions at this point. it's one of the reasons that it's so important that I pull out the amara json to webvtt translation

[11:09:51 CDT(-0500)] <alexn2> I start noticing that I have unique ability to find more issues by digging into an other one

[11:09:51 CDT(-0500)] <michelled> I have that in my branch now

[11:10:02 CDT(-0500)] <colinclark> interesting

[11:10:02 CDT(-0500)] <michelled> but I don't have captionator working with a data url yet

[11:10:08 CDT(-0500)] <colinclark> do you have time to have a quick Skype call with alexn2 and I?

[11:10:13 CDT(-0500)] <colinclark> I'd like to understand more

[11:10:14 CDT(-0500)] <michelled> yep

[11:10:19 CDT(-0500)] <colinclark> alexn2: you free?

[11:10:28 CDT(-0500)] <alexn2> for sure !

[11:10:29 CDT(-0500)] <alexn2> (smile)

[11:10:33 CDT(-0500)] <alexn2> let me login

[11:11:40 CDT(-0500)] <alexn2> I'm online in Skype so you can call me whenever you ready

[12:47:58 CDT(-0500)] <jhung> cindyli: is it possible to control the resolution of the camera using gphoto?

[13:37:03 CDT(-0500)] <cindyli> jhung: sorry, just saw ur msg. no, gphoto doesn't provide an option to control the resolution. It has an option to specify the cameral model. I tried to specify our cannon camera with another model that has a different resolution. unfortunately, didn't work. the capture request is refused due to the unmatched model.

[13:37:34 CDT(-0500)] <jhung> ok. Thanks,

[13:37:37 CDT(-0500)] <cindyli> np

[13:38:44 CDT(-0500)] <cindyli> Justin_o: did you come across this method while researching on the simultaneous capture:

[13:39:57 CDT(-0500)] <cindyli> i tried it, works pretty well except the first pair are not taken simultaneously. the rest pairs are tho

[13:40:57 CDT(-0500)] <Justin_o> cindyli: i had seen that, but this part seemed strange to me "killall -USR1 gphoto2"

[13:41:27 CDT(-0500)] <cindyli> well, that's to send a signal to gphoto2 by using killall. strange indeed. i agree, Justin_o

[13:41:37 CDT(-0500)] <Justin_o> cindyli: maybe i'm just not familiar enough with the command line though..

[13:41:51 CDT(-0500)] <Justin_o> cindyli: i think it's weird that killall would actually start it (smile)

[13:42:03 CDT(-0500)] <Justin_o> cindyli: is there some other signal we could send instead?

[13:42:24 CDT(-0500)] <cindyli> umm…

[13:44:38 CDT(-0500)] <cindyli> from what I read from gphoto doc, doesn't seem have a way to customize this signal. we could take a look on the source code. but, why do you think we should use some other signal, Justin_o?

[13:45:49 CDT(-0500)] <Justin_o> cindyli: I think I'd find it strange if i saw that in the code..

[13:47:15 CDT(-0500)] <cindyli> Justin_o: from killall man page:

[13:48:05 CDT(-0500)] <cindyli> killall is to send a signal out to specific processes. I guess what to do after receiving this signal is depending on the process itself

[13:48:31 CDT(-0500)] <cindyli> interesting how gphoto makes use of it

[13:48:53 CDT(-0500)] <Justin_o> cindyli: okay.. i guess it looks like the standard/only way to do it (smile)

[13:49:18 CDT(-0500)] <Justin_o> cindyli: lets give it a go then.. how much time does it save?

[13:49:34 CDT(-0500)] <cindyli> it can save about 5 secs for each pair

[13:50:13 CDT(-0500)] <cindyli> i think it's pretty good, 1/3 time reduced for capture, Justin_o, jhung

[13:50:23 CDT(-0500)] <Justin_o> cindyli: i think so

[13:50:31 CDT(-0500)] <Justin_o> 25 - 33% that's pretty good

[13:51:02 CDT(-0500)] <Justin_o> cindyli: can you make our calibration script faster too (wink)

[13:51:20 CDT(-0500)] <cindyli> which part, Justin_o

[13:51:32 CDT(-0500)] <cindyli> i do hope i can help

[13:51:36 CDT(-0500)] <Justin_o> cindyli: the part that takes 6 minutes to run (smile)

[13:51:53 CDT(-0500)] <jhung> yeah that's great news cindyli

[13:52:00 CDT(-0500)] <cindyli> that's what i was going to say, for that 6 mins, out of our reach

[13:53:03 CDT(-0500)] <Justin_o> cindyli, jhung: well we're down to about 8 min now.. so that's pretty good

[13:53:41 CDT(-0500)] <Justin_o> cindyli, jhung: sorry that's just under 10 min actually

[14:03:01 CDT(-0500)] <Justin_o> cindyli: I've pushed up my changes.. I've refactored the export server to use the new status module which can be found in utils. I also updated the and modules to return the status as a dictionary and then serialize them in the exportserver like you have in capture

[14:07:34 CDT(-0500)] <cindyli> thanks, Justin_o, will do a merge

[14:08:13 CDT(-0500)] <Justin_o> cindyli: thanks.. i'm going to head offline now.. is there anything you'd like to talk about before that?

[14:08:29 CDT(-0500)] <cindyli> no, Justin_o, enjoy the weekend. (smile)

[14:08:32 CDT(-0500)] <Justin_o> jhung: ^

[14:08:37 CDT(-0500)] <jhung> thanks justin_o

[14:08:40 CDT(-0500)] <jhung> nothing right now

[14:08:45 CDT(-0500)] <cindyli> i do have things to discuss on Monday tho, Justin_o

[14:09:13 CDT(-0500)] <Justin_o> cindyli: thanks.. on Monday i think we can sec up again.. see where we're at. When we get all the work scheduled for this iteration done we should do a code review and then push it up to the googlecode repo

[14:09:27 CDT(-0500)] <Justin_o> cindyli: okay great

[14:09:45 CDT(-0500)] <cindyli> sure

[14:09:49 CDT(-0500)] <Justin_o> jhung, cindyli: have a good weekend, see you monday

[14:09:55 CDT(-0500)] <cindyli> bye

[14:09:59 CDT(-0500)] <jhung> you too

  • No labels