Inspiration
KQR was inspired by the shortcomings of standard QR and their limited storage capacity. At a previous hackathon we attempted to remediate these short comings with a project we called CQR (Colored QR). However, due to the 24 hour time constraint, lack of knowledge, and various hiccups regarding the implementations of readers and writers CQR ultimately was fundamentally lacking in features making it woefully inadequate to act as a next-gen replacement for QR. As such, coming into this hackathon, we initially wanted to improve on CQR as a whole in addition to bundling some neat features that we will touch on later.
What it does
The project, similar to QR, splits its data and coding areas into sectors with each sector encoding a byte of information. Making up sectors we have packages able to occupy 16 different colors and representing 4 bits per package. Within each sector is two packages, another way to think of sectors is the number of bytes a KQR code can hold. KQR utilizes three marker regions representing each of the main colors on the CMYK gamut. Between each marker region is a timings region which helps the reader discern the number of physical pixels making up one package block. By physical pixels here we are referring to the number of pixels making the picture of the code which is wholly dependent upon the camera being used and its fidelity, as various phones have different cameras and different qualities. Adjacent to each of the marker area lies a sector dedicated to conveying the encoding scheme and directly next to that lies the application template ID.
Within the application that would read these KQR codes would lie an interpreter that would first find the encoding scheme, then read the application template ID (APID). After acquiring the APID, it would then be hashed with SHA256, then compared against the other stored hashes within the local repository for application templates. If the template was not found, it would make a request to the central repository of templates to download the missing template. It is important to note that this would only have to happen once. After the template has been added to your local repository it can be used offline on any KQR's you may encounter.
How we built it
As stated prior, we initially intended on modifying CQR in order to increase its viability and expand its features. As we progressed through the hackathon we realized it was going to take significant restructuring and overall changes to implement the features we desired. As such, effectively this project was a complete recode of the CQR project including better logic and vastly changed code formatting internally. We decided to create this project on Java for its portability and ease of integration onto the Android platform. The only resources First, we sketched out on a notebook the encoding pattern and general face of the glyph. After finishing our sketch in a pixel art program for the glyph we then began to replicate the markers, quiet zones, and encoding regions. This is where we made one of our first big changes. Encoding regions previously only occupied one location on the glyph, below the top left marker. In our new and improved design we encode this information adjacent to each marker, now providing us with two redundant copies of the encoding scheme and the APID. After that, we worked on streamlining the package converter and adding a payload compressor. This helped establish some additional space to allow for the added overhead from the inclusion of the app template system.
Challenges we ran into
After having to scrap seven different encoding schemes, two different payload compressors and, last but not least, the reader and writer innumerable times, it's safe to say we had plenty. First, let's delve into why we changed the encoding scheme so many times, then we shall proceed with each topic with respect to how they were introduced. Encoding changed often for many reasons, to start, initially we were trying to use CQR's encoding scheme and slowly derived hybrids of the existing CQR scheme and a new scheme. Ultimately, CQR's encoding scheme, featuring half of a sector, was to be replaced entirely by a full sector encoding scheme where the leading package (lower 4 bits) indicates a data type and the following package (upper 4 bits) indicates the presence of compression, a typical character mapping, and other special add-ons for that particular data encoding scheme. We ended up scrapping all of the hybrid encoding schemes and CQR's encoding scheme together though far later then we should have. CQR's lack of encoding information redundancy can very capably present issues were those sectors ever lost or damaged. Additionally, the template system required us to completely re-evaluate priorities as the template system utilizes eight sectors filling all but one sector, which is reserved for the aforementioned final encoding scheme we settled on. Payload compressors proved to be an absolute nightmare as we were using Java's standard libraries for compressing byte arrays, however unknown to us the bytes were all signed rather then unsigned, causing easily seven hours of work due to the various issues it caused in literally every subsystem. After numerous attempts to find the issue we were simply running into various other bugs throughout the project thinking we solved the issue at hand. As for the reader and writer, at various stages in the competition we took extreme caution to ensure that the reader and writer were always in sync with their methods for encoding and decoding information from KQR's. Despite our best efforts, frequently the reader would break and the writer would overwrite data in crucial locations silently due to offsets that were not accounted for at the time, leading to unintended behavior. Various other challenges did crop up throughout the challenge, though these three took a significant toll on our time thus we consider them to be the most significant.
Accomplishments that we're proud of
The implementation of the template system paving way for the storage of entire applications within the KQR codes. Additionally, with the various methods for reading and writing streamlined it is very likely now to have better responsiveness when finally implemented into an app even on older devices.
What we learned
Compression is very complicated and definitely something to be respected. Additionally, the amount of bitwise operators used throughout the project certainly was a birth-by-fire for various team members that may not have been exposed to them previously.
What's next for KQR (QR Stored Applications)
The usage of templates to create QR stored apps as well as the creation of a central template repository to ensure that all together this project can become a real world, quality of life, improvement for everyone and one day maybe even the thing that gets you your coffee quicker.
Log in or sign up for Devpost to join the conversation.