Summary:
Davis begins this rather informative paper by explaining the title (English use of plural verbs) and how there are many different thoughts of what "are" intelligence. He explains the different views of reasoning, including mathematical, psychological, biological, statistical, and economical. He then goes on to explain different views of how intelligence has evolved and why it has evolved, using various views on early humans hunting skills, socializing skills, etc. The next section discusses less "human" variations on intelligence, showing different animals that have proven to be much more intelligent than most of their kind (or at least a human perception of their kind).
Discussion:
While this paper has little to do with sketch recognition, it is a very interesting read. Davis provides a great deal of information while keeping a neutral stance. When questioned in an interview, he specifically tried not to single any idea out as the best, worst, or even most in need of further consideration.
What I like about this paper is that it explains that if humans ever expect to develop a "strong AI" machine, we cannot continue to focus on things like rational, statistical logic. Intelligence is a product of evolution, shown by the lack of symmetry in the human brain, and a slow and steady process at that. If human scientists intend to create a human-like computer brain, they are going to have to cover thousands and thousands of years worth of history, let alone what little we know of before history was written.
Personally, I didn't believe that a true "strong AI" unit would ever be produced. We will have computers that think 1000 times faster and more efficient than humans, be able to make decisions in practically any situation, and perhaps even be superior to humans in almost every way, but it will never be able to emulate the random quirks that exist in every human. What I was intrigued and somewhat baffled by, however, is Davis' inclusion of "biology" in the reasoning list. I think this will be the defining step in AI, and the major hurdle and seemingly unscale-able wall that seperates "weak AI" from the real "strong AI". This will be the small flickers of random and illogical thought that happen to humans, the unexplainable phenomenon that separate humans and machines at the present.
Wednesday, December 12, 2007
21 - SketchREAD
Summary:
Alvarado's SketchREAD is a system based on Bayesian networks to cut down on the time-consuming task of checking every line with every template match. The system uses both a top-down method and a bottom-up approach. The top-down comes from unfinished shapes, and looks for the missing pieces of possible template matches. It will do this continuously if necessary. Bottom-up is similar to LADDER's approach, where each drawing is recognized as a primitive and the drawing builds upon itself. The system will also "prune" interpretations from the top-down approach, finally selecting the best fit after removing all the unlikely ones. Results show that SketchREAD improves upon baseline numbers, very highly in trees and significantly in circuit diagrams as well.
Discussion:
I wish I could test this system out. This system seems like a very nice alternative to LADDER and definitely in the running. I believe the different methods used within SketchREAD should definitely be looked at more closely, as using both top-down and bottom-up recognition techniques seems to be a great asset. I think integrating these techniques into existing systems would almost always increase recognition, but without knowing all the domains that exist, it's not certain. Still, I'd like to see more domains tested with these innovative ideas.
Alvarado's SketchREAD is a system based on Bayesian networks to cut down on the time-consuming task of checking every line with every template match. The system uses both a top-down method and a bottom-up approach. The top-down comes from unfinished shapes, and looks for the missing pieces of possible template matches. It will do this continuously if necessary. Bottom-up is similar to LADDER's approach, where each drawing is recognized as a primitive and the drawing builds upon itself. The system will also "prune" interpretations from the top-down approach, finally selecting the best fit after removing all the unlikely ones. Results show that SketchREAD improves upon baseline numbers, very highly in trees and significantly in circuit diagrams as well.
Discussion:
I wish I could test this system out. This system seems like a very nice alternative to LADDER and definitely in the running. I believe the different methods used within SketchREAD should definitely be looked at more closely, as using both top-down and bottom-up recognition techniques seems to be a great asset. I think integrating these techniques into existing systems would almost always increase recognition, but without knowing all the domains that exist, it's not certain. Still, I'd like to see more domains tested with these innovative ideas.
20 - 1$ Recognizer
Summary:
Wobbrock et al explain their new recognizer that can be written with little mathematical background in this system. It's given in four easy to follow steps - resampling, rotation, scaling, and classification. It begins by taking N samples from the gesture, defined by the system designer, then rotates it to be horizontal from the start point to the middle of the gesture (N/2 point). Then the gesture is scaled to fit in a specified bounding box and translated to be at the origin. The gesture is then error-checked by the system to match to the list of existing shapes. Results are very high (around 98%) with simple shapes and a decent amount of existing templates.
Discussion:
While this recognizer seems to have no significance in furthering the field, I believe it is necessary to the advancement into the next evolution of sketch recognition. The real benefit of this system is not in how much it advances the field, but more in how it draws new people into the field. This system is meant as a "first step" into sketch recognition, which was, before now, Rubine's feature system. As a beginner in the field myself, I see this paper as a much prettier and "fun" approach of entering sketch recognition, as Rubine's method is much more intimidating than this sytem. I believe that this system will be useful in drawing fresh ideas from less mathematically inclined designers.
Wobbrock et al explain their new recognizer that can be written with little mathematical background in this system. It's given in four easy to follow steps - resampling, rotation, scaling, and classification. It begins by taking N samples from the gesture, defined by the system designer, then rotates it to be horizontal from the start point to the middle of the gesture (N/2 point). Then the gesture is scaled to fit in a specified bounding box and translated to be at the origin. The gesture is then error-checked by the system to match to the list of existing shapes. Results are very high (around 98%) with simple shapes and a decent amount of existing templates.
Discussion:
While this recognizer seems to have no significance in furthering the field, I believe it is necessary to the advancement into the next evolution of sketch recognition. The real benefit of this system is not in how much it advances the field, but more in how it draws new people into the field. This system is meant as a "first step" into sketch recognition, which was, before now, Rubine's feature system. As a beginner in the field myself, I see this paper as a much prettier and "fun" approach of entering sketch recognition, as Rubine's method is much more intimidating than this sytem. I believe that this system will be useful in drawing fresh ideas from less mathematically inclined designers.
19 - Multiscale Models of Temporal Patterns
Summary:
Sezgin et al write about how temporal patterns in user drawing process can be used to determine recognition. The paper discusses the different equations that can be used to find patterns, as well as how Hidden Markov Models can be used coinciding with these equations to find possible recognition rates. Using both gives a decently accurate sample of what the user intends to draw, except for the 'transistor' sketch on a circuit diagram. This is usually caused by segmentation with a wire being drawn after the main part of the transistor and before the "rebounded" part of the transistor. Sezgin et al compensate for that, looking further in the drawing queue for similar examples, basically translating the wire after the "rebounded" part. Results are quite impressive, usually in the 80-90% correct recognition.
Discussion:
While I believe there is a future in this way of thinking, I'm not sure about the exact direction. The paper seems to rely heavily on time data, which is not a TERRIBLE idea but can lead to a dependent relationship between the computer and specific users. The idea that people draw things in a specific order is great in theory, but sketches are usually used in a design process, and when designers design something "new" they usually don't always think linearly. For example, and architect usually draws an outlying structure of a house before putting in the interior walls, to make sure everything fits. But when he gets free reign to build something from scratch, rooms will be continuously added to an existing building, changing the outer wall again and again. I don't think these problems would make the system completely useless, but more work would be needed to keep a domain-independent status.
Sezgin et al write about how temporal patterns in user drawing process can be used to determine recognition. The paper discusses the different equations that can be used to find patterns, as well as how Hidden Markov Models can be used coinciding with these equations to find possible recognition rates. Using both gives a decently accurate sample of what the user intends to draw, except for the 'transistor' sketch on a circuit diagram. This is usually caused by segmentation with a wire being drawn after the main part of the transistor and before the "rebounded" part of the transistor. Sezgin et al compensate for that, looking further in the drawing queue for similar examples, basically translating the wire after the "rebounded" part. Results are quite impressive, usually in the 80-90% correct recognition.
Discussion:
While I believe there is a future in this way of thinking, I'm not sure about the exact direction. The paper seems to rely heavily on time data, which is not a TERRIBLE idea but can lead to a dependent relationship between the computer and specific users. The idea that people draw things in a specific order is great in theory, but sketches are usually used in a design process, and when designers design something "new" they usually don't always think linearly. For example, and architect usually draws an outlying structure of a house before putting in the interior walls, to make sure everything fits. But when he gets free reign to build something from scratch, rooms will be continuously added to an existing building, changing the outer wall again and again. I don't think these problems would make the system completely useless, but more work would be needed to keep a domain-independent status.
Monday, November 12, 2007
018 - Multimodal Interaction
Summary:
Adler et al describe a system where users draw sketches and interact verbally with the computer. The user can just talk and explain what they are drawing, or the computer will ask questions when unsure. The paper describes a Wizard of Oz type user study with an "experimenter" person sitting in pretending to be the computer. The experimenter asked the user questions to clarify the user's intent. He had his own screen to view the drawing, but avoided eye contact with the user. The study showed that user's tend to over-clarify their answers to simple questions, and they also pause their speech to finish their drawing.
Discussion:
Really some very interesting results. I can't help but think of the old starship computer on Star Trek when I think of talking and pressing buttons. Sadly, these results are still inconclusive in my mind, as the study WAS a Wizard of Oz and NOT a real computer. There is a HUGE transition between a person sitting across the table and a computer talking to you, both with the programming and with the attitude of the user. All in all, it's a very interesting idea, but a bit obscure. The paper was all about a user study, but further testing needs to be done for anything solid.
Adler et al describe a system where users draw sketches and interact verbally with the computer. The user can just talk and explain what they are drawing, or the computer will ask questions when unsure. The paper describes a Wizard of Oz type user study with an "experimenter" person sitting in pretending to be the computer. The experimenter asked the user questions to clarify the user's intent. He had his own screen to view the drawing, but avoided eye contact with the user. The study showed that user's tend to over-clarify their answers to simple questions, and they also pause their speech to finish their drawing.
Discussion:
Really some very interesting results. I can't help but think of the old starship computer on Star Trek when I think of talking and pressing buttons. Sadly, these results are still inconclusive in my mind, as the study WAS a Wizard of Oz and NOT a real computer. There is a HUGE transition between a person sitting across the table and a computer talking to you, both with the programming and with the attitude of the user. All in all, it's a very interesting idea, but a bit obscure. The paper was all about a user study, but further testing needs to be done for anything solid.
017 - Three Main Concerns in Sketch Recognition
Summary:
In this paper Mahoney and Fromherz describe what they call the three main concerns and then show a system that vaguely covers the three concerns. The three concerns are dealing with human inaccuracy in sketches, being interactive, and being able to add new features later. The system described deals with "stick figure finding". It searches through the sketch checking every single line for different labels. For example, a body has 5 attached lines - a head, 2 arms, and 2 legs. Using an algorithm, the system goes through each line and checks to see if it is a body, and eventually finds the optimal solution. This allows for context lines not to be included in the figure and be seperated.
Discussion:
Two words: NO RESULTS. This algorithm sounds TERRIBLY slow, even though the algorithm is presented in another paper. It seems this paper is totally misnamed, because it has very little to do with the three "main concerns" of sketch recognition past the Introduction. The algorithm behind the system may be interesting, but the paper itself is really just a bunch of filler and icing on top of that algorithm.
In this paper Mahoney and Fromherz describe what they call the three main concerns and then show a system that vaguely covers the three concerns. The three concerns are dealing with human inaccuracy in sketches, being interactive, and being able to add new features later. The system described deals with "stick figure finding". It searches through the sketch checking every single line for different labels. For example, a body has 5 attached lines - a head, 2 arms, and 2 legs. Using an algorithm, the system goes through each line and checks to see if it is a body, and eventually finds the optimal solution. This allows for context lines not to be included in the figure and be seperated.
Discussion:
Two words: NO RESULTS. This algorithm sounds TERRIBLY slow, even though the algorithm is presented in another paper. It seems this paper is totally misnamed, because it has very little to do with the three "main concerns" of sketch recognition past the Introduction. The algorithm behind the system may be interesting, but the paper itself is really just a bunch of filler and icing on top of that algorithm.
016 - Constellations
Summary:
The paper dealt with a system that combines strokes in a spatial way. It takes in a group of single strokes and calculates their general placement in the drawing area. Using this spatial data, it can identify relativity with other strokes and generalize the data into sets of known shapes. An example was a drawn face. It was required to have two eyes (a right and a left), two pupils, a stroke for the head's shape, a nose and a mouth. After those were drawn, anything could be added, such as eyelashes, an eyepatch, ears, or hair and the shape would still be recognized as a face. It accomplishes this by labeling things and searching through them with different search bounds. This speeds things up.
Discussion:
Biggest problem with this paper - no results. Honestly, I don't blame them, because the results have to be pretty low. I like the concept of the system, but the loose style of recognition really doesn't seem to mesh with me. It's almost like we're taking one step back in recognition and saying "are there 5 strokes there? OK, there are 10 strokes so it must be a face". It would be interesting to find some way to integrate the design for multiple domains, such as recognizing a face OR a boat, because right now it seems this idea is really uninspiring.
The paper dealt with a system that combines strokes in a spatial way. It takes in a group of single strokes and calculates their general placement in the drawing area. Using this spatial data, it can identify relativity with other strokes and generalize the data into sets of known shapes. An example was a drawn face. It was required to have two eyes (a right and a left), two pupils, a stroke for the head's shape, a nose and a mouth. After those were drawn, anything could be added, such as eyelashes, an eyepatch, ears, or hair and the shape would still be recognized as a face. It accomplishes this by labeling things and searching through them with different search bounds. This speeds things up.
Discussion:
Biggest problem with this paper - no results. Honestly, I don't blame them, because the results have to be pretty low. I like the concept of the system, but the loose style of recognition really doesn't seem to mesh with me. It's almost like we're taking one step back in recognition and saying "are there 5 strokes there? OK, there are 10 strokes so it must be a face". It would be interesting to find some way to integrate the design for multiple domains, such as recognizing a face OR a boat, because right now it seems this idea is really uninspiring.
015 - OItmans' PhD Thesis
Summary:
Oltmans takes the approach that sketch data within features has too much noise and shouldn't be relied upon as much. This paper supports the idea that visualization techniques should be used instead of data to get more "humanly" recognition. The system described uses a "bullseye" technique that places a circle in essence every 5 pixels, with smaller circles cocentric to the larger circle in dartboard fashion. The bullseye is rotated freely, and includes stroke direction of all points within the bullseye, in "bins". The bins are made into frequency vectors, which are then compared to a pre-defined codebook The system then goes along the entire stroke with set windows and measure the ink of the line with all the known data and clusters all shapes that are close together. It then splits the clusters into more clusters to make individual shapes in a trickle-down fashion. Evaluation of the system was around 90% accurate in most areas.
Discussion:
I think this is an interesting outlook. While I don't believe throwing away all the data we have from the strokes is necessary, I do like the fact that you can get such high recognition without all the corner-finding algorithms and such that so many use. I'm a strong believer in editable thresholds, though, and I think that some things might be subject to change, such as the 5 pixel radius of the circles. Other than that, the idea is definitely something to consider for future work.
Oltmans takes the approach that sketch data within features has too much noise and shouldn't be relied upon as much. This paper supports the idea that visualization techniques should be used instead of data to get more "humanly" recognition. The system described uses a "bullseye" technique that places a circle in essence every 5 pixels, with smaller circles cocentric to the larger circle in dartboard fashion. The bullseye is rotated freely, and includes stroke direction of all points within the bullseye, in "bins". The bins are made into frequency vectors, which are then compared to a pre-defined codebook The system then goes along the entire stroke with set windows and measure the ink of the line with all the known data and clusters all shapes that are close together. It then splits the clusters into more clusters to make individual shapes in a trickle-down fashion. Evaluation of the system was around 90% accurate in most areas.
Discussion:
I think this is an interesting outlook. While I don't believe throwing away all the data we have from the strokes is necessary, I do like the fact that you can get such high recognition without all the corner-finding algorithms and such that so many use. I'm a strong believer in editable thresholds, though, and I think that some things might be subject to change, such as the 5 pixel radius of the circles. Other than that, the idea is definitely something to consider for future work.
Monday, October 29, 2007
014 - Ambiguous Intentions
Summary:
The paper describes NAPKIN, a system which allows users to draw sketchy shapes and then define them in different domains. An example would be to draw a box with four boxes around it denoting a table with four chairs. The system would then beautify and label the object. The objects are ranked by how they are recognized and by how many domains they are recognized in. The system stores all this data and saves it for later, in case a new napkin wants to use information from a previous napkin. This allows for multiple domains and ambiguous gestures, such as the above square as a table to be used in a bar graph, etc. The symbols are usually related to each other, such as the chairs to the table, because they are smaller and near. Different constraints would be made for different domains.
Discussion:
Honestly, I think this system has limited uses. While it seems and fine and dandy to have all these attachment features and ambiguous data, when people are ACTUALLY sketching something they usually don't intend anyone else to use their sketches. Since everyone has their own sketching style, labeling things would only hinder someone who is sketching something for their own personal use. Why bother labeling something as a table if the sketcher KNOWS it's a table? Also, I believe too many domains should be handled seperately, because the more domains a recognizer takes on, the less likely it is to correctly label objects in the right domain. Also, it's just as easy to write two systems for two domains as it is to write one system for two domains - if you've written the code well, that is.
The paper describes NAPKIN, a system which allows users to draw sketchy shapes and then define them in different domains. An example would be to draw a box with four boxes around it denoting a table with four chairs. The system would then beautify and label the object. The objects are ranked by how they are recognized and by how many domains they are recognized in. The system stores all this data and saves it for later, in case a new napkin wants to use information from a previous napkin. This allows for multiple domains and ambiguous gestures, such as the above square as a table to be used in a bar graph, etc. The symbols are usually related to each other, such as the chairs to the table, because they are smaller and near. Different constraints would be made for different domains.
Discussion:
Honestly, I think this system has limited uses. While it seems and fine and dandy to have all these attachment features and ambiguous data, when people are ACTUALLY sketching something they usually don't intend anyone else to use their sketches. Since everyone has their own sketching style, labeling things would only hinder someone who is sketching something for their own personal use. Why bother labeling something as a table if the sketcher KNOWS it's a table? Also, I believe too many domains should be handled seperately, because the more domains a recognizer takes on, the less likely it is to correctly label objects in the right domain. Also, it's just as easy to write two systems for two domains as it is to write one system for two domains - if you've written the code well, that is.
013 - Herot
Summary:
The paper apparently was a little-known breakthrough in the field. While Sezgin and Rubine seemed to come up with some great ideas, this paper proves that they weren't the first to think of everything. The paper revolves around some early sketch recognition and seems to cover a broad scope. It explains that sketch recognition would be best at the beginning of the design process - a.k.a. the part where everyone's still "sketching". It deals with corner recognition by introducing speed in strokes, which Sezgin uses decades later. It further discusses latching and the user-domains that other papers have covered. It says that the system functioned well with some users and poorly with others, saying the results were "interesting".
Discussion:
Obviously, the paper's age makes it a bit dated technology wise, but the ideas are all there and still valid. I, along with the rest of the class, found it interesting that this paper even existed, because two decades later all kinds of papers flare up stating the exact same thing, although to be fair most of them did have SOME new ideas as well. This paper seems to be ahead of its time, perhaps due to limitations on availability of technology at the time. This "diamond in the rough" is sadly out-dated now by more in-depth research, and to be honest is a little disheartening that such an innovative paper can go so unnoticed.
The paper apparently was a little-known breakthrough in the field. While Sezgin and Rubine seemed to come up with some great ideas, this paper proves that they weren't the first to think of everything. The paper revolves around some early sketch recognition and seems to cover a broad scope. It explains that sketch recognition would be best at the beginning of the design process - a.k.a. the part where everyone's still "sketching". It deals with corner recognition by introducing speed in strokes, which Sezgin uses decades later. It further discusses latching and the user-domains that other papers have covered. It says that the system functioned well with some users and poorly with others, saying the results were "interesting".
Discussion:
Obviously, the paper's age makes it a bit dated technology wise, but the ideas are all there and still valid. I, along with the rest of the class, found it interesting that this paper even existed, because two decades later all kinds of papers flare up stating the exact same thing, although to be fair most of them did have SOME new ideas as well. This paper seems to be ahead of its time, perhaps due to limitations on availability of technology at the time. This "diamond in the rough" is sadly out-dated now by more in-depth research, and to be honest is a little disheartening that such an innovative paper can go so unnoticed.
012 - Learning of Shape Descriptions
Summary:
The paper is mostly concerning constraints on different features. The authors state that users pay more attention to some features and less to others. It introduces a score to different constraints, and allows for different settings on constraints. The best example is the parallel lines - when parallel lines are close in proximity, people recognize them as parallel lines very quickly. If the lines are far apart, it becomes less likely to be recognized, and by other gestures in between the lines human recognition drops drastically. In essence, their system was based as close to real humans as possible, not as close to the ideal recognition a computer can make.
Discussion:
I like the paper quite a bit, though I think it's somewhat unnecessary. I think the whole point of recognizers should be to get as close to human recognition as possible. In this day and age, we've proven that computers can think faster than any human being except on simple math problems and some seemingly unsolvable computer problems. I read that the human brain has around one terrabyte of memory, which you can go out and buy in a single hard drive in today's market. In that sense, we shouldn't shoot for perfect recognition in these sketches, because sketches are human made and thus not perfect. Again, I think the paper just stated what everyone who built recognizers should be thinking - make it as human as possible.
The paper is mostly concerning constraints on different features. The authors state that users pay more attention to some features and less to others. It introduces a score to different constraints, and allows for different settings on constraints. The best example is the parallel lines - when parallel lines are close in proximity, people recognize them as parallel lines very quickly. If the lines are far apart, it becomes less likely to be recognized, and by other gestures in between the lines human recognition drops drastically. In essence, their system was based as close to real humans as possible, not as close to the ideal recognition a computer can make.
Discussion:
I like the paper quite a bit, though I think it's somewhat unnecessary. I think the whole point of recognizers should be to get as close to human recognition as possible. In this day and age, we've proven that computers can think faster than any human being except on simple math problems and some seemingly unsolvable computer problems. I read that the human brain has around one terrabyte of memory, which you can go out and buy in a single hard drive in today's market. In that sense, we shouldn't shoot for perfect recognition in these sketches, because sketches are human made and thus not perfect. Again, I think the paper just stated what everyone who built recognizers should be thinking - make it as human as possible.
Wednesday, October 3, 2007
011 - LADDER
Summary:
This paper is all about the LADDER system. It begins with a basic description of the system. LADDER is a tool that allows designers to create sketch recognition "languages" that work with sketch recognizers to form more high-level programs. The paper describes some of the abilities of LADDER and some limitations, including curve-heavy domains. It explains the hierarchy and shape definition of the system, which allows various shapes to be constrained and grouped into complex shapes for various uses. LADDER has an extensive list of constraints, but still has many different directions and area to explore.
Discussion:
I personally love the LADDER tool. I believe it may be the first "sketch recognition design tool", such as Visual Studio is to programming and Adobe Photoshop is to digital graphics (just examples, of course). This is a tool that will provide huge steps in the field. Now, I won't sing its praises too much, because while the program has a lot of potential, it still isn't NEARLY as user-friendly as it could be. The drawing area is pretty intuitive and the shape/contraint window SEEMS straight-forward, but it can get very muddy very quickly, especially with more complex systems. I'm a big fan of the tool, but I'm the first to admit that there's still a lot of work to be done before Hammond et. al can put the program on shelves and available to download to the general public.
This paper is all about the LADDER system. It begins with a basic description of the system. LADDER is a tool that allows designers to create sketch recognition "languages" that work with sketch recognizers to form more high-level programs. The paper describes some of the abilities of LADDER and some limitations, including curve-heavy domains. It explains the hierarchy and shape definition of the system, which allows various shapes to be constrained and grouped into complex shapes for various uses. LADDER has an extensive list of constraints, but still has many different directions and area to explore.
Discussion:
I personally love the LADDER tool. I believe it may be the first "sketch recognition design tool", such as Visual Studio is to programming and Adobe Photoshop is to digital graphics (just examples, of course). This is a tool that will provide huge steps in the field. Now, I won't sing its praises too much, because while the program has a lot of potential, it still isn't NEARLY as user-friendly as it could be. The drawing area is pretty intuitive and the shape/contraint window SEEMS straight-forward, but it can get very muddy very quickly, especially with more complex systems. I'm a big fan of the tool, but I'm the first to admit that there's still a lot of work to be done before Hammond et. al can put the program on shelves and available to download to the general public.
Monday, October 1, 2007
010 - Beautifying Low-level Sketch Shapes
Summary:
Paulson and Hammond begin their paper by explaining the different low-level sketch shapes used in their system. These shapes are basic enough to be useful but broad enough to not allow too much clutter and overlap. They explain a bit of the work that led to their system, and then jump into details. The writers start by explaining their new features of NDDE (normalized distance between direction extremes) and DCR (direction change ratio) and how they're used to find each shape. They help immensely in the finding of spirals and arcs vs. curves. The next section explains their innovative "ranking" system, which allows for multiple fits to be found for each sketch. Then each fit is given a number based on the rankings and the number of each primitive in the fit. For example, if a fit has 5 lines and a fit of the same sketch has 1 line and 1 arc (3 points), then the 1 line and 1 arc will be a better fit than the 5 lines.
Discussion:
I love the idea of the ranking system. I think some might find it hard to accept, however, unless they are given the option of changing it for their own needs. Some may think that an arc should be worth more than 3 points, and a circle more than 5, etc. If everyone is given the option of changing these "thresholds" on ranking, however, I think this would be a great asset to low level sketch recognition and finding the best fit.
Paulson and Hammond begin their paper by explaining the different low-level sketch shapes used in their system. These shapes are basic enough to be useful but broad enough to not allow too much clutter and overlap. They explain a bit of the work that led to their system, and then jump into details. The writers start by explaining their new features of NDDE (normalized distance between direction extremes) and DCR (direction change ratio) and how they're used to find each shape. They help immensely in the finding of spirals and arcs vs. curves. The next section explains their innovative "ranking" system, which allows for multiple fits to be found for each sketch. Then each fit is given a number based on the rankings and the number of each primitive in the fit. For example, if a fit has 5 lines and a fit of the same sketch has 1 line and 1 arc (3 points), then the 1 line and 1 arc will be a better fit than the 5 lines.
Discussion:
I love the idea of the ranking system. I think some might find it hard to accept, however, unless they are given the option of changing it for their own needs. Some may think that an arc should be worth more than 3 points, and a circle more than 5, etc. If everyone is given the option of changing these "thresholds" on ranking, however, I think this would be a great asset to low level sketch recognition and finding the best fit.
009 - Streaming Algorithms for Line Simplification
Summary:
The paper began by explaining the context of the system. It gives examples of different distance functions, Hausdorff and Frechet, and how they're used. It explains how the technique used is for an infinite amount of string points and simplifying those points to a limited amount of space. Finding the least error point, it removes that point and connects the point before and the point after instead, thus increasing error the smallest amount possible of the new line. It discusses the creation of an error oracle and how it is used in the system.
Discussion:
Quite simply, this is the worst research paper I've ever read. It's not only INCREDIBLY cryptic, but it's also covering what I believe to be a useless topic. The paper gives an example of migrating birds. Points keep streaming in of where the birds are, and the system has to maintain a certain amount of accuracy with a limited amount of space, so it removes the least error point every time a new point comes in. However, it states in the paper that the writer's assume an INFINITE amount of points, which therefore makes the problem unsolvable. Assuming the birds continued migrating North and South, at infinite the graph would look like a bunch of jagged straight lines from the start to finish. Trying to solve this problem is NONSENSE. There should never be an infinite amount of points in a single set of data. For the given example, breaking up the migration into a yearly interval of sets would be completely plausible, or any such case for that matter. All you need to do is break the data into a managable amount, then this system might come in handy by throwing out the small changes and keeping the most data possible.
The paper began by explaining the context of the system. It gives examples of different distance functions, Hausdorff and Frechet, and how they're used. It explains how the technique used is for an infinite amount of string points and simplifying those points to a limited amount of space. Finding the least error point, it removes that point and connects the point before and the point after instead, thus increasing error the smallest amount possible of the new line. It discusses the creation of an error oracle and how it is used in the system.
Discussion:
Quite simply, this is the worst research paper I've ever read. It's not only INCREDIBLY cryptic, but it's also covering what I believe to be a useless topic. The paper gives an example of migrating birds. Points keep streaming in of where the birds are, and the system has to maintain a certain amount of accuracy with a limited amount of space, so it removes the least error point every time a new point comes in. However, it states in the paper that the writer's assume an INFINITE amount of points, which therefore makes the problem unsolvable. Assuming the birds continued migrating North and South, at infinite the graph would look like a bunch of jagged straight lines from the start to finish. Trying to solve this problem is NONSENSE. There should never be an infinite amount of points in a single set of data. For the given example, breaking up the migration into a yearly interval of sets would be completely plausible, or any such case for that matter. All you need to do is break the data into a managable amount, then this system might come in handy by throwing out the small changes and keeping the most data possible.
Tuesday, September 25, 2007
008 - Kim and Kim Curvature Estimation
Summary:
This paper is all about curves and making them as smooth as possible. It begins with some definitions about their equations and some basic mathematic procedure. The next section deals with the basic curvature estimations based mostly on direction change. It goes in depth on how local convexity can be used to add "weight" to a curve and make it much less error-prone. It further goes on to add local monotonicity to the mix. Local monotonicity allows for the convexity to check local points but does not add that convexity unless it's lower than the current minimum value. Ample examples are given to explain this. The paper then shows results of a user study adding each of the elements one at a time, showing how the system gets more accurate and smooth each time a new feature is added, leading to better results.
Discussion:
This paper was slightly confusing the first time through, but it did make sense eventually. The concept of monotonicity really is not a simple one but it is extremely useful. Usually I don't like non-simple solutions but after you understand it it becomes incredibly clear. I think this is probably one of the best curvature estimations that I have seen so far, and really isn't hard to implement, making it my favorite.
This paper is all about curves and making them as smooth as possible. It begins with some definitions about their equations and some basic mathematic procedure. The next section deals with the basic curvature estimations based mostly on direction change. It goes in depth on how local convexity can be used to add "weight" to a curve and make it much less error-prone. It further goes on to add local monotonicity to the mix. Local monotonicity allows for the convexity to check local points but does not add that convexity unless it's lower than the current minimum value. Ample examples are given to explain this. The paper then shows results of a user study adding each of the elements one at a time, showing how the system gets more accurate and smooth each time a new feature is added, leading to better results.
Discussion:
This paper was slightly confusing the first time through, but it did make sense eventually. The concept of monotonicity really is not a simple one but it is extremely useful. Usually I don't like non-simple solutions but after you understand it it becomes incredibly clear. I think this is probably one of the best curvature estimations that I have seen so far, and really isn't hard to implement, making it my favorite.
007 - Domain-Independent System by Yu
Summary:
This paper deals with Yu et. al basically adding on to Sezgin's model. They begin with a list of attributes that they believe are essential in any sketch recognition software and explains why their system qualifies as such. The next section explains their concept of "feature area", which is somewhat similar to error except it deals with various primitives. They then move on to explain how their system does vertex detection, line and curve approximation, and self-intersections. The vertexes are using basic primitives instead of speed data to approximate points. The line and curve approximations are fairly elementary, with basic examples given by the direction graph of various shapes and how they correspond. The self-intersection is handled by checking to see if it is possible and cutting it if is not. The paper then explains some of the cleanup and how the primitives work with the sketches to test for errors. It then concludes with a user study that ended with decent success on most simple shapes and met with user satisfaction.
Discussion:
To be honest, I loved this paper. It really brings everything down to earth and has simple solutions. Granted, this system has a LOT of errors when you start dealing with more distinct shapes, but for simple tools like AutoCad (which is mentioned at the end of the paper) this system would cut user time in half, which is nothing to scoff at. I think this system is a step in the right direction, even though it seems to just further the work of Sezgin. I believe approximation is a much more beneficial direction than that of perfect recognition.
This paper deals with Yu et. al basically adding on to Sezgin's model. They begin with a list of attributes that they believe are essential in any sketch recognition software and explains why their system qualifies as such. The next section explains their concept of "feature area", which is somewhat similar to error except it deals with various primitives. They then move on to explain how their system does vertex detection, line and curve approximation, and self-intersections. The vertexes are using basic primitives instead of speed data to approximate points. The line and curve approximations are fairly elementary, with basic examples given by the direction graph of various shapes and how they correspond. The self-intersection is handled by checking to see if it is possible and cutting it if is not. The paper then explains some of the cleanup and how the primitives work with the sketches to test for errors. It then concludes with a user study that ended with decent success on most simple shapes and met with user satisfaction.
Discussion:
To be honest, I loved this paper. It really brings everything down to earth and has simple solutions. Granted, this system has a LOT of errors when you start dealing with more distinct shapes, but for simple tools like AutoCad (which is mentioned at the end of the paper) this system would cut user time in half, which is nothing to scoff at. I think this system is a step in the right direction, even though it seems to just further the work of Sezgin. I believe approximation is a much more beneficial direction than that of perfect recognition.
Saturday, September 15, 2007
006 - Early Processing for Sketch Understanding
Summary:
This paper describes the "Sezgin System" and how it works. It is a system that allows the user to draw a shape any way they want then continuously makes vertexes at specific spots until it gets "close enough" to the desired shape. It also deals with finding and drawing curves accurately. The vertex finding is a complicated description but a simple concept. The paper describes how the system uses the direction data (from the features) to see spikes in changes. This alone, however, doesn't produce correct corners, so Sezgin also includes the speed data from point to point. It finds the average of these two data elements and then collects data on all points above (in the case of direction) and below (in the case of speed) these averages and intersects these values. The resulting intersection becomes the corners. However, if the drawn shape is not "close enough" to the computer-generated shape, the system will try adding both a direction point and a speed point to the data and try again (the points are added separately, giving two different intersections). Whichever is closest is then chosen, and the process repeats until the drawn shape is under the threshold of error. Sezgin then goes on to describe the use of Bezier curves to draw correct curves without only using "circular" curves. It describes how "beautification" works by making slopes of lines slightly more pleasing to the eye (less "jagged-ness" or aliasing). The paper goes on to describe a user study on the system with a set of drawings. The study resulted in mostly positive feedback for the system.
Discussion:
I really like this method. It's pretty "common sense"-like because it is an approximation, which is what people do in real life. You see a slightly oblong circle and you'll just remember it as a circle, unless it has something special about it. I think this method's BIGGEST drawback is also it's biggest asset, and that's the "threshold" issue. People can design different programs for different uses and sets of people with different thresholds, such as allowing for more jerkiness with arthritis patients drawing something and less for skilled draftsmen. But not specifying a default value for this threshold (since Sezgin didn't in his paper) could lead to a lot of problems.
An interesting thought that I had was that he assumes that all corners have a slower speed. Studies have been done to show this is generally true, but these studies were likely all done on a flat horizon surface. What isn't taken into account is people who use boards on the wall or the new "SmartBoards" (they're new enough to me, all right!?). When writing on a vertical surface gravity can change drawing style. For example, drawing the top half of a circle on a piece of paper you will commonly start slow, speed up through the entire arc, and end slightly slower than at the arc. On a board, gravity might slow your hand down near the top of the arc, or rather SPEED it up on the decent from the top, thus resulting in a great change of speed that might be recognized as a corner.
This paper describes the "Sezgin System" and how it works. It is a system that allows the user to draw a shape any way they want then continuously makes vertexes at specific spots until it gets "close enough" to the desired shape. It also deals with finding and drawing curves accurately. The vertex finding is a complicated description but a simple concept. The paper describes how the system uses the direction data (from the features) to see spikes in changes. This alone, however, doesn't produce correct corners, so Sezgin also includes the speed data from point to point. It finds the average of these two data elements and then collects data on all points above (in the case of direction) and below (in the case of speed) these averages and intersects these values. The resulting intersection becomes the corners. However, if the drawn shape is not "close enough" to the computer-generated shape, the system will try adding both a direction point and a speed point to the data and try again (the points are added separately, giving two different intersections). Whichever is closest is then chosen, and the process repeats until the drawn shape is under the threshold of error. Sezgin then goes on to describe the use of Bezier curves to draw correct curves without only using "circular" curves. It describes how "beautification" works by making slopes of lines slightly more pleasing to the eye (less "jagged-ness" or aliasing). The paper goes on to describe a user study on the system with a set of drawings. The study resulted in mostly positive feedback for the system.
Discussion:
I really like this method. It's pretty "common sense"-like because it is an approximation, which is what people do in real life. You see a slightly oblong circle and you'll just remember it as a circle, unless it has something special about it. I think this method's BIGGEST drawback is also it's biggest asset, and that's the "threshold" issue. People can design different programs for different uses and sets of people with different thresholds, such as allowing for more jerkiness with arthritis patients drawing something and less for skilled draftsmen. But not specifying a default value for this threshold (since Sezgin didn't in his paper) could lead to a lot of problems.
An interesting thought that I had was that he assumes that all corners have a slower speed. Studies have been done to show this is generally true, but these studies were likely all done on a flat horizon surface. What isn't taken into account is people who use boards on the wall or the new "SmartBoards" (they're new enough to me, all right!?). When writing on a vertical surface gravity can change drawing style. For example, drawing the top half of a circle on a piece of paper you will commonly start slow, speed up through the entire arc, and end slightly slower than at the arc. On a board, gravity might slow your hand down near the top of the arc, or rather SPEED it up on the decent from the top, thus resulting in a great change of speed that might be recognized as a corner.
Wednesday, September 12, 2007
005 - MARQS Presentation
Summary:
Paulson's presentation of MARQS included an overview of the program and the possible advantages and disadvantages of its use. MARQS, unlike all previous gesture recognizers, uses only 5 features and a single training example. This is accomplished through seperate single and multiple classifiers that read a specific variation from the gesture made and the gesture base and choose the best match. As more data is accrued for these symbols it will gradually get more accurate, but only 1 starting example is necessary. MARQS also is stroke-number independent, as well as domain independent, allowing users to draw something in many different ways and still have it recognized correctly by the system. Orientation and localization are also independent, allowing for even further variation by the user.
Discussion:
As Brian discussed, while decently effective for such a small amount of training data, some program features are traded for user tolerance. While the system may recognize a stick man with his arms up and a stick man with his arms down both as a stick man, it also recognizes a happy face and a sad face as both faces. As discussed, this could be overcome with multiple layers of classification, though. I think this is a GREAT idea. I love the tolerance in this program, and adding the ability to draw gestures and then classify them is a great designer tool. Sadly, I think the notebook idea is somewhat overkill, because most "notebooks" are not consistent files. The example of drawing some waves of water to go to the "water" notes is nice, but rarely will there be notes all about water in one place. Usually notes are broken up into dates, which are easier to recognize and find by keystrokes, and if they ARE separate the user has already sorted the notes. The only practical use of the system that I could see is if someone were to take an exhorbitant amount of notes and they were classifed into different subjects.
Paulson's presentation of MARQS included an overview of the program and the possible advantages and disadvantages of its use. MARQS, unlike all previous gesture recognizers, uses only 5 features and a single training example. This is accomplished through seperate single and multiple classifiers that read a specific variation from the gesture made and the gesture base and choose the best match. As more data is accrued for these symbols it will gradually get more accurate, but only 1 starting example is necessary. MARQS also is stroke-number independent, as well as domain independent, allowing users to draw something in many different ways and still have it recognized correctly by the system. Orientation and localization are also independent, allowing for even further variation by the user.
Discussion:
As Brian discussed, while decently effective for such a small amount of training data, some program features are traded for user tolerance. While the system may recognize a stick man with his arms up and a stick man with his arms down both as a stick man, it also recognizes a happy face and a sad face as both faces. As discussed, this could be overcome with multiple layers of classification, though. I think this is a GREAT idea. I love the tolerance in this program, and adding the ability to draw gestures and then classify them is a great designer tool. Sadly, I think the notebook idea is somewhat overkill, because most "notebooks" are not consistent files. The example of drawing some waves of water to go to the "water" notes is nice, but rarely will there be notes all about water in one place. Usually notes are broken up into dates, which are easier to recognize and find by keystrokes, and if they ARE separate the user has already sorted the notes. The only practical use of the system that I could see is if someone were to take an exhorbitant amount of notes and they were classifed into different subjects.
Tuesday, September 11, 2007
004 - Visual Simliarity of Pen Gestures
Summary:
This paper seems to be the premise behind creating Quill as in the aforementioned Long paper. It explains why all the research was done, mainly sticking to the similarities of some gestures that humans may not be able to distinguish. It acts as an overview of all the research done that led to the Quill program. It starts with the examining of different interfaces to design with, different formulas and psychology examples of similarity, and the number of dimensions of a Multi-Dimensional-Scaling technique to use. It then lists the different experiment trials run and what each outcome was. The first trial tested the different features to see which ones were best predictors of similarity of gestures, which turned out to be most of the 11 listed features of Rubine (minus bounding box and total length) and several features that Long et al designed (I think, I could be wrong), and what dimensions they were in. The next trial was over a specified set of gestures to see how people would perceive them (absolute angle and aspect, length and area, and rotation-related features). Trial 1 ended in a seemingly unexplained split in the group, but adding the gesture "sets" in Trial 2 brought the group together more.
Discussion:
I gotta say that Long's results didn't SOUND promising. Even with decent results, I dislike the idea of splitting the users into groups in trial 1, and trial 2 said that even without the outliers the overall usage didn't improve. I applaud Long at trying to REMOVE features, because if you had a program with a million features it would be able to tell exactly how different every gesture was, but no one would want to use it. I do question why they took out the features in Rubine that dealt with time and pretty much removed it from the equation. I can only guess that they wanted to remove the "I draw faster than him" part of similarity, since a circle drawn in a second can look the same as one drawn in a minute, though I think it could still be useful in some cases.
This paper seems to be the premise behind creating Quill as in the aforementioned Long paper. It explains why all the research was done, mainly sticking to the similarities of some gestures that humans may not be able to distinguish. It acts as an overview of all the research done that led to the Quill program. It starts with the examining of different interfaces to design with, different formulas and psychology examples of similarity, and the number of dimensions of a Multi-Dimensional-Scaling technique to use. It then lists the different experiment trials run and what each outcome was. The first trial tested the different features to see which ones were best predictors of similarity of gestures, which turned out to be most of the 11 listed features of Rubine (minus bounding box and total length) and several features that Long et al designed (I think, I could be wrong), and what dimensions they were in. The next trial was over a specified set of gestures to see how people would perceive them (absolute angle and aspect, length and area, and rotation-related features). Trial 1 ended in a seemingly unexplained split in the group, but adding the gesture "sets" in Trial 2 brought the group together more.
Discussion:
I gotta say that Long's results didn't SOUND promising. Even with decent results, I dislike the idea of splitting the users into groups in trial 1, and trial 2 said that even without the outliers the overall usage didn't improve. I applaud Long at trying to REMOVE features, because if you had a program with a million features it would be able to tell exactly how different every gesture was, but no one would want to use it. I do question why they took out the features in Rubine that dealt with time and pretty much removed it from the equation. I can only guess that they wanted to remove the "I draw faster than him" part of similarity, since a circle drawn in a second can look the same as one drawn in a minute, though I think it could still be useful in some cases.
Sunday, September 9, 2007
003 - “Those Look Similar!”
“Those Look Similar!” Issues in Automating Gesture Design Advice
Summary:
Long et al. give a brief overview about gestural recognition in this paper before diving into their new design tool, "Quill". Quill interestingly advises the designer of similar gestures and warns that users may perceive them as the same thing. The paper explains how Quill goes through all the gestures and gives warnings to the designer based on similarity data that the tool creates. It discusses the problems that arose from this "advice" feature, and explains how often and for what reasons they finalized the feature's attributes. It explains several different options for giving advice and which ones were put in the final product.
Discussion:
I think this is a great optional tool for gestural language designers. This seems like a good feature; as programming languages have tools that highlight errors and broken code, this highlights possible mistakes in gestural languages. I can't help but think that we should stress the optional part though, being reminded of Clippy from Microsoft Word. Even though Long and the others went out of their way to be as least annoying to the designer as possible, Quill still has a lot of error in the advice giving.
Personally, I believe that gestural languages should be used for different means. For example, typing will almost always be faster than a pencil/writing tablet for taking lots of words, but throw in a fraction or big equation and sketching is totally the way to go. Basically I'm saying that gestural languages shouldn't be as broad as some applications, because there's only so many shapes you can make before you either get repetitive or just plain confusing.
Summary:
Long et al. give a brief overview about gestural recognition in this paper before diving into their new design tool, "Quill". Quill interestingly advises the designer of similar gestures and warns that users may perceive them as the same thing. The paper explains how Quill goes through all the gestures and gives warnings to the designer based on similarity data that the tool creates. It discusses the problems that arose from this "advice" feature, and explains how often and for what reasons they finalized the feature's attributes. It explains several different options for giving advice and which ones were put in the final product.
Discussion:
I think this is a great optional tool for gestural language designers. This seems like a good feature; as programming languages have tools that highlight errors and broken code, this highlights possible mistakes in gestural languages. I can't help but think that we should stress the optional part though, being reminded of Clippy from Microsoft Word. Even though Long and the others went out of their way to be as least annoying to the designer as possible, Quill still has a lot of error in the advice giving.
Personally, I believe that gestural languages should be used for different means. For example, typing will almost always be faster than a pencil/writing tablet for taking lots of words, but throw in a fraction or big equation and sketching is totally the way to go. Basically I'm saying that gestural languages shouldn't be as broad as some applications, because there's only so many shapes you can make before you either get repetitive or just plain confusing.
002 - Rubine's "Specifying Gestures by Example"
Summary:
This paper covers the GRANDMA system, or Gesture Recognizers Automated
in a Novel Direct Manipulation Architecture, which seems to be a very simple gesture-recognizing tool to add any number of gestures to a program, as used with the GDP drawing program. It starts with an example of the system doing some of it's main gestures in a series, including copying, moving, drawing a line, and deletion. Explaining the hierarchy of the GDP, it shows how the gestures are put in and handled. Using a number of examples, it states that almost any gesture can be expressed in this way regardless of size and style. It contrasts this with the multi-stroke techniques that were used in the day, explaining how this improves both techniques and adds flexibility. It then delves into the features used for the underlying algorithm, and how each is calculated and used. It explains the training process and why it works, as well as the rejection and evaluation processes. It further explains some extensions that could be used to improve the overall recognition. This paper is FULL of equations that will be very useful for any recognition system.
Discussion:
I just can't help think that there's some easier way to do this. Obviously much research was done in this area and this is a VERY nice list of features that has been proven to work, but I somehow feel like this is overkill. Maybe there aren't easier ways with less features out there, but I'd like to think there are.
I think this paper is a really great source of information. The list of equations is extensive and pretty laid out bare. I liked the idea of Eager Recognition more than waiting for the system to recognize it, though Rubine doesn't cover it very in-depth.
I commend Rubine for all this research, but I also personally think there's a threshold that we really should stop caring about. Everyone's style is different, so I'm not sure there will ever be a 100% recognition mark for the world's population. Heck, I don't think there'll ever be a 100% recognition mark for our class's population. It's nice to know all this data, but I think, as Rubine said, as long as programs have decent undo functions we shouldn't overwork ourselves to get that 1 extra percent.
This paper covers the GRANDMA system, or Gesture Recognizers Automated
in a Novel Direct Manipulation Architecture, which seems to be a very simple gesture-recognizing tool to add any number of gestures to a program, as used with the GDP drawing program. It starts with an example of the system doing some of it's main gestures in a series, including copying, moving, drawing a line, and deletion. Explaining the hierarchy of the GDP, it shows how the gestures are put in and handled. Using a number of examples, it states that almost any gesture can be expressed in this way regardless of size and style. It contrasts this with the multi-stroke techniques that were used in the day, explaining how this improves both techniques and adds flexibility. It then delves into the features used for the underlying algorithm, and how each is calculated and used. It explains the training process and why it works, as well as the rejection and evaluation processes. It further explains some extensions that could be used to improve the overall recognition. This paper is FULL of equations that will be very useful for any recognition system.
Discussion:
I just can't help think that there's some easier way to do this. Obviously much research was done in this area and this is a VERY nice list of features that has been proven to work, but I somehow feel like this is overkill. Maybe there aren't easier ways with less features out there, but I'd like to think there are.
I think this paper is a really great source of information. The list of equations is extensive and pretty laid out bare. I liked the idea of Eager Recognition more than waiting for the system to recognize it, though Rubine doesn't cover it very in-depth.
I commend Rubine for all this research, but I also personally think there's a threshold that we really should stop caring about. Everyone's style is different, so I'm not sure there will ever be a 100% recognition mark for the world's population. Heck, I don't think there'll ever be a 100% recognition mark for our class's population. It's nice to know all this data, but I think, as Rubine said, as long as programs have decent undo functions we shouldn't overwork ourselves to get that 1 extra percent.
001.1 - Personal Info
Ya, I must have missed this part on the homework, so I'm doing it AFTER the first blog entry.
My name is Michael Eskridge, and I'm an Undergraduate Computer Science major graduating in December (hopefully!). I'm mostly interested in "futuristic" research in CS, which I take to be anything that will be useful in a decade or so. I think sketch recognition is right up there on possiblities, though currently I think the field is limited to the constraints that we have in the here and now. I believe that technology should be peripheral-free in the future, with no pens/tablets/wires of any kind, but obviously this is still quite a ways away. But I'm hopeful!
Since I'm only an undergraduate, I don't have a HUGE experience in all types of programming, but I'm usually a fast learner. I have experience with most of the big languages like C++, Java, and C#, but I haven't done much with them in a few years. Most of my recent programming skills are centered in website design like CSS, XHTML, and PHP, which is what I've used for classes for a few years now. Sadly I have NO experience in Sketch Recognition and very little into AI, just a few algorithms I'd have to look up in a book to fully remember.
I got interested in this class from a question posed by my mother-in-law, who teaches 7th grade math. She wanted to know if there was a quick way to put fractions and different mathematical symbols in faster than looking them up in some "insert" tab. I contacted Dr. Hammond about it and somehow wound up in this class. Although I'm not all that interested in the history of the field, I'm convinced that this field along with Computer/Human Interaction will really have a huge impact in the next decade or so, so I'd like to familiarize myself with the coming future by learning what we have available today.
I'm very interested in Computer Graphics and anything to do with them, such as website development, logo design, interface engineering and the like. I'm starting my family soon, as my wife is expecting on Christmas of this year, so in 5 years I hope to have a beautiful daughter and be making lots of money. I don't have any set goals as far as what I do in the CS field, but I'd like to do something that leans towards interface design and development. In ten years I hope to be president of the US and be the first person on Mars. And if you actually read this far, then I commend you and hope you found the joke funny.
I'm an aspiring cartoonist on the side and I play way too many video games. Along with this class I'm taking a 3D modeling course, a storyboarding/comic course, and an introductory course in drawing on the computer (that I probably should be teaching, but I'm not complaining). I graduate in December, like I said, and I hope NEVER TO BE IN SCHOOL AGAIN. As much as some of these classes are fun, school is just not for me. I'd rather be in the workforce and learning than in a classroom any day.
Hopefully this covers what is ME. You'll notice that I spell my name "Miqe" on pretty much everything. This is because in high school someone suggested I be different and spell my name "Mique" and I agreed. Shortly thereafter I typed it in wrong on a message board or game or something and I realized that "Miqe" was much less feminine than "Mique" so I switched it. And I've been Miqe ever since.
So that wraps it up. Hope you enjoyed the read, though you really should have been reading your papers instead....
Miqe
My name is Michael Eskridge, and I'm an Undergraduate Computer Science major graduating in December (hopefully!). I'm mostly interested in "futuristic" research in CS, which I take to be anything that will be useful in a decade or so. I think sketch recognition is right up there on possiblities, though currently I think the field is limited to the constraints that we have in the here and now. I believe that technology should be peripheral-free in the future, with no pens/tablets/wires of any kind, but obviously this is still quite a ways away. But I'm hopeful!
Since I'm only an undergraduate, I don't have a HUGE experience in all types of programming, but I'm usually a fast learner. I have experience with most of the big languages like C++, Java, and C#, but I haven't done much with them in a few years. Most of my recent programming skills are centered in website design like CSS, XHTML, and PHP, which is what I've used for classes for a few years now. Sadly I have NO experience in Sketch Recognition and very little into AI, just a few algorithms I'd have to look up in a book to fully remember.
I got interested in this class from a question posed by my mother-in-law, who teaches 7th grade math. She wanted to know if there was a quick way to put fractions and different mathematical symbols in faster than looking them up in some "insert" tab. I contacted Dr. Hammond about it and somehow wound up in this class. Although I'm not all that interested in the history of the field, I'm convinced that this field along with Computer/Human Interaction will really have a huge impact in the next decade or so, so I'd like to familiarize myself with the coming future by learning what we have available today.
I'm very interested in Computer Graphics and anything to do with them, such as website development, logo design, interface engineering and the like. I'm starting my family soon, as my wife is expecting on Christmas of this year, so in 5 years I hope to have a beautiful daughter and be making lots of money. I don't have any set goals as far as what I do in the CS field, but I'd like to do something that leans towards interface design and development. In ten years I hope to be president of the US and be the first person on Mars. And if you actually read this far, then I commend you and hope you found the joke funny.
I'm an aspiring cartoonist on the side and I play way too many video games. Along with this class I'm taking a 3D modeling course, a storyboarding/comic course, and an introductory course in drawing on the computer (that I probably should be teaching, but I'm not complaining). I graduate in December, like I said, and I hope NEVER TO BE IN SCHOOL AGAIN. As much as some of these classes are fun, school is just not for me. I'd rather be in the workforce and learning than in a classroom any day.
Hopefully this covers what is ME. You'll notice that I spell my name "Miqe" on pretty much everything. This is because in high school someone suggested I be different and spell my name "Mique" and I agreed. Shortly thereafter I typed it in wrong on a message board or game or something and I realized that "Miqe" was much less feminine than "Mique" so I switched it. And I've been Miqe ever since.
So that wraps it up. Hope you enjoyed the read, though you really should have been reading your papers instead....
Miqe
Thursday, August 30, 2007
001 - Hammond and Sketchpad
"Introduction to Sketch Recognition"
Summary: This article begins with an introduction to modern Tablet PCs. A brief history of Tablets is given, then it delves into the argument of Active vs. Passive digitizers, complete with pros and cons of each. Different types of Tablets are then covered, along with different styles of input for those tablets. It goes on to explain different peripherals that use Sketch Recognition and different existing softwares that are currently in use. The article covers different uses of the technology, such as the different educational prospects, showing examples ranging from grade school (algebraic formulas) to real world on-the-job applications (Class Diagrams in Software Engineering).
I think the different applications of this technology is definitely the most appealing part of this article. Some of the examples are intriguing, such as the chemistry models, and some are literally WAITING to be explored (the animated schematics). I believe that there is a huge selection of different directions for this field to go in, and I think that all of those directions should be explored. I only wish there was more manpower to devote to this, because the potential of this technology is virtually limitless.
"Sketchpad"
Summary:
"Sketchpad" begins with a detailed example of creating a repeating pattern of hexagons, using various functions to lock the hexagon into place, equalize the lines, and copy the hexagon over and over. It goes on to explain how this example revolutionizes the field, and explains how these functions could be used to improve upon the hand schematics used at the time. It explained the function of the light pen and some of the concepts it uses, as well as how Sketchpad displays on the screen. It gives some equations on line drawing that are used even today in basic Computer Graphics, and goes into detail about the copy function. It further explains some of the more advanced functions and uses of Sketchpad, such as architectural design and circuit design.
I think this article, though aged, seems very advanced. Some of the functions in Sketchpad are even more powerful than some programs today. For example, as far as I know, AutoCad does not have a function for equalizing lines; users instead have to extend a guideline and delete the excess. While some functions seem archaic, such as the line drawing (even MSPaint has an "S-line" which allows for non-perfect curves), the copy function is still being refined and used to this day. Adobe Photoshop CS3 still uses grouping with copying, practically the same as the instances used in Sketchpad. It really is amazing that this program was made 45 years ago and some aspects are practically unchanged and unevolved in all that time.
Summary: This article begins with an introduction to modern Tablet PCs. A brief history of Tablets is given, then it delves into the argument of Active vs. Passive digitizers, complete with pros and cons of each. Different types of Tablets are then covered, along with different styles of input for those tablets. It goes on to explain different peripherals that use Sketch Recognition and different existing softwares that are currently in use. The article covers different uses of the technology, such as the different educational prospects, showing examples ranging from grade school (algebraic formulas) to real world on-the-job applications (Class Diagrams in Software Engineering).
I think the different applications of this technology is definitely the most appealing part of this article. Some of the examples are intriguing, such as the chemistry models, and some are literally WAITING to be explored (the animated schematics). I believe that there is a huge selection of different directions for this field to go in, and I think that all of those directions should be explored. I only wish there was more manpower to devote to this, because the potential of this technology is virtually limitless.
"Sketchpad"
Summary:
"Sketchpad" begins with a detailed example of creating a repeating pattern of hexagons, using various functions to lock the hexagon into place, equalize the lines, and copy the hexagon over and over. It goes on to explain how this example revolutionizes the field, and explains how these functions could be used to improve upon the hand schematics used at the time. It explained the function of the light pen and some of the concepts it uses, as well as how Sketchpad displays on the screen. It gives some equations on line drawing that are used even today in basic Computer Graphics, and goes into detail about the copy function. It further explains some of the more advanced functions and uses of Sketchpad, such as architectural design and circuit design.
I think this article, though aged, seems very advanced. Some of the functions in Sketchpad are even more powerful than some programs today. For example, as far as I know, AutoCad does not have a function for equalizing lines; users instead have to extend a guideline and delete the excess. While some functions seem archaic, such as the line drawing (even MSPaint has an "S-line" which allows for non-perfect curves), the copy function is still being refined and used to this day. Adobe Photoshop CS3 still uses grouping with copying, practically the same as the instances used in Sketchpad. It really is amazing that this program was made 45 years ago and some aspects are practically unchanged and unevolved in all that time.
Subscribe to:
Posts (Atom)