Boundless information storage in limited space [didn't work]
Well, even if N, A and B are constrained, it might be an interesting algorithm. Could you try it for some arbitrary values, say N=10, A=B=500, and see if it still works?
Just by scanning your original post, it sounds a lot like texture atlasing (specifically for textures). I could perhaps see a very minimal savings in space due to the fact you won't have file headers for each file.
Quote:Original post by Moe
Just by scanning your original post, it sounds a lot like texture atlasing
Quote:Original post by Subotron
I have written a program that is able to store N bitmaps (size AxB pixels) into just one bitmap of the same size (AxB).
I can fit N bitmaps of AxB into a single AxB bitmap. All I need is to make the new bitmap have N times the number of bits per pixel as the initial ones.
I can compress ANY file to the original size minus one byte. Simply cut out the last byte and encode it into the filename :)
Quote:Original post by Fred304
I can compress ANY file to the original size minus one byte. Simply cut out the last byte and encode it into the filename :)
Wouldn't work. No operating system allows all 256 values of a byte as valid characters for filenames.
However, you could take the last three bytes off of a file, base64 encode them, and use that instead...
(LOL!)
I think the confusion in this thread stems from either poor wording on the OP's part, or a misunderstanding of what "compression" means:
These two statements are contradictory, since the program you describe is, in fact, performing compression. Compression means that the encoded form (the "combined" image) uses fewer bits than the unencoded form (the individual images). (I am assuming that the number of bits per pixel is identical in the encoded form as in the unencoded form.)
The title of the thread ("Boundless information storage in limited space") is also a physical impossibility. Limitless information cannot be encoded using finitely many bits; you are limited to the amount of different representations that could be encoded using those bits. Supposing that it were actually possible to store "limitless information" in finitely many bits, this would imply that some of the representations are equivalent. In turn this means that you're not really storing limitless information at all since you are constrained to the number of possible bit patterns, a contradiction.
Quote:Original post by Subotron
I have written a program that is able to store N bitmaps (size AxB pixels) into just one bitmap of the same size (AxB).
(...)
[T]his is NOT a compression algorithm, but an alternate, small way to store multiple objects into one.
These two statements are contradictory, since the program you describe is, in fact, performing compression. Compression means that the encoded form (the "combined" image) uses fewer bits than the unencoded form (the individual images). (I am assuming that the number of bits per pixel is identical in the encoded form as in the unencoded form.)
The title of the thread ("Boundless information storage in limited space") is also a physical impossibility. Limitless information cannot be encoded using finitely many bits; you are limited to the amount of different representations that could be encoded using those bits. Supposing that it were actually possible to store "limitless information" in finitely many bits, this would imply that some of the representations are equivalent. In turn this means that you're not really storing limitless information at all since you are constrained to the number of possible bit patterns, a contradiction.
Assuming you're serious:
a) Does it work? Can you take 100 random bitmaps of the same size, process them in and get the same bitmaps out?
b) If so, could you send just your 1 saved super-bitmap and your extraction program to someone else and they would also be able to extract the 100 bitmaps? Or is there some kind of adjunct information saved that you're not figuring into this process?
c) One single executable to 'compress' them and one single executable to 'extract' them? Or does the program change? How big is the program?
What you're describing is impossible. I'm just trying to suggest some of the ways that you may have tricked yourself. I would suggest starting with a) i.e. does it really work. If it does, then think about what would actually have to be delivered to another computer to extract your 'n' bitmaps and figure out how big that is compared to your original n bitmaps.
a) Does it work? Can you take 100 random bitmaps of the same size, process them in and get the same bitmaps out?
b) If so, could you send just your 1 saved super-bitmap and your extraction program to someone else and they would also be able to extract the 100 bitmaps? Or is there some kind of adjunct information saved that you're not figuring into this process?
c) One single executable to 'compress' them and one single executable to 'extract' them? Or does the program change? How big is the program?
What you're describing is impossible. I'm just trying to suggest some of the ways that you may have tricked yourself. I would suggest starting with a) i.e. does it really work. If it does, then think about what would actually have to be delivered to another computer to extract your 'n' bitmaps and figure out how big that is compared to your original n bitmaps.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
