JPEG Simulator (E2)

[Syranide]

Awesome, I just noticed a few "improvements" you can do to your code.

[array():clone()] => [array()], no need to clone an empty array
[print("A" + toString(B) + "C")] => "print("A" + B + "C")], string concatenation support numbers

    if(C9<Res) { SumK+=IDCT1:number(Base1+C9)*cosr(pi()*C9*(KX+0.5)/Res), C9++ }
    if(C9<Res) { SumK+=IDCT1:number(Base1+C9)*cosr(pi()*C9*(KX+0.5)/Res), C9++ }
    if(C9<Res) { SumK+=IDCT1:number(Base1+C9)*cosr(pi()*C9*(KX+0.5)/Res), C9++ }
    if(C9<Res) { SumK+=IDCT1:number(Base1+C9)*cosr(pi()*C9*(KX+0.5)/Res), C9++ }

You could just multiply by "min(4, Res - C9)" instead (same for all others). unless I'm mistaken.


But I'm quite amazed by the complexity of the code

[Black Phoenix]

I wonder if CPU version will be any faster

[ningaglio]

can someone tell me where to split the code into 4(the 512*512 image)

thx in advance

o and btw i tryed to do 128*128 and did the same resolution on the digi screen, and only got a part of the image.

btw nice programe

[Josef]

This third example is pretty similar to the compressor a few posts ago but it includes a second expression that receives and decompresses the data back into the original image. The transfer between the two chips happens through a single regular wire, which is the red wire in this demo. Apart from this wire, each board is a separate contraption. I now consider this to be a full working demonstration.

A breakdown on its speed:

Using the largest example of a 512x512 greyscale image at quality level 50, capturing the 262,144 pixels using this overclocked E2 ranger camera takes around 90 seconds (a little more with AA turned on). Using a single plain old external ranger (they take 22 readings per second) would take over 10,000 seconds (3+ hours) to accomplish the same thing. 90 seconds is still enormously long for a picture though, so don't expect to capture anything in motion at this size

The compression and decompression steps for this image size are around 100 and 95 seconds each. This is almost in line with the image capture time because the most intensive step (DCT/inverse DCT) at default blocksize will process 1 pixel per execution, the same as the ranger camera produces.

Even though WireLink would be faster for the transfer between the two chips, I chose the classic wire to see how far it could be pushed. Using the vector mathemagic I mentioned in my earlier post allows for a transfer speed of 2400 bytes per second, or 19.2kbps, so the example 512x512 image compressed at a quality of 50 (~11,000 bytes) takes roughly 5 seconds to transfer. Compare this with sending one byte at a time over one wire at the standard tickrate, which would take 165 seconds, or the same image that's sent uncompressed pixel-by-pixel at 3932 seconds, or 1.1 hours!

Bugs:

As expected, there were a few bugs with the previous compressor that couldn't be discovered until I had built the suitable decompressor. Most notably, after a ton of backtracking I traced some sporadic image corruption to a floating point number problem in rounding the base 2 logarithm function :censored:. On certain exact powers of 2, using log2() will return what appears to be a whole number, but flooring the result will give you one number less. For example, log2(8) = 3 but floor(log2(8)) = 2. The solution was to fudge the log2 calculation by just enough (0.000001) to fix these cases and not introduce additional errors.

There is still a bug where when using the highest resolution (512) and the highest quality (100) it will occasionally produce an error in the decoder. This is likely due to the unique combination of large integer bit length and large Huffman code length preceding it which overflows the 24-bit "train" I used to create the byte stream. I don't plan on fixing this, so try moving the camera around slightly or lower the settings instead .

Awesome, I just noticed a few "improvements" you can do to your code.

[array():clone()] => [array()], no need to clone an empty array
[print("A" + toString(B) + "C")] => "print("A" + B + "C")], string concatenation support numbers

    if(C9<Res) { SumK+=IDCT1:number(Base1+C9)*cosr(pi()*C9*(KX+0.5)/Res), C9++ }
    if(C9<Res) { SumK+=IDCT1:number(Base1+C9)*cosr(pi()*C9*(KX+0.5)/Res), C9++ }
    if(C9<Res) { SumK+=IDCT1:number(Base1+C9)*cosr(pi()*C9*(KX+0.5)/Res), C9++ }
    if(C9<Res) { SumK+=IDCT1:number(Base1+C9)*cosr(pi()*C9*(KX+0.5)/Res), C9++ }

You could just multiply by "min(4, Res - C9)" instead (same for all others). unless I'm mistaken.

But I'm quite amazed by the complexity of the code

D'oh! Thanks, I have shortened my string and array lines accordingly :winkiss:. I don't think replacing the If condition would work quite that way though. However, these repetitive areas can definitely be shortened down with the soon-to-be-implemented while-loops. Performance quotas will surely be a problem though, since with full simulation options turned on, the compressor does 60,000 ops/tick. With all intermediate display options turned off, the compressing/decompressing stages still max out at around 34000 and 40000 ops/tick. :lol:

can someone tell me where to split the code into 4(the 512*512 image)

thx in advance

o and btw i tryed to do 128*128 and did the same resolution on the digi screen, and only got a part of the image.

btw nice programe

Digital screens can be up to 512x512 each, so I'm not quite sure what you mean, but try this latest file and see if you're not still having the same problem. This example lets you set the screen resolution outside of the expression with a constant value.

How to use it:

Spawn the "jpeg full sim" adv. dupe
Edit the screen size with the constant value
Press the +/- keys to adjust the quality (+100 to -150).
Press 1 to toggle AA
Press 2 to toggle showing the intermediate DCT image on both sides (lags a bit)
Press 3 to toggle simulating the final compressed image on the first board (no longer necessary, and lags even more)
Press 0 to take a picture of yourself
Press Enter to compress it and transmit it to the receiver chip where it will decompress automatically
Press period (.) to reset the expression and screens in case something breaks.

One extra note: You do not have to recapture an image when changing the quality setting, only when changing resolution. Just change quality and hit Enter to recompress and see the difference.

The additional files ("jpeg compressor" and "jpeg receiver") are the expressions themselves.

[Syranide]

D'oh! Thanks, I have shortened my string and array lines accordingly :winkiss:. I don't think replacing the If condition would work quite that way though. However, these repetitive areas can definitely be shortened down with the sooon-to-be-implemented while-loops. Performance quotas will surely be a problem though, since with full simulation options turned on, the compressor does 60,000 ops/tick. With all intermediate display options turned off, the compressing/decompressing stages still max out at around 34000 and 40000 ops/tick. :lol:

They will not affect singleplayer, and I assume you haven't been hogging any server with that ^_^. Also, you will be able to keep it going at full speed (as in max quota) using some commands that are bundled, but of course, it will not be nearly as fast.

[sharonk868]

Edit: A newer version with full compression/decompression capability can be found later in this thread, here.


Warning: If you're not a math geek, this will probably not interest you!

.

Such a very amazing link!
Thanks you for the post.