Comments:
Jorge
Summary:
This paper, written in 1976, outlines the things that a sketch-based system must be able to do in order to be of use to humans. It outlines three experiments in computer processing of sketches.
HUNCH: Can a computer interpret a sketch without knowing the domain? Such was the question behind experiment one, known as HUNCH. Testing was done using an actual pen and big piece of paper set over the surface of a drawing tablet (this was done to mimic a natural sketching environment). HUNCH essentially found corners by marking a slower drawing speed as a corner. It originally "latched" together endpoints, meaning that if two endpoints were within a certain radius of each other, they were said to meet. The system was then augmented to use speed to determine 'intended' endpoints. Experiments were also conducted to determine and interpret over-traced lines, project into the third dimension, and find paths between rooms in a hand-drawn floor plan. The conclusion was that context is important- even at the lowest levels of interpretation.
Experiment 2: Specifying the context of drawings was tested next. They found that "... the system is only as good as matching machinery". In other words, context can help, but it doesn't guarantee that the user will draw everything that the computer needs to identify the proper context.
Experiment 3: An interactive system that combines the strengths of HUNCH and Experiment 2 was tested next. For a user to interactive with the system, basic recognition must be done in real time. Measuring the speed of a stroke ad how bent it is can help with this.
The conclusion of the paper mentions how the goal is to allow users to modify interpretations as needed. A sketch-based system should be smart, adaptable, and easy to interact with.
Discussion:
Part of my truss recognition algorithm uses latching, and has similar issues. Adjusting the radius used to the length of the strokes in question could definitely help me out!
Really my one issues with this paper is that it seemed to end abruptly. I liked where it was going and the concise discussions of experiments and findings, but then all the sudden it was over. The conclusion could have been a page or more in length! I am thinking that it was cut short to meet some sort of page cap. Regardless, I liked this paper because it made me think of new ways to solve problems and create interfaces.
Yeah this paper was very strangely organized and did end abruptly. They didn't exactly say why they were trying to latch everything, but a good latching mechanism would be indeed nice.
ReplyDeleteI like your latching comment. I intend to add that to my algorithm; I've already got latching in my now-discarded triangle recognition program. As for the paper, I agree that it ended abruptly. I was expecting results and evaluation and I did not find any. Still, it does some explaining of the basics, and there is no faulting that.
ReplyDeleteI also used latching in the truss recognition, and had the same experience. It would be better to use the two lines's length to determine the latching radius.
ReplyDeleteActually, I do not understand what the paper really wanted to show. An algorithm? The abstract and the conclusion of the paper gave me very little help in reading it.
I guess that the date the paper was published is related to its abrupt ending, many of the problems that they bumped into are still open today. So in this rather short paper they covered many broad topics but at the moment they where just able to state the problems they found without getting deep into them.
ReplyDeleteOn the other hand I was also a victim of poor latching. And I blame most of my accuracy problems to it. :S
For those of you that used latching, how effective was it? I thought the problem they ran into while trying to latch line segments in the sketch of the cube was pretty neat. Did anyone run into a similar problem if more than one of the triangle strokes did not touch the base of the truss?
ReplyDeleteold paper , seems not bad anyway.
ReplyDelete