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.
Don't see a snark here -- Java libs are really lightweight, in a matter of kilobytes. Because it's interpreted, you'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.
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's .p8.png (and yet its distribution will be severely constrained), but this library clearly wants to embed a secret payload...
9 comments
[ 3.2 ms ] story [ 48.9 ms ] threadFor comparison, this IOCCC entry can encode ~128 bytes of random binary data in 33000 pixels, or ~16K of ASCII text.
https://www.ioccc.org/years.html#2012_vik
Who's there?
Long pause
Java
Compare that to Go, where Hello World weighs 1.8 MB, more than 100x heavier than the lib in question.
Also, we'd want to include libc.so and even OS kernel that both Go and JVM depend on.