Sign in to follow this  

Boundless information storage in limited space [didn't work]

This topic is 4022 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have written a program that is able to store N bitmaps (size AxB pixels) into just one bitmap of the same size (AxB). A complementary program is written that interprets this bitmap, and has the ability to retrieve all N original bitmaps. This way, a very large number of bitmaps can be stored into just one bitmap. (provided they are the same dimensions*, for now.) * meaning AxB is the same for every bitmap stored The program is not necessarily limited to just storing bitmaps. It could also be used for scripts, facts, or whatever information. The goal is just to store a lot of information in small space. The required time to interpret a 'bundled' file does increase with amount of data stored in this file, but I believe my algorithms can interpret the 'bundled' file relatively fast. And although the time to read such a file is larger than that of reading the original files, this algorithm can still be usefull in applications where reading time is not as important as file size. One application I can think of is that of making install files, which can now be smaller in size. Another application would be to store a movie into just one movie frame (= one bitmap). (Note that this is NOT a compression algorithm, but an alternate, small way to store multiple objects into one. These files themselves may be compressed before they are combined.) I was wondering if there are any known techniques that address the same issue, and just your thoughts about the usefullness of such an algorithm. [Edited by - Subotron on December 13, 2006 11:33:01 PM]

Share this post


Link to post
Share on other sites
What is the algorithm, exactly? What is the value of N, A, and B? Could you post the combination of two 128x128 images along with the original images, for example?

Share this post


Link to post
Share on other sites
I would be very, very careful and double and triple check your results before claiming such a thing. Several claims like these have been made before. None of them have proven accurate. You've either managed something so amazing that you ought to run out and get a patent now because it will make you billions, or else you've made a simple mistake. Excuse my scepticism, but based on previous results I'm going with the latter.

Σnigma

Share this post


Link to post
Share on other sites
Quote:
Original post by Subotron
Another application would be to store a movie into just one movie frame (= one bitmap).

(Note that this is NOT a compression algorithm, but an alternate, small way to store multiple objects into one. These files themselves may be compressed before they are combined.)


Wait, so you are claiming you can store a full length movie and store it as just a single frame ("able to store N bitmaps (size AxB pixels) into just one bitmap of the same size (AxB). ") and you are saying it's not a compression algorithm? That's possibly THE best compression algorithm EVAR! I call shens.

Share this post


Link to post
Share on other sites
Why stop there? If you can fit an entire movie into one frame, you could fit an entire frame into one pixel. If you set A and B to 1, and your pixels have K bits, then you can store N K-bit numbers in one K-bit value. If you set K to 1, then you can store a string of N binary digits in one bit.

(I kind of suspect N has to be 1.)

Share this post


Link to post
Share on other sites
Quote:
Original post by Enigma
I would be very, very careful and double and triple check your results before claiming such a thing.


Actually, I find his claim quite muddled and difficult to understand. For all we know, he might just be claiming to use steganography...

Share this post


Link to post
Share on other sites
thank you for all your replies. Indeed, I could be making a mistake. But I will be spending a lot of time to figure this out. Please don't interpret the first post as a claim that I have found the holy grail, but lets just say I have a suspicion. I was just wondering if (IF this works) this was something that had the huge impact you guys talk about.

But well, I'm probably overseeing something, since you guys say this hasn't been done before. I will keep you informed of the progression.

Share this post


Link to post
Share on other sites
If there are no contraints on the values of N, A and B then what you suggest is impossible. As has already been mentioned you could get a A x B bitmap and turn it into A * B 1 pixel bitmaps and then combine them into a single 1 pixel bitmap. Thus you could get any arbitrary sized file and turn into a single 1 pixel bitmap. That pixel will occupy n bits of storage (if the pixel is a single bit n will 1 if it's 3 bytes n will be 24 etc). That gives 2^n distinct values for the pixel and the number of different files in the universe is greater than 2^n thus you cannot compress any arbitrary sized file to a single 1 pixel bitmap which means your method cannot work (if it appears to work there's probably contraints on N, A and B that you haven't seen).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!)

Share this post


Link to post
Share on other sites
I think the confusion in this thread stems from either poor wording on the OP's part, or a misunderstanding of what "compression" means:

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Mithrandir
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.

That's why I wrote encode instead of append. I could use two characters to represent one byte.

Share this post


Link to post
Share on other sites
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 :)
There's a 256-byte demo (whose name I don't remember) that uses this trick to decode a 320x200 image from the filenames of thousands of 0-sized files.

Share this post


Link to post
Share on other sites
Quote:
Original post by klajerhgkja
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 :)
There's a 256-byte demo (whose name I don't remember) that uses this trick to decode a 320x200 image from the filenames of thousands of 0-sized files.



Isn't this cheating though? I mean, the filenames have to be stored on the disk someplace...

Share this post


Link to post
Share on other sites
and like all you people had already guessed, I overlooked certain constraints that will bring my claim down to almost zero: all that is left is just another compression algorithm. Turns out I overlooked some possibilities, and once again I am bound to the possibility of storing a max of 2^N different patterns in N bits. The algorithm can still compress a lot of files to a reasonable extend, but in no way as much as I was claiming in the original post (which, I still like to say, wasn't really compression, but since it's also proven to be fiction there's no use for THAT discussion :))

Thanks a lot for your thoughts and help!

Share this post


Link to post
Share on other sites

This topic is 4022 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this