RE: How does "record" activity the camera in Sugar?
I have tried the “gst-launch-0.10 v4l2src ! xvimagesink” and the display is normally. Then I try the “gst-launch-0.10 videotestsrc ! xvimagesink” and there is no problem with test pattern. We have changed a new camera module on the same machine and run “record”. But there is the same problem in real-time display. Thank you. Luna From: Erik Blankinship [mailto:[EMAIL PROTECTED] Sent: Thursday, September 06, 2007 12:04 PM To: Luna Huang (�S��玲) Cc: [EMAIL PROTECTED] Subject: Re: How does "record" activity the camera in Sugar? The first command will run the camera data directly to the xv image sink via gstreamer (a video application framework used by the Record activity). We can diagnose where the problem is better when we see the result of this test. The second command will run a test pattern directly to the xv image sink. If we get the same visual problem with the test patter, we might be able to rule out the camera as the culprit. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: How does "record" activity the camera in Sugar?
The first command will run the camera data directly to the xv image sink via gstreamer (a video application framework used by the Record activity). We can diagnose where the problem is better when we see the result of this test. The second command will run a test pattern directly to the xv image sink. If we get the same visual problem with the test patter, we might be able to rule out the camera as the culprit. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: How does "record" activity the camera in Sugar?
On Thu, Sep 06, 2007 at 09:13:46AM +0800, [EMAIL PROTECTED] wrote: > >gst-launch-0.10 v4l2src ! xvimagesink > >and report if you get the same problem? > Well, I got one error report: > ERROR: pipeline could not be constructed: no element ??v412src??. You have mis-read the characters in the original mail. The letter L in lowercase was between the 4 and the 2, not the number one. v - victor 4 - four l - lima 2 - two s - sierra r - romeo c - charlie -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Nepalese have right attitude
The sacrifice or the barbecue ? Unless somebody (Richard ?) is faster than me at goat skinning, there will be about an hour and half lag (possibly more, I'm not real clear on the ritual w. a goat.) wad On Sep 5, 2007, at 10:47 PM, Robert D. Fadel wrote: > > Spot on, Jim! Please time it during a business lunch meeting. > > r. > > > Jim Gettys <[EMAIL PROTECTED]> > 09/05/2007 10:38 PM > Please respond to > [EMAIL PROTECTED] > > > To > John Watlington <[EMAIL PROTECTED]> > cc > Robert Fadel <[EMAIL PROTECTED]>, OLPC Developer's List > <[EMAIL PROTECTED]> > Subject > Re: Nepalese have right attitude > > > > > > So long as the goat is young, so we can barbecue the result >- Jim > > > On Wed, 2007-09-05 at 22:32 -0400, John Watlington wrote: > > Haven't we all had products that demanded live sacrifices ? > > > > Goats sacrificed to fix Nepal jet > > http://news.bbc.co.uk/2/hi/south_asia/6979292.stm > > > > I never splurged on a goat, much less two. > > Maybe on XO suspend/resume > > (Robert, can we expense them ?) > > > > Cheers, > > wad > > ___ > > Devel mailing list > > Devel@lists.laptop.org > > http://lists.laptop.org/listinfo/devel > -- > Jim Gettys > One Laptop Per Child > > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Nepalese have right attitude
On 9/6/07, John Watlington <[EMAIL PROTECTED]> wrote: > > Haven't we all had products that demanded live sacrifices ? > > Goats sacrificed to fix Nepal jet > http://news.bbc.co.uk/2/hi/south_asia/6979292.stm > > I never splurged on a goat, much less two. > Maybe on XO suspend/resume On behalf of all goats, no more screeching noises please. :-) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Nepalese have right attitude
But be careful of the skin: http://www.wfsb.com/news/14049418/detail.html http://www.foxnews.com/story/0,2933,295833,00.html http://www.recall-warnings.com/cpsc-content-74-74026.html http://www.wtopnews.com/?nid=104&sid=1239680 --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Nepalese have right attitude
So long as the goat is young, so we can barbecue the result - Jim On Wed, 2007-09-05 at 22:32 -0400, John Watlington wrote: > Haven't we all had products that demanded live sacrifices ? > > Goats sacrificed to fix Nepal jet > http://news.bbc.co.uk/2/hi/south_asia/6979292.stm > > I never splurged on a goat, much less two. > Maybe on XO suspend/resume > (Robert, can we expense them ?) > > Cheers, > wad > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Nepalese have right attitude
Haven't we all had products that demanded live sacrifices ? Goats sacrificed to fix Nepal jet http://news.bbc.co.uk/2/hi/south_asia/6979292.stm I never splurged on a goat, much less two. Maybe on XO suspend/resume (Robert, can we expense them ?) Cheers, wad ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: How does "record" activity the camera in Sugar?
an exclamation mark ? run: >gst-launch-0.10 v4l2src ! xvimagesink >and report if you get the same problem? Well, I got one error report: ERROR: pipeline could not be constructed: no element “v412src”. Could you explain what the command is? Thank you very much. Luna From: Erik Blankinship [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 05, 2007 9:46 PM To: Luna Huang (�S��玲) Cc: devel@lists.laptop.org Subject: Re: How does "record" activity the camera in Sugar? >From the terminal, can you run: gst-launch-0.10 v4l2src ! xvimagesink and report if you get the same problem? Also, try: gst-launch-0.10 videotestsrc ! xvimagesink I look forward to the results of these tests. Thank you, Erik On 9/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Sorry, I forget to say. In the Nand flash image is 542. But I use USB whose image is 515 to boot, has the same event. Luna From: Erik Blankinship [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 05, 2007 9:02 PM To: Luna Huang (�S��玲) Cc: devel@lists.laptop.org Subject: Re: How does "record" activity the camera in Sugar? Good morning Luna Can you please take a photograph of your XO (with another camera), so that we can see the visual problem? Also, which build are you using? Thank you Erik On 9/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: There is one question need someone tells me. How does "record" activity the camera in Sugar? I have one C test machine which has question. When I open "record" item, can fine there are some straight lines on left of a real-time display of the camera's input being shown. The lines are highly concentrated to make the left of portrait is indistinct. And all of real-time display has noise to make display is disturbance. Use "test /camera" on OFW, I did not fine the event. I have done the memory test is no problem. Boot from USB, the event also exists. I think it is HW question. But I don't know there has different between "record" and OFW. Please give idea to help me analysis quick. Thanks. Best Regards, - Luna Huang / �S��玲 Quanta EPBU Software Dept. Engineer Tel : 886-3-327-2345 EXT:18921 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel <>___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: headtracker / mag lens / macro lens ([EMAIL PROTECTED])
I see, so the camera sensor area covered by moving your head in-place to
point to the four corners of the display is approximately 90x30.
I think you are saying that the image of the reflective dot is a blob of
neighboring pixels of size 5x3 to 20x12 somewhere on the display. If that
is the case, then taking the centroid is probably the best approach.
However I may make a suggestion to improve accuracy:
-- Threshold image at some minimum brightness
-- Find largest blob of connected pixels above threshold, and put them into
a set B
-- Put all pixels just inside or just outside the edge of the blob into a
set E
-- Find all internal pixels I = B \ E (all pixels in B that are not in E)
-- Linearly scale the (floating point) intensity of all pixels in E so the
brightest is 1.0 and the darkest is 0.0. (Beware of division by zero if all
edge pixels are the same intensity.)
-- Set the intensity of all pixels in I to 1.0
-- Find the weighted centroid of (I Union E), by multiplying the pixel
intensity by the x and y coords, and summing for x and y, then dividing x
and y sums by the total of all pixel intensities.
What this effectively does is give all internal pixels equal weight in
calculating centroid position, and then it uses the normalized shade of edge
pixels to fractionally adjust the centroid position. This effectively
reverses the antialiasing that occurs at the edge of the image of the dot on
the CCD. You really should be able to get some good resolution using some
sort of approach like this.
By the way, as someone pointed out in another post, trying to hold your head
in position and just tilt it slightly to reach the corners of the laptop is
likely to give you a knot in your neck! You should probably allow the user
to move their head further (because their effective range is extended by
their eyes). You might also want to consider doing some eye tracking, so
that the user can blink twice to turn the head tracking on or off, for
example, and maybe wink to trigger a L/R mouse button action.
Also you should look at relative positioning and not just absolute
positioning: e.g. the cursor doesn't move unless you move your head quickly,
and the movement is only part of the width of the screen each time -- that
way you can move the cursor in several steps, by moving quickly forward in
one direction, then slowly back, much the same way as you do with a touch
pad, except that touching/raising your finger is emulated by the speed
threshold.
Luke
On 9/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Hello Luke,
>
> I will consider the paraboloid thing, thanks for the code.
>
> I am not tracking only one point. I am tracking a bundle of points - say
> 5x3 to 20x12 - and it changes all the time with different ratio. Out of
> those pixels (and maybe some time) I have to build an AVG Pixel with a
> defined XY value. AVG pixel != brightest pixel. For that AVG pixel I could
> use subpixel, too. I have to use subpixel because I have to map the low
> resolution to 1200x900 pixel if I try to use absolute coordinates.
> Where do I get the size 90x30 from? It is not an pixel exact value but a
> approximation. It differs.
> I tried not to move my eyes but my head and looking to the four corners
> and the center of the XO display. The display is very small so I moved my
> head really not to much. One infrared filtered result merged from 5
> snapshots (four eges and center) is here:
>
> http://www.olpcaustria.org/mediawiki/upload/7/79/Headtracker_area_small.jpg
> It is downsized from 640x480 to 320x240px but the relation is the same.
>
> Maybe I have got a knot in my brain. I really like to get the headtracker
> working in a good way without an additional lens.
> Again the link to the project site:
> http://www.olpcaustria.org/mediawiki/index.php/Headtracker
>
> greeting,
> yokoy
>
>
>
>
> On Wed, 5 Sep 2007 12:57:54 -0400
> "Luke Hutchison" <[EMAIL PROTECTED]> wrote:
>
> > PS there's a "cheap" way you can accomplish subpixel accuracy, as
> follows.
> > You basically take a bunch of 1D samples through the brightest pixel,
> > looking at 2 neighbors in each direction, and then take a weighted sum
> of
> > the results. This calls the code I pasted in the last email. It's not
> > going to be as good as paraboloid regression, but it should allow you to
> > test feasibility.
> >
> >
> > // Do a 2D parabolic fit to give sub-pixel accuracy for translational
> > // registration, by performing four 1D parabolic fits through the
> closest
> > // integer correlation offset: horizontally, vertically, and on the
> leading
> > // and trailing diagonals. Take the weighted centroid of all four to
> get
> > // the true correlation offset.
> >
> > // off_x and off_y are the one-pixel-accurate correlation offsets
> recovered
> > // by correlation.
> >
> > // x1d and y1d are x and y values for the 1D quadratic fit function
> > double y1d[9] = { // Get magnitudes at (off_x,off_y) and 8 neighbors
> > dft_mag(dft, off_x -
Re: headtracker / mag lens / macro lens ([EMAIL PROTECTED])
[EMAIL PROTECTED] wrote: > I tried not to move my eyes but my head and looking to the four corners and > the center of the XO display. The display is very small so I moved my head > really not to much ... > > Maybe I have got a knot in my brain. > I'm pretty sure that if I had to keep my head still to avoid moving the mouse, I would have a knot in the back of my neck after a short time. Whether the knot would then travel to my brain, I don't know. :-) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: headtracker / mag lens / macro lens ([EMAIL PROTECTED])
Hello Luke,
I will consider the paraboloid thing, thanks for the code.
I am not tracking only one point. I am tracking a bundle of points - say 5x3 to
20x12 - and it changes all the time with different ratio. Out of those pixels
(and maybe some time) I have to build an AVG Pixel with a defined XY value. AVG
pixel != brightest pixel. For that AVG pixel I could use subpixel, too. I have
to use subpixel because I have to map the low resolution to 1200x900 pixel if I
try to use absolute coordinates.
Where do I get the size 90x30 from? It is not an pixel exact value but a
approximation. It differs.
I tried not to move my eyes but my head and looking to the four corners and the
center of the XO display. The display is very small so I moved my head really
not to much. One infrared filtered result merged from 5 snapshots (four eges
and center) is here:
http://www.olpcaustria.org/mediawiki/upload/7/79/Headtracker_area_small.jpg
It is downsized from 640x480 to 320x240px but the relation is the same.
Maybe I have got a knot in my brain. I really like to get the headtracker
working in a good way without an additional lens.
Again the link to the project site:
http://www.olpcaustria.org/mediawiki/index.php/Headtracker
greeting,
yokoy
On Wed, 5 Sep 2007 12:57:54 -0400
"Luke Hutchison" <[EMAIL PROTECTED]> wrote:
> PS there's a "cheap" way you can accomplish subpixel accuracy, as follows.
> You basically take a bunch of 1D samples through the brightest pixel,
> looking at 2 neighbors in each direction, and then take a weighted sum of
> the results. This calls the code I pasted in the last email. It's not
> going to be as good as paraboloid regression, but it should allow you to
> test feasibility.
>
>
> // Do a 2D parabolic fit to give sub-pixel accuracy for translational
> // registration, by performing four 1D parabolic fits through the closest
> // integer correlation offset: horizontally, vertically, and on the leading
> // and trailing diagonals. Take the weighted centroid of all four to get
> // the true correlation offset.
>
> // off_x and off_y are the one-pixel-accurate correlation offsets recovered
> // by correlation.
>
> // x1d and y1d are x and y values for the 1D quadratic fit function
> double y1d[9] = { // Get magnitudes at (off_x,off_y) and 8 neighbors
> dft_mag(dft, off_x - 1, off_y - 1),
> dft_mag(dft, off_x, off_y - 1),
> dft_mag(dft, off_x + 1, off_y - 1),
> dft_mag(dft, off_x - 1, off_y),
> dft_mag(dft, off_x, off_y),
> dft_mag(dft, off_x + 1, off_y),
> dft_mag(dft, off_x - 1, off_y + 1),
> dft_mag(dft, off_x, off_y + 1),
> dft_mag(dft, off_x + 1, off_y + 1)
> }
>
> // Sum contributions to centroid of each quadratic fit
> double x1d_tot = 0.0, y1d_tot = 0.0, x1d;
>
> // Parabolic fit in horiz direction through correlation maximum
> x1d = parabolic_fit(-1, y1d[3], 0, y1d[4], 1, y1d[5]);
> x1d_tot += x1d;
>
> // Parabolic fit in horiz direction through correlation maximum
> x1d = parabolic_fit(-1, y1d[1], 0, y1d[4], 1, y1d[7]);
> y1d_tot += x1d; // [x1d is x in parabola space, but y in correlation
> space]
>
> // Weight contributions of diagonal by the inverse of their distance
> #define RT2_OV_2 0.7071067811865475244 // sqrt(2)/2 (= 1/sqrt(2))
>
> // Parabolic fit in leading diagonal direction through correlation maximum
> x1d = parabolic_fit(-1, y1d[0], 0, y1d[4], 1, y1d[8]);
> x1d_tot += x1d * RT2_OV_2;
> y1d_tot += x1d * RT2_OV_2;
>
> // Parabolic fit in leading diagonal direction through correlation maximum
> x1d = parabolic_fit(-1, y1d[2], 0, y1d[4], 1, y1d[6]);
> x1d_tot -= x1d * RT2_OV_2;
> y1d_tot += x1d * RT2_OV_2;
>
> // Take centroid of all parabolic fits, weighting diagonals by RT2_OV_2;
> // make relative to correlation coords by adding off_x, off_y
> double subpix_off_x = off_x + x1d_tot / (2.0 + 2.0 * RT2_OV_2);
> double subpix_off_y = off_y + y1d_tot / (2.0 + 2.0 * RT2_OV_2);
>
>
>
> On 9/5/07, Luke Hutchison <[EMAIL PROTECTED]> wrote:
> >
> > Where do you get the size 90x30 from though? Are you saying you can't get
> > at the full-sized frame through the API currently?
> >
> > You really should consider fitting a paraboloid over the dot to get
> > sub-pixel resolution. Note that if the dot is bigger (more than a few
> > pixels), you probably want to just use the weighted centroid, but if it's
> > small, a paraboloid is the right approach. You really will get at least a
> > 10x increase in accuracy in both x and y, bringing your effective resolution
> > to something like 900x300 for the example you gave. You may not even need a
> > lens. I have used this before with success for an image processing project.
> >
> >
> > Here's the code for the 1D version:
> >
> > // Fit a parabola to three points, and return the x coord of the turning
> > // point (point 2 is the central point, points 1 and 3 are its neighbors)
> > double parabolic_fit(double x1, double y1,
> > double x2, doub
Re: Teleconference information for software status meeting ( today, 21:00 EDT Boston)
Jordan Crouse wrote: > IRC++. I would have to encourage a very strict set of rules, to keep > the discussion from going off in the weeds - it is good for more people > to participate, but these meetings do serve a very important purpose. We > don't want to get distracted with topics that could just as easily be > discussed on e-mail or in other IRC forums. I agree with Jordan. Some IRC meetings I've seen use a wiki page as an aid to keep track of the schedule. We could use the announcement in the mailing list as well and send a reply with the resolutions below the quoting. They, also have some moderator giving voice to people in turn so there's no cross-talking. But I'd not be too strict on this, it's not really as annoying as interrupting a speaker. People are supposed to answer with several short sentences to minimize the delay. To mean that they're actually finished answering, they say something like "GA". -- // Bernardo Innocenti - One Laptop Per Child \X/ http://www.codewiz.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: EXA performance
Bernardo Innocenti wrote: > Aleph, could you post an oprofile of Sugar switching between zoom levels > in both 16bpp and 24bpp? Doing it manually by pressing F1 to F4 would be > good enough for me: I just want to get an idea of where we spend the time. > Of course, X, amd_drv, pixman and cairo need to be built with -g. Here are the oprofile results while switching between the 4 Sugar zoom levels for sixty seconds, with the journal displaying past activities at the 4th level. Unfortunately the oprofile callgraph feature doesn't work on the Geode, but I hope these data are of some use anyway. CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt TIMER:0| samples| %| -- 2936 47.6082 python TIMER:0| samples| %| -- 1543 52.5545 libpython2.5.so.1.0 594 20.2316 libcairo.so.2.11.5 276 9.4005 libc-2.6.so 116 3.9510 libgobject-2.0.so.0.1200.13 79 2.6907 libglib-2.0.so.0.1200.13 68 2.3161 libpangoft2-1.0.so.0.1600.4 62 2.1117 libpthread-2.6.so 41 1.3965 libpango-1.0.so.0.1600.4 31 1.0559 libgtk-x11-2.0.so.0.1000.14 24 0.8174 libgdk-x11-2.0.so.0.1000.14 15 0.5109 libfreetype.so.6.3.15 13 0.4428 libhippocanvas-1.so.0.0.0 12 0.4087 libX11.so.6.2.0 10 0.3406 _gobject.so 9 0.3065 librsvg-2.so.2.16.1 8 0.2725 libgthread-2.0.so.0.1200.13 6 0.2044 libpangocairo-1.0.so.0.1600.4 5 0.1703 anon (tgid:2962 range:0xb7fc7000-0xb7fc8000) 5 0.1703 libm-2.6.so 5 0.1703 libXrender.so.1.3.0 5 0.1703 hippo.so 3 0.1022 libdbus-1.so.3.2.0 3 0.1022 _cairo.so 1 0.0341 libwnck-1.so.18.2.10 1 0.0341 libxml2.so.2.6.29 1 0.0341 _gtk.so 2645 42.8896 no-vmlinux 454 7.3618 Xorg TIMER:0| samples| %| -- 202 44.4934 libpixman-1.so.0.9.5 84 18.5022 amd_drv.so 82 18.0617 Xorg 42 9.2511 libexa.so 29 6.3877 libc-2.6.so 12 2.6432 libfb.so 2 0.4405 libextmod.so 1 0.2203 anon (tgid:2942 range:0xb7f83000-0xb7f84000) ... CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt samples %image name app name symbol name 2645 42.8896 no-vmlinux no-vmlinux (no symbols) 1543 25.0203 libpython2.5.so.1.0 python (no symbols) 116 1.8810 libgobject-2.0.so.0.1200.13 python (no symbols) 114 1.8485 libpixman-1.so.0.9.5 Xorg pixman_rasterize_edges 791.2810 libglib-2.0.so.0.1200.13 python (no symbols) 681.1026 libpangoft2-1.0.so.0.1600.4 python (no symbols) 560.9081 amd_drv.so Xorg gp_color_bitmap_to_screen_blt 530.8594 libpixman-1.so.0.9.5 Xorg pixman_fill 470.7621 libcairo.so.2.11.5 python fbRasterizeEdges 460.7459 libc-2.6.so python _int_malloc 460.7459 libc-2.6.so python memcpy 410.6648 libpango-1.0.so.0.1600.4 python (no symbols) 390.6324 libcairo.so.2.11.5 python _PointDistanceSquaredToSegment 350.5675 libc-2.6.so python __ctype_b_loc 340.5513 libc-2.6.so bash __gconv_transform_utf8_internal 310.5027 libgtk-x11-2.0.so.0.1000.14 python (no symbols) 260.4216 bash bash (no symbols) 250.4054 libcairo.so.2.11.5 python _cairo_bentley_ottmann_tessellate_polygon 240.3892 libgdk-x11-2.0.so.0.1000.14 python (no symbols) 230.3730 libc-2.6.so bash mbrtowc 230.3730 libcairo.so.2.11.5 python _cairo_bo_event_queue_insert_if_intersect_below_current_y 200.3243 libc-2.6.so python _int_free 200.3243 libc-2.6.so python msort_with_tmp 200.3243 libpthread-2.6.sopython pthread_mutex_lock 190.3081 libcairo.so.2.11.5 python __divdi3 180.2919 libc-2.6.so python free 180.2919 libcairo.so.2.11.5 python _cairo_pixman_composite_solid_mask_nx8xmmx 180.2919 libcairo.so.2.11.5 python _cairo_pixman_render_sample_floor_y 180.2919 libcairo.so.2.11.5 python _cairo_uint64x64_128_mul 17
Re: Pippy and Calculate
Hi, Chris, > (I'm the Pippy author.) (We didn't have much time to discuss with you while I was in Cambridge two weeks ago...) >> Imagine if Pippy has a button called "Print!", which would be >> located right next to the "Run!" button. And, if "Print!" prints >> out the results of running the program into the bottom pane, that >> is pretty much all we need. (For the record, the workspace in >> Etoys has been there from day one for this purpose.) > > This is a useful idea, thanks. At the moment, Pippy doesn't keep any > variable/program state inbetween "Run!"s (each run is a new Python > interpreter), so there is no way to do "Ans*2"-style calculations. > It sounds like you want "Print!" to keep a single interpreter that > reinterprets the source pane at each click. I didn't think about that aspect, but keeping state will be useful. > The first version of Pippy used a single Python interpreter that > executed the program source code in this way, without losing state, > but that makes it possible to write programs that will not run on a > fresh interpreter later (as they refer to state that was generated > as a result of code that no longer exists, or a previous run of the > code), so I decided against keeping that. Yeh, that can happen in a typical workspace programming. But in Pippy's setting, it would not be much of a problem. "Keep" button can store the state altogether into a journal entry. > Oh! We could have an "example" in Pippy that, when run, gives you a > Python interactive shell. That should work well; it gives you the > mode you want (without requiring an extra button), and is useful in > any case. I'll do that. > > I don't think Python's evaluations are useful as a calculator to > a child, though. You would have to explain this: > > >>> 2+2 > 4 > >>> 3/4 > 0 > > I would like to add a simple graphics screen to Pippy, but I don't > intend it to get many more features past that -- I'd like to keep > it at a simple introduction to input/output programming. Yeah, I was aware of the division (/) problem (when I see the last digit in Calculate falls off to the next line. It would be nice if you can override the division operator... >> We have a real problem of shortage of man-power, so replacing >> smaller activities that take more time to maintain and document >> with more powerful ones is probably a good thing. > > Just a note that Reinier Heeres is a volunteer, so isn't pulling OLPC > man-power away from any other projects. Well, a volunteer can certainly contribute one of OLPC projects, right? I now see that the timeframe and practical matters will probably prevent us going to the nice merging point between these different projects. However, I still contend that similarity is close enough. So, for example Pippy doesn't have to be confined "this is a Python thing" mind, but take advantage of similarity. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Pippy and Calculate
> I don't think Python's evaluations are useful as a calculator to > a child, though. You would have to explain this: > > 2+2 > 4 > 3/4 > 0 > > When I was in elementary school, we first learned division with remainder, so the result of 3 / 4 is 0 remainder 3. Fractions are a more advanced topic, and decimal fractions yet another level. I think we are applying assumptions based on "already having learned the whole wad of mathematics convention" to learners. Mathematics learning is a process. People are not born with algebraic notation wired in; it is an artifice like any other language. People are born with the ability to learn such artifices, but not with a particular one. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: headtracker / mag lens / macro lens ([EMAIL PROTECTED])
PS there's a "cheap" way you can accomplish subpixel accuracy, as follows.
You basically take a bunch of 1D samples through the brightest pixel,
looking at 2 neighbors in each direction, and then take a weighted sum of
the results. This calls the code I pasted in the last email. It's not
going to be as good as paraboloid regression, but it should allow you to
test feasibility.
// Do a 2D parabolic fit to give sub-pixel accuracy for translational
// registration, by performing four 1D parabolic fits through the closest
// integer correlation offset: horizontally, vertically, and on the leading
// and trailing diagonals. Take the weighted centroid of all four to get
// the true correlation offset.
// off_x and off_y are the one-pixel-accurate correlation offsets recovered
// by correlation.
// x1d and y1d are x and y values for the 1D quadratic fit function
double y1d[9] = { // Get magnitudes at (off_x,off_y) and 8 neighbors
dft_mag(dft, off_x - 1, off_y - 1),
dft_mag(dft, off_x, off_y - 1),
dft_mag(dft, off_x + 1, off_y - 1),
dft_mag(dft, off_x - 1, off_y),
dft_mag(dft, off_x, off_y),
dft_mag(dft, off_x + 1, off_y),
dft_mag(dft, off_x - 1, off_y + 1),
dft_mag(dft, off_x, off_y + 1),
dft_mag(dft, off_x + 1, off_y + 1)
}
// Sum contributions to centroid of each quadratic fit
double x1d_tot = 0.0, y1d_tot = 0.0, x1d;
// Parabolic fit in horiz direction through correlation maximum
x1d = parabolic_fit(-1, y1d[3], 0, y1d[4], 1, y1d[5]);
x1d_tot += x1d;
// Parabolic fit in horiz direction through correlation maximum
x1d = parabolic_fit(-1, y1d[1], 0, y1d[4], 1, y1d[7]);
y1d_tot += x1d; // [x1d is x in parabola space, but y in correlation
space]
// Weight contributions of diagonal by the inverse of their distance
#define RT2_OV_2 0.7071067811865475244 // sqrt(2)/2 (= 1/sqrt(2))
// Parabolic fit in leading diagonal direction through correlation maximum
x1d = parabolic_fit(-1, y1d[0], 0, y1d[4], 1, y1d[8]);
x1d_tot += x1d * RT2_OV_2;
y1d_tot += x1d * RT2_OV_2;
// Parabolic fit in leading diagonal direction through correlation maximum
x1d = parabolic_fit(-1, y1d[2], 0, y1d[4], 1, y1d[6]);
x1d_tot -= x1d * RT2_OV_2;
y1d_tot += x1d * RT2_OV_2;
// Take centroid of all parabolic fits, weighting diagonals by RT2_OV_2;
// make relative to correlation coords by adding off_x, off_y
double subpix_off_x = off_x + x1d_tot / (2.0 + 2.0 * RT2_OV_2);
double subpix_off_y = off_y + y1d_tot / (2.0 + 2.0 * RT2_OV_2);
On 9/5/07, Luke Hutchison <[EMAIL PROTECTED]> wrote:
>
> Where do you get the size 90x30 from though? Are you saying you can't get
> at the full-sized frame through the API currently?
>
> You really should consider fitting a paraboloid over the dot to get
> sub-pixel resolution. Note that if the dot is bigger (more than a few
> pixels), you probably want to just use the weighted centroid, but if it's
> small, a paraboloid is the right approach. You really will get at least a
> 10x increase in accuracy in both x and y, bringing your effective resolution
> to something like 900x300 for the example you gave. You may not even need a
> lens. I have used this before with success for an image processing project.
>
>
> Here's the code for the 1D version:
>
> // Fit a parabola to three points, and return the x coord of the turning
> // point (point 2 is the central point, points 1 and 3 are its neighbors)
> double parabolic_fit(double x1, double y1,
> double x2, double y2,
> double x3, double y3) {
>
> double a = (y3 - y2) / ((x3 - x2) * (x3 - x1)) -
> (y1 - y2) / ((x1 - x2) * (x3 - x1));
>
> double b = (y1 - y2 + a * (x2 * x2 - x1 * x1)) / (x1 - x2);
>
> double xmin = x2; // Just use central point if parabola is flat
> if (fabs(a) > EPSILON)
> xmin = -b / (2 * a); // [avoids division by zero]
>
> // Use the following to calculate the y-value at the turning point
> // of the parabola:
> //
> // double c = y1 - a * x1 * x1 - b * x1;
> // double ymin = a * xmin * xmin + b * xmin + c;
>
> return xmin;
> }
>
> I don't have code for the 2D version unfortunately.
>
> The 2D version (fitting a paraboloid to a neighborhood of more than four
> points total) is overspecified, as is the 1D version if fitting a parabola
> to more than three points (e.g. using two neighbors on either side of the
> brightest pixel). Thus you need to do some sort of regression to find the
> best fit. I'm sure there is code out there to accomplish this.
>
> Luke
>
>
> On 9/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >
> > Hello Luke,
> >
> > On Tue, 4 Sep 2007 16:11:34 -0700
> > "Luke Hutchison" < [EMAIL PROTECTED]> wrote:
> >
> > > Is the processing time for 640x480 the reason you're only using 90x30?
> > >
> >
> > No, I am not at the point thinking about optimization the processing
> > time.
> > You don't want to dance in front of the camera to control the mouse
> > pointer. You just want t
Re: headtracker / mag lens / macro lens ([EMAIL PROTECTED])
Where do you get the size 90x30 from though? Are you saying you can't get
at the full-sized frame through the API currently?
You really should consider fitting a paraboloid over the dot to get
sub-pixel resolution. Note that if the dot is bigger (more than a few
pixels), you probably want to just use the weighted centroid, but if it's
small, a paraboloid is the right approach. You really will get at least a
10x increase in accuracy in both x and y, bringing your effective resolution
to something like 900x300 for the example you gave. You may not even need a
lens. I have used this before with success for an image processing project.
Here's the code for the 1D version:
// Fit a parabola to three points, and return the x coord of the turning
// point (point 2 is the central point, points 1 and 3 are its neighbors)
double parabolic_fit(double x1, double y1,
double x2, double y2,
double x3, double y3) {
double a = (y3 - y2) / ((x3 - x2) * (x3 - x1)) -
(y1 - y2) / ((x1 - x2) * (x3 - x1));
double b = (y1 - y2 + a * (x2 * x2 - x1 * x1)) / (x1 - x2);
double xmin = x2; // Just use central point if parabola is flat
if (fabs(a) > EPSILON)
xmin = -b / (2 * a); // [avoids division by zero]
// Use the following to calculate the y-value at the turning point
// of the parabola:
//
// double c = y1 - a * x1 * x1 - b * x1;
// double ymin = a * xmin * xmin + b * xmin + c;
return xmin;
}
I don't have code for the 2D version unfortunately.
The 2D version (fitting a paraboloid to a neighborhood of more than four
points total) is overspecified, as is the 1D version if fitting a parabola
to more than three points (e.g. using two neighbors on either side of the
brightest pixel). Thus you need to do some sort of regression to find the
best fit. I'm sure there is code out there to accomplish this.
Luke
On 9/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Hello Luke,
>
> On Tue, 4 Sep 2007 16:11:34 -0700
> "Luke Hutchison" <[EMAIL PROTECTED]> wrote:
>
> > Is the processing time for 640x480 the reason you're only using 90x30?
> >
>
> No, I am not at the point thinking about optimization the processing time.
> You don't want to dance in front of the camera to control the mouse
> pointer. You just want to move your head a few degrees as if you would look
> to the edges of the display without moving your eyes. Then the area
> recognized from the camera is very small. It is like moving the mouse only
> one or two millimeters to move the mousepointer over the whole desktop. To
> get more 'delta pixel' I need a mag lens, I think.
>
> regards,
>
> yokoy
>
>
>
> > You can actually dramatically increase the precision to which you can
> read
> > back the bright point's location by fitting a paraboloid to the
> intensity
> > values in the neighborhood of the brightest pixel, then reading off the
> > location of the extremum of the paraboloid. You will get at least one
> order
> > of magnitude more accuracy that way than looking at the integer coords
> of
> > the brightest pixel (perhaps as much as two orders of magnitude).
> >
> > Luke
> >
> >
> > On 9/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >
> > > Hello Mary Lou,
> > >
> > > On Tue, 04 Sep 2007 12:13:34 -0400
> > > Mary Lou Jepsen <[EMAIL PROTECTED]> wrote:
> > >
> > > > lenses are cheap. it depends on what exactly you are doing with the
> > > > software.
> > >
> > > tracking a little shiny point at the head and transform it into
> > > mousepointer movements. Here is the description:
> > > http://www.olpcaustria.org/mediawiki/index.php/Headtracker
> > >
> > > With the XO camera we typicaly use only 90x30 pixel from the 640x480
> > > pixel. So I want to magnify the operative area with a lens.
> > > Here is a picture of the area:
> > >
> > >
> http://www.olpcaustria.org/mediawiki/index.php/Headtracker#magnification_lens
> > >
> > >
> > >
> > > > American Science and Surplus is a good way to experiment:
> > > > http://sciplus.com/category.cfm?subsection=21
> > > >
> > >
> > > thank you for that link. A plastic lens is what I am searching for.
> > >
> > >
> > > > then to china for mass production at very low price point.
> > > >
> > > >
> > > > - Mary Lou
> > > >
> > > >
> > >
> > > regards,
> > >
> > > yokoy
> > > --
> > >
> > > ___
> > > Devel mailing list
> > > Devel@lists.laptop.org
> > > http://lists.laptop.org/listinfo/devel
> > >
> >
>
>
> --
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Teleconference information for software status meeting ( today, 21:00 EDT Boston)
On 05/09/07 11:55 -0400, Chris Ball wrote: > Hi, > >> DIAL IN: >> From the United States: 866-213-2185 >> From Outside the United States: 1-609-454-9914 > > The audio quality on last night's call was awful. What's the interest > like (from current call participants) in moving the meetings to IRC? IRC++. I would have to encourage a very strict set of rules, to keep the discussion from going off in the weeds - it is good for more people to participate, but these meetings do serve a very important purpose. We don't want to get distracted with topics that could just as easily be discussed on e-mail or in other IRC forums. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Teleconference information for software status meeting (today, 21:00 EDT Boston)
Hi all, im agree with moving the confcal to IRC for these reasons: advantages: -Every one gets informed -zero noise problems disadvantages -Slower,,, On 9/5/07, Chris Ball <[EMAIL PROTECTED]> wrote: > > Hi, > >> DIAL IN: >> From the United States: 866-213-2185 >> From Outside the United States: 1-609-454-9914 > > The audio quality on last night's call was awful. What's the interest > like (from current call participants) in moving the meetings to IRC? > > The advantages that I see are: >* people who can't make a phone call for some reason are able to join >* several people can talk at once, which might save time >* we get a full transcription of "minutes" for free, although we > should probably still summarize the conversation > > I propose having a trial run on IRC for next week's conference. > If anyone who wants to be on the call is unable or unwilling to use > IRC, we could consider opening up the bridge in order to relay their > questions to the conference. Thoughts? > > Thanks, > > - Chris. > -- > Chris Ball <[EMAIL PROTECTED]> > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > -- Rafael Enrique Ortiz Guerrero OLPC Colombia http://wiki.laptop.org/go/OLPC_Colombia [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Teleconference information for software status meeting (today, 21:00 EDT Boston)
Chris Ball wrote: >> DIAL IN: >> From the United States: 866-213-2185 >> From Outside the United States: 1-609-454-9914 > > The audio quality on last night's call was awful. What's the interest > like (from current call participants) in moving the meetings to IRC? IRC would certainly make it easier for me to participate. On yesterday's call, I realized I was telling J5 the same thing he had just said a few seconds earlier! :-) Also, was the time of 21:00 EDT chosen for a particular reason? Because people from Europe are hardly able to participate at that time. 17:00 EDT would be 23:00 CEST... Way more feasible. -- // Bernardo Innocenti - One Laptop Per Child \X/ http://www.codewiz.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Teleconference information for software status meeting (today, 21:00 EDT Boston)
Hi, > DIAL IN: > From the United States: 866-213-2185 > From Outside the United States: 1-609-454-9914 The audio quality on last night's call was awful. What's the interest like (from current call participants) in moving the meetings to IRC? The advantages that I see are: * people who can't make a phone call for some reason are able to join * several people can talk at once, which might save time * we get a full transcription of "minutes" for free, although we should probably still summarize the conversation I propose having a trial run on IRC for next week's conference. If anyone who wants to be on the call is unable or unwilling to use IRC, we could consider opening up the bridge in order to relay their questions to the conference. Thoughts? Thanks, - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Pippy and Calculate
Hi Yoshiki, (I'm the Pippy author.) > Imagine if Pippy has a button called "Print!", which would be > located right next to the "Run!" button. And, if "Print!" prints > out the results of running the program into the bottom pane, that > is pretty much all we need. (For the record, the workspace in > Etoys has been there from day one for this purpose.) This is a useful idea, thanks. At the moment, Pippy doesn't keep any variable/program state inbetween "Run!"s (each run is a new Python interpreter), so there is no way to do "Ans*2"-style calculations. It sounds like you want "Print!" to keep a single interpreter that reinterprets the source pane at each click. The first version of Pippy used a single Python interpreter that executed the program source code in this way, without losing state, but that makes it possible to write programs that will not run on a fresh interpreter later (as they refer to state that was generated as a result of code that no longer exists, or a previous run of the code), so I decided against keeping that. Oh! We could have an "example" in Pippy that, when run, gives you a Python interactive shell. That should work well; it gives you the mode you want (without requiring an extra button), and is useful in any case. I'll do that. I don't think Python's evaluations are useful as a calculator to a child, though. You would have to explain this: >>> 2+2 4 >>> 3/4 0 I would like to add a simple graphics screen to Pippy, but I don't intend it to get many more features past that -- I'd like to keep it at a simple introduction to input/output programming. > We have a real problem of shortage of man-power, so replacing > smaller activities that take more time to maintain and document > with more powerful ones is probably a good thing. Just a note that Reinier Heeres is a volunteer, so isn't pulling OLPC man-power away from any other projects. Thanks! - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: How does "record" activity the camera in Sugar?
From the terminal, can you run: gst-launch-0.10 v4l2src ! xvimagesink and report if you get the same problem? Also, try: gst-launch-0.10 videotestsrc ! xvimagesink I look forward to the results of these tests. Thank you, Erik On 9/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Sorry, I forget to say. > > In the Nand flash image is 542. > > But I use USB whose image is 515 to boot, has the same event. > > Luna > > > -- > > *From:* Erik Blankinship [mailto:[EMAIL PROTECTED] > *Sent:* Wednesday, September 05, 2007 9:02 PM > *To:* Luna Huang (黃綉玲) > *Cc:* devel@lists.laptop.org > *Subject:* Re: How does "record" activity the camera in Sugar? > > > > Good morning Luna > > Can you please take a photograph of your XO (with another camera), so that > we can see the visual problem? > > Also, which build are you using? > > Thank you > Erik > > On 9/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > There is one question need someone tells me. > > How does "record" activity the camera in Sugar? > > I have one C test machine which has question. > > When I open "record" item, can fine there are some straight lines on left > of a real-time display of the camera's input being shown. > > The lines are highly concentrated to make the left of portrait is > indistinct. > > And all of real-time display has noise to make display is disturbance. > > Use "test /camera" on OFW, I did not fine the event. > > I have done the memory test is no problem. > > Boot from USB, the event also exists. > > I think it is HW question. But I don't know there has different between > "record" and OFW. > > Please give idea to help me analysis quick. > > Thanks. > > Best Regards, > > - > > Luna Huang / 黃綉玲 > > *Quanta EPBU* > > Software Dept. *Engineer* > > Tel : 886-3-327-2345 EXT:18921 > > > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: How does "record" activity the camera in Sugar?
Sorry, I forget to say. In the Nand flash image is 542. But I use USB whose image is 515 to boot, has the same event. Luna From: Erik Blankinship [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 05, 2007 9:02 PM To: Luna Huang (�S��玲) Cc: devel@lists.laptop.org Subject: Re: How does "record" activity the camera in Sugar? Good morning Luna Can you please take a photograph of your XO (with another camera), so that we can see the visual problem? Also, which build are you using? Thank you Erik On 9/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: There is one question need someone tells me. How does "record" activity the camera in Sugar? I have one C test machine which has question. When I open "record" item, can fine there are some straight lines on left of a real-time display of the camera's input being shown. The lines are highly concentrated to make the left of portrait is indistinct. And all of real-time display has noise to make display is disturbance. Use "test /camera" on OFW, I did not fine the event. I have done the memory test is no problem. Boot from USB, the event also exists. I think it is HW question. But I don't know there has different between "record" and OFW. Please give idea to help me analysis quick. Thanks. Best Regards, - Luna Huang / �S��玲 Quanta EPBU Software Dept. Engineer Tel : 886-3-327-2345 EXT:18921 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: How does "record" activity the camera in Sugar?
Good morning Luna Can you please take a photograph of your XO (with another camera), so that we can see the visual problem? Also, which build are you using? Thank you Erik On 9/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > There is one question need someone tells me. > > How does "record" activity the camera in Sugar? > > I have one C test machine which has question. > > When I open "record" item, can fine there are some straight lines on left > of a real-time display of the camera's input being shown. > > The lines are highly concentrated to make the left of portrait is > indistinct. > > And all of real-time display has noise to make display is disturbance. > > Use "test /camera" on OFW, I did not fine the event. > > I have done the memory test is no problem. > > Boot from USB, the event also exists. > > I think it is HW question. But I don't know there has different between > "record" and OFW. > > Please give idea to help me analysis quick. > > Thanks. > > Best Regards, > > - > > Luna Huang / 黃綉玲 > > *Quanta EPBU* > > Software Dept. *Engineer*** > > Tel : 886-3-327-2345 EXT:18921 > > > > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
How does "record" activity the camera in Sugar?
There is one question need someone tells me. How does "record" activity the camera in Sugar? I have one C test machine which has question. When I open “record” item, can fine there are some straight lines on left of a real-time display of the camera’s input being shown. The lines are highly concentrated to make the left of portrait is indistinct. And all of real-time display has noise to make display is disturbance. Use “test /camera” on OFW, I did not fine the event. I have done the memory test is no problem. Boot from USB, the event also exists. I think it is HW question. But I don’t know there has different between “record” and OFW. Please give idea to help me analysis quick. Thanks. Best Regards, - Luna Huang / �S��玲 Quanta EPBU Software Dept. Engineer Tel : 886-3-327-2345 EXT:18921 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Pippy and Calculate
Hi All, This is just a thought, but for a while I have been thinking about providing hooks into python from existing activities. What if Calculate provided a button that hooked into Pippy - when the button is pressed, Pippy would pop up, showing the underlying python code that is producing the math equation being focused on in Calculate. I think this could be a great way to introduce children to python with context. This could be thought of as as a gentle 'view source', focusing on math within python. More generally, I would love to see such a hook in other activities to provide hooks into python in a specific context. Just an idea. Cheers, Julius --- Please Reply to My Permanent Address: [EMAIL PROTECTED] http://www.openwetware.org/wiki/User:Julius_B._Lucks On Sep 5, 2007, at 3:06 AM, Walter Bender wrote: While in the abstract, Yoshiki has a great idea, I see three problems: (1) Especially for young children who are just beginning to read and write, imposing Python and its syntax on them is to high of a hurdle for accessing a calculator; (2) While I love Pippy, it has a long ways to go towards being friendly to the uninitiated: there is no debugger, for example; This is fine for the purposes for which it was designed, but to use it for a general purpose tool is a real stretch; (3) Reinier has added a very approachable feature set to the latest versions of the Calculator Activity: it lets you define variables and hence contruct word problems. It isn't a full-blown programmng environment, but it is one of many stepping stones for younger children. I would almost go so far as to agree with Yoshiki that for the more advanced calculator features: trig fucntions, etc., we do make the leap into Pippy or Etoys, but there is something simple and approachable to Reinier's work. -walter ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Pippy and Calculate
hi, On Wed, 05 Sep 2007 13:00:50 +0200 Reinier Heeres <[EMAIL PROTECTED]> wrote: ... > I just think the two activities are suited for different > things. ... yes, I agree. A calculator is not to learn python. Some time ago the calculator activity looks like real pocket calculator and I think that was a good way. I was a bit disappointed about some changes the calculator overcomes. I like the idea to put some interface stuff from the TI89 and the option to program inside the calculator activity. Pippy is more an activity to learn python, did I understand right? So you could also do math in it but it is not in the first place a calculator. I like Pippy (oh, what a sentence. For german ears it sounds like 'I like wee-wee' :-) but it is not the right activity to replace a calculator IMHO. regards, yokoy -- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Pippy and Calculate
Yoshiki, Yoshiki Ohshima wrote: > Reinier, > > Firstly, I apologize if my first email sounded too harsh to you. > (It definitely didn't mean to be personal.) > That's alright, I could have phrased it a little differently as well actually! I just think the two activities are suited for different things. Calculate is now more focussed on collaboration than the previous version, and the interface aims to resemble a calculator and expose the user to mathematics directly. Maybe I can include some extra educational features as well, like a help() command that explains things about functions. Pippy, for now, looks (to me) like a one-person activity, although I can imagine inclusion of a similar 'output-history' window to integrate the collaboration aspect. On the other hand, I was thinking about allowing user-written functions in Calculate as well. I guess part of the success of the TI89 style calculators is that children can program stuff for it. In the end, Calculate functionality might overlap a little with Pippy. However, some overlap should not be a problem: for example, I designed Calculate so that it's easy to implement arbitrary precision math in the future. The end-user will never have to adjust to this underlying change, and can just continue to think about the relevant aspect of the activity: math. >> Being the main Calculate developer, I don't agree on your opinion about >> Calculate. I think it deserves to be a separate activity. It's true that >> it was a little underdeveloped lately, but that was mainly because I was >> on a (long) holiday. The last couple of days have produced major >> improvements in Calculate: tab-completion of variable names, copy-paste, >> journal support, etc. (not sure if it made it into the build yet, did a >> release though: http://rwh.corps.nl/Calculate-7.xo). More new features >> are coming, for example I just started working on a plot() function (an >> obviously useful extension), which I estimate to be functioning >> somewhere next week. >> > > It was not so much as Calculate is underdeveloped or not, I > think. (Almost every end-user software including Etoys is > underdeveloped). But looking at the similarity of Pippy and Calculate, > for example the plot feature you are making could be beneficial for > both, right? And, you would wish to have a calculator whose syntax is > closer to Python, right? > I'm not sure. I think the main goal is to have the syntax as close to (written) math as possible. >> There seem to be some performace issues with Calculate on the XO. I >> haven't been able to profile these yet, but I expect them to be related >> to the way the application is shared (basic sharing should be >> functioning). This problem has the highest priority now... >> > > Yes. I filed a bug report for it. The length of old expressions > seems to be strongly affecting the performance. > > >> The equation parser I wrote isn't perfect yet either, although in >> general it does a pretty good job at parsing simple as well as more >> complex expressions. Please file bug reports if you notice weird behavior... >> > > Yes. I did it, too. It must be something to do with an error within > parenthesis. > I saw that and fixed it, thanks :-) > -- Yoshiki > Cheers, Reinier ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: headtracker / mag lens / macro lens ([EMAIL PROTECTED])
Hello Luke, On Tue, 4 Sep 2007 16:11:34 -0700 "Luke Hutchison" <[EMAIL PROTECTED]> wrote: > Is the processing time for 640x480 the reason you're only using 90x30? > No, I am not at the point thinking about optimization the processing time. You don't want to dance in front of the camera to control the mouse pointer. You just want to move your head a few degrees as if you would look to the edges of the display without moving your eyes. Then the area recognized from the camera is very small. It is like moving the mouse only one or two millimeters to move the mousepointer over the whole desktop. To get more 'delta pixel' I need a mag lens, I think. regards, yokoy > You can actually dramatically increase the precision to which you can read > back the bright point's location by fitting a paraboloid to the intensity > values in the neighborhood of the brightest pixel, then reading off the > location of the extremum of the paraboloid. You will get at least one order > of magnitude more accuracy that way than looking at the integer coords of > the brightest pixel (perhaps as much as two orders of magnitude). > > Luke > > > On 9/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > Hello Mary Lou, > > > > On Tue, 04 Sep 2007 12:13:34 -0400 > > Mary Lou Jepsen <[EMAIL PROTECTED]> wrote: > > > > > lenses are cheap. it depends on what exactly you are doing with the > > > software. > > > > tracking a little shiny point at the head and transform it into > > mousepointer movements. Here is the description: > > http://www.olpcaustria.org/mediawiki/index.php/Headtracker > > > > With the XO camera we typicaly use only 90x30 pixel from the 640x480 > > pixel. So I want to magnify the operative area with a lens. > > Here is a picture of the area: > > > > http://www.olpcaustria.org/mediawiki/index.php/Headtracker#magnification_lens > > > > > > > > > American Science and Surplus is a good way to experiment: > > > http://sciplus.com/category.cfm?subsection=21 > > > > > > > thank you for that link. A plastic lens is what I am searching for. > > > > > > > then to china for mass production at very low price point. > > > > > > > > > - Mary Lou > > > > > > > > > > regards, > > > > yokoy > > -- > > > > ___ > > Devel mailing list > > Devel@lists.laptop.org > > http://lists.laptop.org/listinfo/devel > > > -- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Help with git
Jameson "Chema" Quinn wrote: > I am having some problems with git - essentially, my .gitignore and > core/editor config options are not working. The "core.editor" config option works fine here (git version 1.5.3.rc6.17.g1911). Maybe the files are encoded with MS-DOS style EOLs? Just a guess. > If you can help, THANK YOU. Please respond to this problem on > http://wiki.laptop.org/go/Talk:Git to avoid clogging up the list. For help and support, IRC generally works better than mailing-lists or wikis, because we can interactively ask you to issue some commands and report the results. We mostly hang on the #olpc channel. But for git support, the #git channel is probably a better bet. -- // Bernardo Innocenti - One Laptop Per Child \X/ http://www.codewiz.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Pippy and Calculate
Hello, Walter, Thank you for the comment. > (1) Especially for young children who are just beginning to read and > write, imposing Python and its syntax on them is to high of a hurdle > for accessing a calculator; Yes. But, Pippy can pretend that it is not about Python at first. The user can type "3+4" into the top pane, and if there is a "Print!" button, the user would see "7" in the lower pane. I could imagine to have number and four basic arithmetic buttons on screen. > (2) While I love Pippy, it has a long ways to go towards being > friendly to the uninitiated: there is no debugger, for example; This > is fine for the purposes for which it was designed, but to use it for > a general purpose tool is a real stretch; This is true. For example, I think there should be a way to stop a long running execution (a la keyboard interrupt). > (3) Reinier has added a very approachable feature set to the latest > versions of the Calculator Activity: it lets you define variables and > hence contruct word problems. It isn't a full-blown programmng > environment, but it is one of many stepping stones for younger > children. > > I would almost go so far as to agree with Yoshiki that for the more > advanced calculator features: trig fucntions, etc., we do make the > leap into Pippy or Etoys, but there is something simple and > approachable to Reinier's work. Gradual progression when a child is learning is something we think about a lot. I tend to think that the progression as "removing fences". The introductory version shows something simpler, but as the child learns more, he will be able to access more. And, I have some prejudice that to make the progression smoother, it would be nice if the environment is kept the same, but make the kid realize that these seemingly different interfaces are just facets are the same thing. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Pippy and Calculate
Reinier, Firstly, I apologize if my first email sounded too harsh to you. (It definitely didn't mean to be personal.) > Being the main Calculate developer, I don't agree on your opinion about > Calculate. I think it deserves to be a separate activity. It's true that > it was a little underdeveloped lately, but that was mainly because I was > on a (long) holiday. The last couple of days have produced major > improvements in Calculate: tab-completion of variable names, copy-paste, > journal support, etc. (not sure if it made it into the build yet, did a > release though: http://rwh.corps.nl/Calculate-7.xo). More new features > are coming, for example I just started working on a plot() function (an > obviously useful extension), which I estimate to be functioning > somewhere next week. It was not so much as Calculate is underdeveloped or not, I think. (Almost every end-user software including Etoys is underdeveloped). But looking at the similarity of Pippy and Calculate, for example the plot feature you are making could be beneficial for both, right? And, you would wish to have a calculator whose syntax is closer to Python, right? > There seem to be some performace issues with Calculate on the XO. I > haven't been able to profile these yet, but I expect them to be related > to the way the application is shared (basic sharing should be > functioning). This problem has the highest priority now... Yes. I filed a bug report for it. The length of old expressions seems to be strongly affecting the performance. > The equation parser I wrote isn't perfect yet either, although in > general it does a pretty good job at parsing simple as well as more > complex expressions. Please file bug reports if you notice weird behavior... Yes. I did it, too. It must be something to do with an error within parenthesis. -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Pippy and Calculate
While in the abstract, Yoshiki has a great idea, I see three problems: (1) Especially for young children who are just beginning to read and write, imposing Python and its syntax on them is to high of a hurdle for accessing a calculator; (2) While I love Pippy, it has a long ways to go towards being friendly to the uninitiated: there is no debugger, for example; This is fine for the purposes for which it was designed, but to use it for a general purpose tool is a real stretch; (3) Reinier has added a very approachable feature set to the latest versions of the Calculator Activity: it lets you define variables and hence contruct word problems. It isn't a full-blown programmng environment, but it is one of many stepping stones for younger children. I would almost go so far as to agree with Yoshiki that for the more advanced calculator features: trig fucntions, etc., we do make the leap into Pippy or Etoys, but there is something simple and approachable to Reinier's work. -walter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
