~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.

https://www.ioccc.org/years.html#2012_vik

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.

"Lightweight Java" hah!

Knock knock

Who's there?

Long pause

Java

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.

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

Why? If there are 2 adumbra libs, the total size won't change much. But 2 Go hello worlds would take 2x space.

Also, we'd want to include libc.so and even OS kernel that both Go and JVM depend on.

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...