Pressure bug?

[xuv]

While trying to come up with dummy file, I think I encountered a bug in the interpretation of the pressure data. Or maybe it's the pen itself that bugged.

Here is a link to the WPI file: http://xuv.be/static/inkling/tree.WPI And what it looks like when converted to svg.

I also have to tell you that the line that draws the contour of the tree was much much longer on paper. I have no idea why it stopped recording at 3/4 of it.

[roelj]

I've experienced the problem of the fill on the down-right corner (from the beginning of stroke pressure implementation). I thought I was the only one..

Maybe you could draw to the edges of the paper to see if the data is really cropped.. I think I need help from @MeraX because he provided the patches for stroke pressure support. So @MeraX, if you read this, could you help fixing the problem? If there's anything you want me to provide, please let me know.

[xuv]

Maybe you could draw to the edges of the paper to see if the data is really cropped..

I don't understand this sentence. What do you mean by the edge of the paper? I guess there is a limit to what the Inkling tool can "see". Is that what you mean. Trying to reach those limits?

[roelj]

Something like this:

[xuv]

Based or your proposition, I made a test file drawing borders of paper sizes from A6 to A3. The file: http://xuv.be/static/inkling/A6-A3.WPI The setup:

Might be a "good" test file. When trying to convert it to JSON, I got a lot of warning messages telling me "malformed data" or something similar. I guess it's because of the lines beyond A4. For some reason, the inkling recorded some. But I have no idea how InklingReader converts them. Because some don't appear in the svg.

Although pressure bug is not appearing here. :)

I like the fact that lines are rendered even outside of the A4 canvas. It's useful to me. My guess is that all the data that makes sense in the WPI file should be converted to SVG drawing. Even if it lacks pressure or tilt data as it seems with some lines here. What do you think?

[roelj]

Thanks for the great test setup!

The Inkling doesn't record pen strokes within 2 cm of the Inkling device (there's nothing we can do about that).

I'll remove the A4 restrictions from the code. As far as the "stroke fill" bug goes, I don't have a solution (but I am looking for one).

[roelj]

It seems that the A3 strokes haven't been recorded (could you try draw over the A3 line and watch the green light on the inkling device?).

The A4 line is being displayed completely now (but not very precise).

[xuv]

Mmmmh, strange that the A3 lines are not there. I especially had to re-draw them many times until I had the green light on. But anyway, I made another drawing. Starting from a point just below the center of the A6 and reaching the corners of all the sheets from there. It seems that if you start from a point close to the Inkling, you can go to the bottom corners of an A3. But it's hard to get a green light when starting to draw down there. I had to draw many "A3" letters going up the sheet before seeing the green light. Here's the file: http://xuv.be/static/inkling/A6-A3_star.WPI

And thanks for removing the A4 limit. It works very well. (although not the gui. See #21)

[xuv]

Here's another 'test' file. I've drawn a grid (with a ruler) on a A3 paper. Starting from the top left. Drawing horizontal lines every 1cm (from left to right) down and vertical lines, every 1cm, (from top to bottom). Makes a funky looking grid because I didn't keep the pressure steady. And gives a sense of the limits of the tool for accuracy and detection. Here is the file: http://xuv.be/static/inkling/A3_grid.WPI (the A4 canvas is rendered in gray)

[roelj]

Thanks for the great test file (again). I guess it would be great when InklingReader could determine the size of the paper automatically.

I wonder if using the tilt data could make the drawing more accurate.

Also, I think we could write "optimizers" to make the lines more straight (and in thus more accurate in this case). For this I should rewrite some bits of the SVG converter.

As for the pressure bug. @MeraX, do you have an idea for how to fix this?

[xuv]

Many subjects here. Sorry if it's a bit long to read.

Paper size

It's funny because I've been wondering for a while if it is necessary for InklingReader to determine the size of the paper based on the drawing or not. At first, I would have said yes. But I'm not sure anymore. So far, the way you've set it up is fine for me, a standard A4. As long as we get "all" the lines drawn in an svg, it doesn't really matter if it goes beyond the "paper" limits.

As a feature suggestion though: the user could maybe determine a canvas size while loading the drawing. Let's say if someone draws on a A4, A5 or A6, in portrait or landscape. Because when you draw, you usually draw in relation to the limits of the paper you're drawing on and work on the composition of that drawing in the page. So maybe if the user would say what are the page dimensions he or she was working on, the composition could be kept in the output file. (It could be presets like A3_landscape or A5_portrait. or 200x200mm). That, I think, would be a useful option.

Line optimizer

As for the "optimizer", I'm not sure about it. I personally like the "loss of accuracy" when the drawing gets too far from the "receiver". That's exactly why I made this kind of test file. To see how it would behave and what are the limits of the tool. And this test file tends to show that the A4 (+ a 2cm border) is the canvas where there is the less drawing bias.

Maybe, you're suggesting to use an optimizer for these lines beyond the A4? If so, it would require a lot more similar test files I guess. Maybe some test drawings done with a CNC could be good. So pressure, tilt, speed and directions could be constant.

As a similar suggestion, I remember that at LGM, when we talked about the software, some people where suggesting a line optimizer could be used to reduce the number of points in the svg while keeping the drawing close to the original. And they where talking about mapping algorithms for that. But I'm not sure it is really relevant here.

Pressure bug

Since this is the subject of this thread ;) The only "problem" I see in the test file, is maybe the big "chunky" vertical line in the middle of the drawing. I don't remember having pressed that much to draw it. The rest, might be more correct. It's also funny to see that the width of the line seems to expand in one direction only.

[roelj]

I changed the SPIKE_THRESHOLD (a variable in src/converters/svg.c) and opened your tree.WPI. It looks fine now.

[MeraX]

Yeah, that was a feature I introduced to reduce spikes. The value 20 is just randomly choosen. I'm glad your figured this out.

I'm very happy to see progress in this project but unfortunately I haven't got a lot of time to contribute my self.

[xuv]

@roelj : Great. And it "solved" it also in the A3_grid.WPI file with the vertical line. Awesome job. I also like the zoom feature. Good idea.

Maybe I should file this in another issue. But I get warnings when I load a file.

(inklingreader:13381): Gtk-CRITICAL **: gtk_widget_set_size_request: assertion `width >= -1' failed
(inklingreader:13381): Gtk-WARNING **: drawing failure for widget `GtkDrawingArea': invalid matrix (not invertible)

Not that it matters much because everything seems alright. But thought I would tell you. Guess you know it already.

[roelj]

@xuv: Actually, I hadn't seen it, and I hope the patch solves it.

[xuv]

@roelj : Sorry to say that even with e69d40de5b9ca830bee2ef0e1fb91ec66c12a78f, the errors are still showing when loading a file.

[roelj]

@xuv: Could you open a new issue for this and possibly share the file that you're receiving this error with?

[xuv]

Done. Moved to other issues what was "opened" here. So maybe we can close this "pressure bug".

[roelj]

If anyone is interested in line optimizers, please open a new issue. I think the rest got covered.

I'm closing this issue now.