3 ms·
You're ignoring two things: 1) that the aggregate savings from compressing the images needs to outweigh the initial cost of distributing the decompressor. 2)
by ebg13 7y ago
You're ignoring two things:
1) that the aggregate savings from compressing the images needs to outweigh the initial cost of distributing the decompressor.
2) to be lossless, decompression must be deterministic an unambiguous, so you can't compress _everything_ down to zero bits; you can compress only _one_ thing down to zero bits, because otherwise you wouldn't be able to unambiguously determine which thing is represented by your zero bits.
- yters 7y agoIn each case I pick out an algorithm beforehand that will inflate my zero bits to whatever artifact I desire.
- ebg13 7y ago"I will custom write a new program to (somehow) generate each image and then distribute that instead of my image" is not a compression algorithm. But I think you'd do well over at the halfbakery.
- yters 7y agoIt works well if it's the only image!
- ebg13 7y agoNow you're chasing your own tail. You've gone from "I can losslessly compress everything" to "I can losslessly compress exactly one thing only".
- yters 7y agoI'm arguing it's the same as this image compression technique. They rely on a huge neural network which must exist wherever the image is to be decompressed. If I'm allowed to bring along an unlimited amount of background data, then I can compress everything down to zero bits. In contrast, an algorithm like LZ78 can expressed in a 5 line python script and perform decently on a wide variety of data types.
- ebg13 7y ago> If I'm allowed to bring along an unlimited amount of background data, then I can compress everything down to zero bits. If by "background data" you mean the decompressor, this is patently false. No matter how much information is contained in the decompressor (The Algorithm + stable weights that don't change), you can only compress one thing down to any given new representation ( low resolution image + differential from rescale using stable weights ). If by "background data" you mean new data that the decompressor doesn't already have, then you're ignoring the definition of compression. Your compressed data is all bits sent on the fly that aren't already possessed by the side doing the decompression regardless of obtuse naming scheme. > I'm arguing it's the same as this image compression technique. That's wrong, because this scheme doesn't claim to send a custom image generator instead of each image, which is what you're proposing.
- mypalmike 7y agoThe neutral network is not an unlimited amount of data. It is fixed size, and not transferred. Further, if you're not familiar with the pigeonhole principle, it might be worth a read on Wikipedia.
- milesvp 7y agoYou have to convey which algorithm, which takes bits. And at the very least you need a pointer to a file, which also takes bits. You’d do well to look for archives of alt.comp.compression. There was also a classic thread that surfaced recently on HN about a compression challenge whereby someone tried to disengenuously attempt to compress a file of random data (uncompressable by definition) by splitting it on a character then deleting that character from each file. Was a simple algorithm, that appeared to require fewer bits to encode. The problem is, all this person did was shift the bits to the filesystem’s metadata, which is not obvious from the command line. The final encoding ended up taking more bits once you take said metadata into account.
- karpierz 7y agoThen that becomes part of the payload that you decompress, and you no longer have a 0 byte payload.