Generally speaking, xz provides higher compression.

None of these are well optimized for images. Depending on your image format, you might be better off leaving those files alone or converting them to a more modern format like JPEG-XL. Supposedly JPEG-XL can further compress JPEG files with no additional loss of quality, and it also has an efficient lossless mode.

Do any of them have the ability to recover from a bit flip or at the very least detect with certainty whether the data is corrupted or not when extracting?

As far as I know, no common compression algorithms feature built-in error correction, nor does tar. This is something you can do with external tools, instead.

For validation, you can save a hash of the compressed output. md5 is a bad hashing algorithm but it’s still generally fine (and widely used) for this purpose. SHA256 is much more robust if you are worried about dedicated malicious forgery, and not just random corruption.

Usually, you’d just put hash files alongside your archive files with appropriate names, so you can manually check them later. Note that this will not provide you with information about which parts of the archive are corrupt, only that it is corrupt.

For error correction, consider par2. Same idea: you give it a file, and it creates a secondary file that can be used alongside the original for error correction later.

I also want the files to be extractable with just the Linux/Unix standard binutils

That is a key advantage of this method. Adding a hash file or par file does not change the basic archive, so you don’t need any special tools to work with it.

You should also consider your file system and media. Some file systems offer built-in error correction. And some media types are less susceptible to corruption than others, either due to physical durability or to baked-in error correction.

I actually did this a lot on classic Mac OS. Intentionally.

The reason was that you could put a carriage return as the first character of a file, and it would sort above everything else by name while otherwise being invisible. You just had to copy the carriage return from a text editor and then paste it into the rename field in the Finder.

Since OS X / macOS can still read classic Mac HFS+ volumes, you can indeed still have carriage returns in file names on modern Macs. I don’t think you can create them on modern macOS, though. At least not in the Finder or with common Terminal commands.

It would be like taking your compiled machine code and editing it by hand because your compiler sucks.

Just use the right tool from the start.

No way Linux is 32! I remember when it first came out and it was just…oh.

Don’t mind me, I’ll just be here yelling at the cloud.