Jump to content

What do you think of this idea?

- - - - -

This topic has been archived. This means that you cannot reply to this topic.
2 replies to this topic

#1
NeximusF

NeximusF

    Newbie

  • Members
  • Pip
  • 2 posts
Intermediate c++ programmer here, native. Anyway, as this is going to be coded in C++ I thought I'd put the idea here.

Anyway, I have been working on new ways to compress and encrypt files as to be more efficient than most compression methods, and I came upon the idea of converting data into colors. At the moment I am only using grayscale, as it has proven to be almost completely lossless between image types, though I may expand to complete RGB in time(Theory of RGB explained into the description).

After much trial and error I have came up with a theory that sticks to my goal perfectly, but would like opinions on it. I will not express every detail of the idea, but give a general image of what it will be.

In each image there will be 100 shades of gray, ranging from clean white, to absolute black. These colors are used to represent numbers in blocks of four, which in turn represent a wide character, or a sequence of characters in general. In the compressed image there are 'blocks' of data in 64x64, or 128x128 sized squares, each filled with the prementioned 2x2 blocks representing a character.

Now, a short description of the smaller blocks representing characters. The two upperhand 'dots' (I will use this as no better term stands out), will represent two numbers multiplied by eachother which equals, or near equals the number that represents the character, used widely in coding (e.g '0' is a space, '6' is a letter that I am too lazy to look up). The first dot on the lower part of the block is an addition factor, in case the multiplication is unable to react the exact number. The next dot is one of the better features. If the pattern is repeated in the data after it, the dot specifies how many times it is repeated in the form of a number, up to 100.

After the larger blocks are filled to their maximum capacity, for grayscale compression, it ends there. If I were to use RGB, which I am not so sure of, each three blocks would be changed to colors on the red/green/blue scale, depending on the grayscale color. After this is done, each set of three blocks would be merged together, retaining their depth number. The decompressor would parse each color accordingly.

That being the end of the process, I would like to know what you guys think? I have thought of many uses for the new compression method, but will not ramble on about them here.

#2
WingedPanther

WingedPanther

    A spammer's worst nightmare

  • Moderators
  • 16,831 posts
I think your idea has numerous problems, though you are correct that any method you can use to compress grayscale can be used on each of the RGB components.

Issue 1) when dealing with images, you have 256 shades of gray, not 100. If you reduce it to 100, you are immediately dealing with lossy compression.

Issue 2) it's not clear that you've done anything different from other compression techniques.

As it stands now, without a more precise description, or an example, it's hard to see whether you have come up with anything useful or effective. Also, if you feel that this method is truly an improvement, it would be useful to demonstrate how effective it is on various samples when compared with various other compression methods, such as those used by gzip, winzip, and 7zip.
Programming is a branch of mathematics.
My CodeCall Blog | My Personal Blog

#3
NeximusF

NeximusF

    Newbie

  • Members
  • Pip
  • 2 posts
I could use all 256, but until I see the effects of different image compressions, I will use 100. Will post an example soon. Coding up a storm.