Image steganography that is corrupted by any sort of lossy compression is practically useless, unfortunately. Such method is only meaningful when the image acts as a transparent container of non-sensitive data, like PICO-8&#x27;s .p8.png (and yet its distribution will be severely constrained), but this library clearly wants to embed a secret payload...

Eight pixels ber byte would indeed be more efficient, but the intent of this library was to make the hidden message as discreet as possible, rather than transmit as much hidden data as possible. 
By modifying only occasional pixels, in an unpredictable pattern (based on a secure hash of the key), my hope was that it would make detection more difficult. Whether I succeeded or not remains to be determined, I suppose.

~500 pixels for every byte seems wasteful, I would have expected just ~8 pixels for a single byte (using just one bit from each pixel).For comparison, this IOCCC entry can encode ~128 bytes of random binary data in 33000 pixels, or ~16K of ASCII text.<a href="https:&#x2F;&#x2F;www.ioccc.org&#x2F;years.html#2012_vik" rel="nofollow">https:&#x2F;&#x2F;www.ioccc.org&#x2F;years.html#2012_vik</a>

Comparing fairly with Go would mean adding the JRE to the lib, because the lib itself is useless. Go produces executables.

Don&#x27;t see a snark here -- Java libs are really lightweight, in a matter of kilobytes. Because it&#x27;s interpreted, you&#x27;re supposed to have OS-specific JVM installed to run it. Exactly the same as Python.Compare that to Go, where Hello World weighs 1.8 MB, more than 100x heavier than the lib in question.

Knock knockWho&#x27;s there?Long pauseJava

Adumbra: A lightweight Java library for bitmap steganography