maciel310 / nortnacs Goto Github PK

Currently the only data processing is basic survey analysis. The application 
should also include a grading feature where the user enters an answer key, 
selects the exams, and a grade is assigned to each file.

The user should have the option of entering a set of custom fields to be 
associated with each image. This would be used for entering the name on the 
test, ID numbers, etc. This may be implemented as either a set number of fields 
(Custom1, Custom2....), or as a dynamic feature where the user first enters the 
field names they'd like to have for each form, then the data for each image.

The processed form data (final grades) should be exportable in a CSV format, 
listing the custom entry forms, image file name (full path?), and the 
calculated grade.

Overview information might be implemented, offering information such as most 
missed questions, score distributions, etc. Some data analysis can be left to 
the user using the above CSV export.


Two methods of defining the answer key might be provided. The first option 
would be to have a printed form filled out with the correct answers, scanned 
in, and then processed as being the answer key. The other option would be to 
implement a Graphical User Interface where the user enters the number of 
questions, the number of choices, and then they are presented with an array of 
checkboxes (option for radio buttons to prevent possible errors?) which the 
user would fill out and save as the answer key. Option 1 would likely be the 
easiest to implement, though slightly more tedious and indirect.


Answer keys should have the option of being saved, eventually in an encrypted 
(enter a password every load, as PDF files) file format. Need to research if 
any applicable standardized file format exists (doubtful). Barring that, the 
file format would be a simple JSON object with data members containing 
descriptions, and a two dimensional array of boolean values indicating answers. 
Password protection would be layered on top of this file format using a 
standard text encryption algorithm, possibly Base64 encoded to be ASCII safe.

To make processing easier, there may be a wrapper JSON object that either has a 
data member containing the encrypted string or the unencrypted object described 
above, that way no extra logic needs to be implemented to detect if it should 
JSON process the string or Bas64 decode, decrypt, then decode.


Auxiliary functionality that still needs to be considered are things such as 
automatic curving, weighting questions, etc.

Currently, the Form processing algorithm is not very robust against rotation 
that might occur during scanning.

Two areas need to be modified in order to make this more robust. First, the 
rectangle scanning routine should be modified to better account for the 
starting line being at an angle. Currently the algorithm always starts back at 
the same starting column when going to the next line, and this should be 
altered to account for the slope that occurs when the image is rotated.


The other issue is that if an image is rotated, the intersection of a row and 
column marker won't actually correlate to the center of the bubble, and in 
extreme cases might even cause it to look at the next bubble over. This can be 
accounted for by using the calibration points. Once the calibration points are 
found, the slope between the points can be calculated, and then that same slope 
can then be utilized when traversing to the intersection point of the row and 
column and that will yield the correct point.


A simple rotational error that will be easy to fix is if the image is scanned 
in at 90, 180, or 270 degrees, thus causing the row and column markers to be in 
the wrong spots. We can know that this occurred if either the row or column 
counts (or both) are zero, and then rotate accordingly (each case has a 
corresponding rotational error). This rotational correction should be fixed 
ASAP.