Even though version 0.5 was released just a couple of weeks ago, the next release, 0.6, is approaching. As I did with the previous release, I'll blog about the new features it will include as they are more or less ready.

The first feature I'd like to talk about is a new subsystem for recognizing handwritten digits, which replaces the one that I wrote in the early days of Eyegrade. Rodrigo Argüello, a former student of mine at Universidad Carlos III de Madrid, volunteered to improve the previous system with a machine learning based solution. More specifically, he used a support vector machine (SVM). The machine is trained by showing it lots of samples of each digit, and telling it which digit each sample represents. Once trained, you can show an image of a digit to it, and it will answer with the digit it considers the best match for the image.

Rodrigo tried with several strategies before finally integrating one into Eyegrade. Our first tests in real scenarios show that, under conditions in which the former system failed approximately once for every 6 student identifications, the new system fails approximately once for every 20. I believe it is a big step forward. Many thanks to Rodrigo for his great contribution, and to Roberto for sending us tons of samples for training and testing the new system.

Removing the old digit recognition system provides a second benefit: the tre library is no longer needed. The fact that it wasn't a pure Python library, and that it doesn't seem to be widely used from Python, was a headache for deploying the Windows version, and complicated the installation procedure in Linux a little bit. If everything goes as planned, you can expect a greatly simplified installation procedure, especially for Windows users. More on this topic on my next post.

I've finally released Eyegrade 0.5. As I've advanced in the previous four posts, its new features are:

• It stores exam captures and updates their miniatures immediately when they are captured or you edit an answer or the student id (blog post).
• I've reworked the subsystem that manages the identity of the students. Optionally, students may now have separate first and last name, and there is a new dialog for entering new students when they aren't in your student lists (blog post, explanation in the user manual).
• Each question in a exam can have now a different weight in the final scores. This way, you can assign a bigger weight to the most important questions (blog post, explanation in the user manual).
• If you don't want a question to contribute to the score of the exam, now you can do it when creating the session. For example, it is useful when you discover an error in the statement of a question, but it's too late for fixing it. With this feature you can avoid grading that question (blog post, explanation in the user manual).

If you have installed eyegrade through git, you can easily update the program from versions in the series 0.2.x and later by executing the command git pull from inside the directory in which Eyegrade is installed (explanation in the user manual).

Be aware that Eyegrade 0.5 uses an updated session database schema. Although Eyegrade 0.5 is able to work with sessions created by the previous versions of Eyegrade, those previous versions don't work with sessions created by Eyegrade 0.5.

I'm holding release 0.5 more than expected because I plan to add a couple of features more. Today I'll talk about one of them. Roberto González, a long time user and contributor of Eyegrade, wondered in his comment to my previous blog post whether the new feature for assigning different scores to questions could be used to void those questions that one doesn't want to grade. This may be useful, for example, when, being late for doing changes to the text of the exam, you want to invalidate a question because you discover that there is a severe error in how it's stated. Roberto commented another situation in which voiding a question would be very useful for him.

Roberto cleverly suggested that assigning weight zero to those questions would make it. I've been working on his idea. When you set the scores of the questions and select the base score plus per-question weight option, you'll be able to assign weight zero to some questions:

The example above voids question 5 in model A, which is also question 1 in model B, question 2 in model C and question 3 in model D. Void questions will be clearly displayed in the capture of the exam, and won't be considered either for the score or the count of correct and incorrect questions:

This new feature has a limitation though: you'll have to void the questions when you create the session. You won't be able to do it once the session has been created. For future releases I'll try to allow changing question scores for existing sessions, so that the scores of the exams that have already been graded get computed again and their captures get updated.

Continuing the series of posts that describe the new features of the future eyegrade 0.5 release (see the first and second posts), I'll introduce today a new one: the possibility to assign separate scores to different questions.

Until now, the system assumed that all the questions had the same weight when computing the score for an exam. For example, suppose an exam with 10 questions, in which correct answers add 1 point to the score and incorrect answers subtract 1/3 points (one third of a point). A student having 7 correct and 3 incorrect answers will get 6 points (7 * 1 - 3 * 1/3).

With the new feature, not all the questions need to be awarded the same score. Important questions may get bigger scores than others. In order to do that, you define a base score (e.g. 2 points for correct answers and -2/3 for incorrect ones) and a relative weight for each question. The weight of a question is a factor that multiplies the base score in order to get the actual score of that question. For example, for a question you want to score double than the base score (4 points for correct answers and -4/3 for incorrect ones) you would set a weight of 2. For a question you want to have exactly the base score, you would set a weight of 1. You can even decrease the score of a question with respect to he base score. A weight of 1/2 would mean 1 point for correct answers and -1/3 for incorrect ones in our example.

You'll be able to edit the weights of the questions in one of the steps of the wizard that creates a new session. In that page you select between having no scores, the same score for all the questions and the new weights-based variable score system:

If you select the last option, you'll edit the scores in the table at the bottom of the dialog:

You can enter in each cell integer numbers (e.g. "2"), fractions (e.g. "1/2") or decimal numbers with fractional digits (e.g. "2.5"). If you have several exam models (alternative orderings of the questions), eyegrade will check that you enter the same weights in all the models, possibly in a different order for each model:

In addition, if your session configuration file contains the permutations done to each model (if you create the documents of your exams with eyegrade, it will), eyegrade automatically updates the value in all the models every time you change the weight of a question in one of them. However, if the file does not contain the permutations, you'll need to enter the weights for each model.

I've also updated the dialog that, given a desired maximum score, configures the score for each question. Click on the compute default scores button after you have entered the weights and eyegrade will choose the base score so that the maximum possible grade is the one you choose, taking into account the weights you set:

Keep tuned for more updates.

This post describes another feature that will be available in eyegrade 0.5 (see the first installment of this series of posts).

I've largely reworked the code that handles the student lists. In eyegrade 0.5 you'll see two visible changes regarding this. Firstly, you'll be able to specify the first and last name of students in two separate fields. Secondly, there is a new dialog for entering, while grading an exam, new students.

Separating first and last name will be optional. Eyegrade will infer, from the student lists it imports, whether you are providing separate first and last name fields, or the whole name together in just one field. When exporting grades, you'll have control over which name fields get exported and will be able to sort the listing by last name if you wish so.

Regarding the second change, there will be a new button in the dialog for editing the student id that lets you open a dialog for entering the data for a student that is not in your student lists:

The dialog asks for the numerical id, first name, last name and email. Only the numerical id is mandatory. This is the current look of the dialog, although it might change before the release:

Apart from fixing some minor issues here and there, I'm currently busy adding some new features to eyegrade. Some of them are already integrated into the development branch at GitHub. The plan is releasing them with eyegrade 0.5 sometime in January. I'm not sure yet which new features will make it into the release but, starting with this post, I'll describe some of them once they are more or less ready.

The first feature I'll talk about is actually a fix for a counter-intuitive behavior of the right-side view of exams (the one I introduced in eyegrade 0.3 that shows miniatures of the exams that have been graded in the current session). Up to now, the miniature was not immediately updated when the webcam captured a new exam or you edited something on a previously graded exam. It was updated later, when you changed to another exam or started to grade a new one. That was somewhat confusing for many users. From version 0.5 onward the miniatures will get updated immediately when the webcam captures a new exam or you edit an exam. I believe that having that immediate feedback will improve the overall user experience.

More posts will follow with the description of other new features.