LoginLogin

My image compression/decompression is not working properly

Root / Programming Questions / [.]

PerskaCreated:
Perska#1
So while I were writing a image player, I had to compress images so they wouldn't be so slow loading. However, the displayed image is not the same as before (well, expect from the colors changing to 8-bit). The whole image is messed up. I don't know if it's the compressing or the decompressing. So if anyone can help, then it would be appreciated! I have a public key for a project containing the compressor and the viewer. Also, there is a test image there too. Public Key: XDNY3QJ EDIT: Run the 320X240TO8-BIT first, then run 8-BITTO320X240. EDIT2: It's working now. Though if someone can optimize this it would be really appreciated! (it's slower than loading GRPs normally) Also there is a 512x512 one too. That one takes REALLY LONG. BTW, I have included precompressed images too so you don't have to experience a long wait.
12Me21#2
WHY ARE YOU USING RRRGGBBB?!?!? Integers are 16 bits...
Perska#3
Integers are 16 bits...
Wait what really? An edit: Err 16-bit integers can be 65535, while 32-bit integers 4294967295 (unsigned though).
12Me21#4
yeah nevermind
Perska#5
So I think I figured out why it's happening: the values being read are high: for example, when the color red is being ANDed, it gets a rather big number. I don't know how to fix this without making reading slower right now, but I'll mess with some stuff to see if it helps
snail_#6
pfshhhhh Integers are signed two's-compliment 32-bit (-2147483648 to 2147483647, whole numbers only, % suffix). A 32-bit color-code pulled from a GRP is in the hex format &HAARRGGBB. Keep in mind that the 32-bit codes are simply a level of abstraction: GRP in reality works in 16-bit &BRRRRRGGGGGBBBBBA color.
snail_#7
I optimized it a fair bit. Key: 73KKXPDX Images not included. For the decompressor:
  • Multiplies were replaced with left-shifts
  • I%*4 was stored to a variable T% so you don't have to do it 4 times
  • LOAD[I%,J%] was assigned to a variable C% because array access times are slower than variables
  • The R%, G%, and B% arrays were replaced with individual variables (see above)
These were all minor changes. I didn't change the algorithm at all. For the compressor:
  • Same changes as above where applicable
  • Instead of using string operations, only left-shift and OR were used to concatenate the pixel values
  • Instead of using the array NEW$, a single int C% was used as the intermediary
Things got very much faster on this end. Here's a math tip: for all non-negative numbers less than 1073741824, left-shifting by n bits is equivalent to multiplying by 2n. Similarly, right-shifting by n bits is equivalent to integer-dividing by 2n. In the case of right-shifting, the operation will work on all numbers (due to the sign fill), with one caveat: shifting negative numbers will never fall below -1. Bit shifts seem to be faster than multiplies, so this helps out in a pinch. EDIT: Bitwise operations (shifts, AND OR XOR) only work on integers. Reals passed to them are clamped to integers.