Shape Recognition
Brought to you by:
andreasb123,
auroux
Menu
▾
▴
#3 Shape Recognition
When drawing shapes, this patch will try to find
a matching shape in it's configuration file and
if it has enough confidence, replace the drawn path
with the recognized shape. To build it you need GSL,
so it has to be linked with -lgsl -lgslcblas options.
The RECO FACTOR and PRECISION parameters in xo-shapes
conf file determine the factor for the confidence
threshold after which shapes are recognized and the
precision of shape fitting, which influences speed.
Main patch code
Logged In: YES
user_id=1044657
Originator: YES
Second patch file.
File Added: xo-shapes.h
Main patch code header.
Shape patterns and patch configuration.
Logged In: YES
user_id=1044657
Originator: YES
Third patch file.
File Added: xo-shapes.conf
Modified xo-paint file to include the patch.
Logged In: YES
user_id=1044657
Originator: YES
Fourth patch file (modified original).
File Added: xo-paint.c
Main file with added shape recognition initialization.
Logged In: YES
user_id=1044657
Originator: YES
Fifth patch file (modified original, very small addition).
File Added: main.c
Logged In: YES
user_id=1482965
Originator: NO
Great patch, I love it! Just to clarify, this is a patch against version 0.3.3 (if you want to build it against 0.4, you'll have to merge the changes to main.c and xo-paint.c).
Also, the easiest way to compile with the patch is to modify src/Makefile.am before running autogen.sh, to add "xo-shapes.c xo-shapes.h" to the list of source files, and change the last line to xournal_LDADD = @PACKAGE_LIBS@ -lgsl -lgslcblas
Finally, note that the config file xo-shapes.conf should be in the current working directory or else segfault (yes, a bit of extra error-checking/integration needs to be done on that).
Denis.
Updated patch in one file.
Logged In: YES
user_id=1044657
Originator: YES
This is an updated version of the patch, against 0.4 now.
It adds timestamps and no longer depends on GSL.
File Added: xo-shapes-patch.tar.gz
New and corrected patch file.
Logged In: YES
user_id=1044657
Originator: YES
It seems that the last file attached was corrupted
(thanks to Uwe Winter for pointing that out). Here
is a new version of the patch - in addition to some
corrections recognition finally has its own icon and
can be turned on and off and there are letters as shapes.
File Added: xournal-shapes-patch.tar.gz
Logged In: YES
user_id=1044657
Originator: YES
It seems that this sourceforge system appends bytes to files and corrupts
compressed files when attached to comments. Before we figure out how to
avoid this problem the patch can be downloaded from the address below.
http://www-mgi.informatik.rwth-aachen.de/~kaiser/xournal-shapes-patch.tar.gz
Logged In: YES
user_id=1044657
Originator: YES
I created an updated version of the shape recognition patch for the current CVS snapshot (xournal 4.1).
In addition to a few corrections it includes the pressure sensitivity and resizing patch from Andy Neitzke
(included because it has to be hand-merged) and makes PageUp/PageDown move to Previous/Next page when in
one-page mode and zoomed-out (useful for full-screen work with pdf presentations). Comments are welcome,
the patch is on the web as full files, do "cp -r xournal-shapes-patch/* xournal/" to apply it.
http://logic.rwth-aachen.de/~kaiser/xournal-shapes-patch.tar.gz
Logged In: YES
user_id=1914026
Originator: NO
Neat!
I think there were some small mismerges and perhaps small bugs -- I attach a small patch to be applied on top of yours, which fixed a few issues for me -- I hope I understood your code correctly.
Logged In: YES
user_id=1914026
Originator: NO
Hmm, maybe I am not navigating this interface correctly, or maybe only the creator of a ticket can add attachments; since I can't figure out how to attach it, I'll put my patch (to your patch) below the dashed line.
------------------
diff --git a/src/xo-file.c b/src/xo-file.c
index 7374dcb..47e3aff 100644
--- a/src/xo-file.c
+++ b/src/xo-file.c
@@ -23,7 +23,7 @@
#include "xo-file.h"
#include "xo-paint.h"
-const char *tool_names[NUM_TOOLS] = {"pen", "eraser", "highlighter", "text", "", "selectrect", "vertspace", "hand"};
+const char *tool_names[NUM_TOOLS] = {"pen", "recognizer", "eraser", "highlighter", "text", "", "selectrect", "vertspace", "hand"};
const char *color_names[COLOR_MAX] = {"black", "blue", "red", "green",
"gray", "lightblue", "lightgreen", "magenta", "orange", "yellow", "white"};
const char *bgtype_names[3] = {"solid", "pixmap", "pdf"};
diff --git a/src/xo-paint.c b/src/xo-paint.c
index 6a969c2..ee7be9a 100644
--- a/src/xo-paint.c
+++ b/src/xo-paint.c
@@ -306,6 +306,7 @@ void put_single_shape_on_canvas (interval* shape, int size, int match,
current_item->end_time = end_t;
current_item->recognized_pattern = match;
current_item->path = gnome_canvas_points_new (2 * size);
+ current_item->brush.variable_width = FALSE;
int i = 0;
for (i = 0; i < size; i++) {
@@ -1284,7 +1285,6 @@ void recolor_selection(int color)
if (item->type == ITEM_STROKE &&
((item->brush.tool_type != TOOL_PEN) &&
(item->brush.tool_type != TOOL_RECOGNIZER))) continue;
-continue;
// store info for undo
undo->itemlist = g_list_append(undo->itemlist, item);
brush = (struct Brush *)g_malloc(sizeof(struct Brush));
Logged In: YES
user_id=1044657
Originator: YES
Great thanks for your patch! Obviously I did not test
it with pressure sensitivity and when I started the day
before yesterday I was not sure how to correct it - with
your patch it seems to work well :). I updated the version
online to include the patch, it is much better now, thanks!
Logged In: YES
user_id=1482965
Originator: NO
Many thanks to both of you for these really useful patches. Don't mistake my lack of apparent reaction for lack of interest, it's just that I'm so busy at work that I don't get to spend any time on xournal. But I promise, when I find time (not sure when???) I'll go over the merged patch carefully and make a new release that includes it.
Denis
Logged In: YES
user_id=1044657
Originator: YES
Thanks to the testing done by David Piegdon and Andy Nietzke there
were more problems found with the patch (and I guess threads in
gnome canvas in general). I hope that I protected all unsafe calls
with mutexes this time, the corrected version is online to try out.
Logged In: YES
user_id=1482965
Originator: NO
Release 0.4.2 includes a different implementation of the shape recognizer (obviously inspired by this one, but more narrow in scope). From the manual:
The shapes that can be recognized are: line segments, circles, rectangles, arrows, triangles and quadrilaterals. Polygonal shapes can be drawn in a single stroke or in a sequence of consecutive strokes.
The recognizer is set to be as unobtrusive as possible, and should not interfere too much with handwriting. (It differs in this and other ways from the shape recognizer written by Lukasz Kaiser). As a result, it may only recognize shapes if you draw them carefully and deliberately. Specific tips for better recognition: (1) for circles, a closed curve that isn't quite round works better than a rounder curve that doesn't close; (2) for arrows, it is better to lift the pen before drawing the tip of the arrow, and make sure the tip consists of two straight line segments; (3) for very elongated rectangles, recognition tends to be better if you lift the pen between consecutive sides.
The to-do list for future releases includes doing some more work on this recognizer (in particular to address issue (3) at least). If you have used Lukasz's recognizer on a semi-regular basis, feedback about whether the new recognizer is overall better or not, what the most urgent improvements to it would be, whether it should be made more tolerant (easier match) or less tolerant (harder to match) in various situations would be useful.
Denis
Logged In: YES
user_id=69814
Originator: NO
Hello,
I just installed Xournal 0.4.2.1 on the Nokia N810 and the inclusion of the shape recognition was a very pleasant surprise. So far it works fairly well. The tablet does have pressure sensitivity and that brings a few quirks into it though.
Either due to the pressure sensitivity not being calibrated (since there is no GUI to do so) or just the regular functioning of that mode, the lines drawn are much lighter than the actual line thickness set since it seems to use the pressure to apply a factor from 0-1 to the line thickness. However, the recognized shape picks the actual line thickness set (uses a factor of 1) so it redraws the line much thicker. So if you draw a thin-lined circle, it is replaced with a fat-lined circle that doesn't match any of your other diagram. This can be solved a few ways:
- by adjusting the pressure sensitivity to use the line thickness chosen as its midpoint factor (have the pressure sensitivity apply factor of 0-2 to the line thickness)
- have the shape recognizer draw a line thickness that is the average of the line thickness it got its shape from
- have the shape recognizer use some user defined shape thickness as it might make some sense to have a separate line thickness for diagrams than for writing.
I think that doing at least the first one when pressure sensitivity is enabled would make pressure sensitivity work better because at the moment, you do get very thin lines unless you use something bigger than medium thickness. Part of the problem is that (at least on this tablet) pressure sensitivity is not really measuring pressure. It is measuring force. So if I press with my finger (small pressure over a large area), I get a very fat line (but have no control) but if I press with the stylus (high pressure over a very small area) I can never reach the max line width without risking driving the stylus right through my LCD screen.
I also find myself too sloppy for the shape recognition to correct me unless I am very careful and almost draw a perfect shape anyways. In reading here, I see that there is a conf file that I can play with. I'll play with it to see if I can find a happy medium for me but since this is a fairly personal thing based on individual dexterity, it would be nice if RECO FACTOR was presented in the GUI somewhere as a slider or something. PRECISION is likely a function of hardware and likely would be best tucked away in a conf file for the different porters to set appropriately.
Lastly, the resulting shapes don't always have the right parameters (diameter, length, angle, tangency, etc.). It would be pretty cool to be able to edit these parameters after drawing them. I neat idea would be to enter a mode where you could draw annotations like you would in elementary school geometry in order to set the parameter relations. For instance, if you wanted to square up two lines, you would draw a box at their intersection. Or if you wanted to make line segments equal, you would draw an equals sign intersecting the mid-section of one line and another intersecting the mid-section of the line you want to to be an equal length. You could use three lines to indicate that you want both lines to change size to the average of the two lengths. A similar thing could be done with arcs to set angles between lines. Doing the same thing at the end points of lines could pin them to each other. A single stroke could move them. Etc. Etc. Anyways ... I could dream that someone would implement something like this since I don't have the coding knowledge.
Regardless ... keep up the good work.
Logged In: NO
The width of the pressure-sensitive strokes can indeed be calibrated (at least crudely), although unfortunately there is no GUI for that.
The relevant entries in .xournal/config are
width_minimum_multiplier and width_maximum_multiplier. So to get the behavior you wanted, you could set them to
width_minimum_multiplier = 0.0
width_maximum_multiplier = 2.0
Logged In: YES
user_id=1482965
Originator: NO
As already mentioned, for now the recommended thing to do is to modify the width_minimum_multiplier and width_maximum_multiplier in .xournal/config (not sure how easy that is to do on a Nokia tablet, since there's no setting in the GUI, and I know there isn't a keyboard to edit the config file with...). (maybe to 0 and 2 instead of the default values 0 and 1.25, as suggested by the previous poster; or maybe to 0.5 and 1.5, or whatever you feel is appropriate). The idea being that your variable-width strokes should be of the same average width as if you had disabled pressure sensitivity.
Over the longer term, I entirely agree with your idea that maybe the recognized stroke should be given the average width of the stroke drawn by the user. I'll add this to the to-do list for the next release.
Thanks!
Denis