Madeline Krajewski

This week, I embraced the excruciating truth that Algorithm 1 still isn’t done. This week, I set my sights on finishing it. I stand before you today with the tragic truth: it still isn’t done. It is, however, getting pretty close! I encoded the width and height, the decoder (and its ability to decode images of different sizes), and a few other bits and bobs. I also revisited Visual Cryptography and Threshold Schemes” by Doug Stinson to develop Algorithm 2.

It… didn’t really help. I have many questions on how to proceed with it, and my approach is unfortunately not correct. I think I will refrain from explaining my interpretation here, because I am quite certain it is incorrect.

Now, the progress I’ve made on Algorithm 1:

I moved the encoding of the First Pixel (the number of encoded bits) into its own function in order to make my main function easier to read. This is a small change, but it definitely enhanced my quality of life.

I encoded three pieces of information into the Second Pixel’s least significant bits: whether or not the number of encoded bits is an eight; whether or not the secret image is the same size of the host image; and finally, whether or not the secret image is 1/2 the size or smaller than the host image.

Why, you may ask? Well, the first pixel holds the number of bits (from the secret image) which get encoded. There are three binary digits available to use, and that translates to a range of 0-7. I want to allow the user to encode zero and eight so they can see what occurs. I think experimentation is an incredible way to learn, and I want to provide that to the user if I can. As such, I need a fourth bit to differentiate between 0 (000 in binary) and eight (1000 in binary). If the eight-“flag” is 1, that means we have an eight. It cannot be a one if the number of bits exceeds eight.

If the secret image is the same size as the host, hooray! We don’t need to bother encoding or decoding the secret image’s width and height. Finally, if the secret image is 1/2 the size of the host or smaller (via the total number of pixels), we can actually encode more information by spreading it out over the host’s pixels.

The Third and Fourth Pixels will hold an offset (the third pixel holds the x value, and the fourth holds the y value). This offset is used when the secret image’s size is small enough where we do not have to use the first twelve pixels for encoding image information as well as the most significant bits of the secret image. I have not, however, encoded this yet; it will basically reuse the same code as the First Pixel.

The next four pixels have the width of the secret image, and the following four pixels have the height. This allows twelve bits for the width (since each pixel has an R, G, and B value), and twelve for the height. This allotment allows secret images with a width and/or height of 4,000 pixels in length.

Here is the summary:

I also wrote the decoder for all of these (as well as the offset decoder, though I cannot verify it works).

I still need to figure the smaller image size encoding and decoding. I know how to do this, but I just did not get to it this week. I cannot wait for it to be done, because then the only things I have to do for it is add hashing (which I don’t think I’m required to do), and threading (which I will probably tackle at the same time as the other algorithm, since both will need it in the final versions of my programs).

I am so ready for Algorithm 1 to be over.