JF make 24
JF Nav
JF Nav
Creation Date: 2002-01-18
So, what's this mess? This mess is a lesson waiting to happen. You've seen this background before, but you won't recognize it unless you decompress it, delete the first 54 characters, and rename the output BMP to PNG. I'm going to teach people here a little bit about data compression theory. Using my AltSci Any2Img program, I turned a png file into a bitmap. Then I recompressed it. Why isn't it a lot smaller than the original? I did compress it twice instead of once. Well, that's because of the definition of compression. If you could compress something n number of times and get a smaller each time, the limit as you take n to infinity, the compressed file becomes zero size. Then you have a program that can create information out of nothing. But that's nothing new. The damascus blade came out of "nothing". A program that inputs three numbers and outputs a picture. I could make a program out of that program that inputs nothing and outputs the damascus blade. Of course, it'd output the damascus blade every time unless I hooked it up to some random or some factor driven function (which would be data, I might add). So, where was I? Ah, yes, the compressed file. The double compressed picture looks pretty random, right? Well, a good compression outputs a very random compressed file. In fact, a perfect compression program would output perfectly random information. That is perfect as defined that it would compress to the smallest size possible. But perfectly random is hard to define. What is perfect randomness? Random is something that not only cannot be defined by a person with a ruler, but is theoretically impossible to be defined. Pretty strong words. What is an example? Well, the exact position of an atom is pretty random. With Heisenberg's Uncertainty principle, it is impossible to know the position exactly because it would take an infinite amount of energy. Without going further into Quantum Mechanics than we need to, I'll just tell you that we can only know the position of an atom to a certain degree and that degree is based on the energy that your laser fires at it. But there are better ways to get random numbers than pushing around atoms with a laser.

But two things are staring me right in the face in this crazy problem. The first is that the original picture can be defined with vector graphics and anti-aliasing constants. With the compressor/decompressor Corel Draw, this picture can be recreated with MUCH less data than the PNG takes. That means that the PNG is not as good at compression as Corel Draw for certain images. That means that the randomness seen in this picture is not very random at all. In fact, it's awful. Even the Corel Draw isn't very good. Why, because I can use WinImp to compress the gogrrl.cdr file that this came from to get a much smaller file. Oh my, the rabbit hole goes deeper. In fact, we don't need WinImp. I can make a program that compresses cdr files better than WinImp can. I could transmit this file with a couple bytes. If I made a really good compressor, I could send a few compressed bytes and you'd get a seriously complex vector graphic. Wow, what a wonderful idea. And it'd work if there weren't data theory.

But then there's this data theory. It says that the more you compress, the less you're able to do. So, if I make my wonderful compressor and I convince everyone to use it, we'd eventually run out of unique ideas. ;-; I hate running out of unique ideas. Here's the beef: my wonderful compressor allows me to send you two bytes "A#" and it displays a wonderful picture, two girls and Jav drinking mochas and tea. You probably know that each byte has 8 bits and there are 2^8 possible combinations of a byte, right? Of course. So there's 2^16 combinations of a pair of bytes. My next picture might be "3u" with Jav and his brother listening to music. After I've drawn 65536 pictures, I will have to use an extra bit for the next two pictures. For the next four pictures, I'd need to add 1 more bit. And so it goes, this game called data theory. So my perfect compressor isn't that bad, is it? It's actually quite nice. I guess the problem is that this compressor/decompressor is quite a ways from the boundaries of our compressive technology. In fact, the decompressor would take at least as much space as the cdrs if I did it that way.

A better way would be for me to make a program that compresses cdrs well and a client program that decompresses them and displays them. That'd be just about the best deal for everyone involved. The decompressor is easily within the limits of technology. The compression scheme could just be zlib (the same used for PNG) or WinImp. Then a vector graphic like this one would only take 11 kb. The vector graphics program would take about 50 kb if I wrote it (plus Visual Basic runtimes if I wrote it in VB). I think that's a pretty realistic idea. However (there's always a however ;_;), the simple fact that it isn't popular enough, it would turn away visitors. But if Javantea.com became huge and I got a bunch of artists working with me, and there was a vector art revolution, it would be significantly popular enough for people to download it. The bandwidth savings would be nice, right?

When did these thoughts arrive in my head that Javantea.com is going to become huge and I'm going to get a bunch of artists working with me? Well, it's always been one of those thoughts that it'd be cool to work together on my ideas as well as other people's ideas that are similar to mine. I've recently thought that making an actual web manga would be cool. It seems like a waste of paper for all the mangas to be in paper, when most of the readers and writers are very computer savvy. Of course, a lot can be said about digitization, but mangas are digitized in the end to be printed, right? But then there's compression. Paper is a decent medium of compression. There's a lot of data that can be stored in atoms. Of course, the printer only prints at 300 dots per inch (~12000 dots per meter), right? That means that it's not even close to the compression of PNG on a hard drive. However, people seem to like it. For delivery, it seems to get the job done. The bandwidth (trucks and boats) is quite large in bursts. I'm interesting in making or extending a vector format that is perfect for a manga. Then we can see about web mangas using little bandwidth. It'd use text, bezier curves, fill, patterns, points, outline, pen tip pressure, compression, compressed bitmaps, and 3d (I like this idea! That's what AltSci3D MD and MP's end goal will be), and a few things I'm forgetting. Until then, PNG compression is fine. PNG is cool because you can use any amount of bits to describe your image. 1 bit is one of my favorites. 1 bit is black and white. Line Art, diffusion, and value can be used to turn a picture into 1 bit. Diffusion is often seen in mangas. Those dots? Yup, diffusion in the form of screentones. Line art can be found in my favorite procedural sword.

E-mail me to talk about helping me with manga.

I have a hypothesis on data compression theory. Ooh, check this out, you trolls who like to destroy young thinker's dreams, your perfect chance is here. If someone were to give me a "random" file that had the exact bit for bit combination of the background of my picture, I could compress it by means of taking my cdr exporting it to BMP, anti-aliasing it and creating a PNG of it. That is not a hypothesis, it's a fact. My hypothesis is that a vector graphic can be made for any "random" data. In fact, it doesn't have to be a vector graphic, it could just be a relatively simple mathematical formula (Corel Draw runs fast on a simple computer). Thus, higher compression than that has ever been seen (leaving Divx, JPG, and PNG in the dust) could be made using this simple principle. I don't have the program to back up my claim, so it remains a hypothesis. However, I won't be surprised if I see it in the next few years.
Home Characters Making Of Technical Mail News Links |< First < Prev Next > Latest >|  bandwidth version Goto Scene