0

I have come across a problem that I would ideally like to solve where I would like to add two (problem involves 24-bit but for ease of demonstration 8-bit is fine) numbers together - simple enough, they don't even need to be strictly added, an XOR would be fine. However, I would like this to be reversible, I know you can use an XOR cipher to add a known number to the original and be able to decode it again, but I would like to do something similar but with 2 starting numbers rather than a single one.

Truncating to 8-bit numbers for ease of demonstrating:

I would like to have 10010100 added to 10110110 for instance. I would then like to be able to extract 10010100 from the resulting number to get 10110110 again. I would add n 8-bit numbers, transmit the resultant number and then decode back to n 8-bit numbers + the original number. The transmitted number can be as large as it needs to be, although the smaller the better. I am flexible on how to achieve this, either in hardware or in software. Is this possible? Hopefully I have included sufficient information.

Thanks in advance

Sparky366
  • 1
  • 2
  • 1
    You need to clarify that a little bit more. The way it is it seens you want to extract n 8 bit numbers from a single transmitted 8 bit block - which is of course, impossible. – jsbueno Jul 24 '16 at 17:18
  • Sorry, should have expanded that bit a little more. Each time a new number is added it will add to the original number. I will do this n times. It will then be transmitted and I then want to decode the transmitted number to extract the n 8-bit numbers. The transmitted number can be as large as it needs to be. – Sparky366 Jul 24 '16 at 17:27
  • So just append them, why even do any funny transformation? – harold Jul 24 '16 at 19:31
  • How would I go about decoding them unless I ended up with a string that was n-bytes long? – Sparky366 Jul 24 '16 at 22:07
  • Of course if you append n bytes together, you get, well, n bytes. Really nothing changes if you append bytes. It's an imaginary operation. Seriously this whole problem is weird, if you need to transmit n bytes why don't you just do exactly that? – harold Jul 24 '16 at 22:24
  • I would like to transmit as little data as possible. Ideally filling every 24-bits (16,777,215) with a meaningful number into a 32-bit number. Thus the head scratching. – Sparky366 Jul 24 '16 at 22:43
  • Ah you're doing this for compression. What sort of data is expected? Mainly low values or anything useful like that? – harold Jul 24 '16 at 22:55
  • Precisely that. Each value will be 8-bit RGB colours (thus the 24-bit number) and I want to squeeze 256 of these into a 32-bit value if that's possible? I would be happy to transmit the 32-bit number multiple times coding the colours slightly differently if it meant I would be able to extract them at the end. – Sparky366 Jul 24 '16 at 23:02
  • These expectations of achievable compression ratios (256 24-bit pixels compressed into a single 32-bit number) don't seem realistic to me. Your data needs to have a lot of redundancy to be able to compress well, and you will need to decide whether you want lossy or lossless compression. If there is a lot of temporal or spacial locality in this color data, you may want to look into a simple scheme like run-length encoding or delta encoding. – njuffa Jul 24 '16 at 23:11
  • Thanks will have a look into these. – Sparky366 Jul 25 '16 at 10:34

0 Answers0