lossy simplifier of a png bmp jpg

[toi007]

it has to be all decompressed to the same directory
scanline.exe simplifies lossing information to a file called simple.bmp
it can be recostructed by calling the simple.bmp in the scanline.exe ( remade.bmp will apear)
theres english instructions there
if you think this is as good as jpg think again its far off worst
but the simple.bmp can be compressed to levels of 200kb in a 1024x768 image (by the way size fixed image to 1024x76 sorry
you can select the file
the compression rate (0-255) dont go further than 32
the bits from 8 to 1 dont go lower than 4
and a preview first
then confirmation to compress
the link http://www.atelierpt.com/pngcompress...ompression.zip

[Matt Mahoney]

Just to clarify what this is. It is a lossy transform for improving lossless image compression. The GUI program "scanline" asks for an input file, a number of bits (1- and a compression rate. Then it displays the image and slowly (about a minute, it is written in Blitz Basic) transforms it by discarding the low bits you didn't ask for. Also, if the difference from the previous pixel to the left is not greater than the compression rate in all 3 colors, it replaces the pixel with a copy of the previous one, as it will appear when the image is restored. It then asks to proceed with the compression or select new parameters if the quality is not acceptable. If you answer Y, then it compresses (again, about a minute) by setting all but the first pixel in each run to 0. It transforms .png to .simple.bmp, which is ready to compress. If you enter a .simple.bmp file, then it inverts the transform to a .remade.bmp file. It only works on 1024 x 768 images. There are 10 included. There is also the source (scanline.bb) and Windows executable and a copy of zpaq and config files to compress the .bmp file using "zpaq -mbmp_j4 c sample001.simple.bmp".

For comparison, I did some experiments with sample009.png (a mountain scene) and compared with jpeg after converting to 24 bit .bmp first with Windows Paint. For the scanline program, I used the suggested bits=5 and rate=16, and then compressed the original, transformed, and restored .bmp with zpaq using the bmp_j4.cfg model written by Jan Ondrus. As you can see, both the lossy and lossless parts of the transform improved compression. However, there are noticeable artifacts in the restored image like streaks and contour lines. These can be reduced by using more bits and a lower rate, but the compression is not as good.

For comparison I converted to JPEG using cjpeg from the original IJG reference with -quality 40 through 90 and -progressive (indicated by -40p to -90p). The lower quality settings also produce noticeable (but different) artifacts like blocks and ringing around edges. However, JPEG files are much smaller. I also tested the JPEG compression using "zpaq -mjpg_test2" (also by Jan Ondrus) to show further compression. The model only works on baseline, not progressive so I only tested for -q50 and -q90. By itself, progressive mode produces smaller JPEG files than baseline.

1,472,000 sample009.png
2,359,350 sample009.bmp
1,013,525 sample009.bmp.zpaq
2,359,350 sample009.simple.bmp
  303,274 sample009.simple.bmp.zpaq
2,359,350 sample009.remade.bmp
  842,937 sample009.remade.bmp.zpaq

   93,946 sample009-q40p.jpg
  111,276 sample009-q50.jpg
   97,706 sample009-q50.jpg.zpaq
  107,833 sample009-q50p.jpg
  121,874 sample009-q60p.jpg
  145,537 sample009-q70p.jpg
  185,893 sample009-q80p.jpg
  314,402 sample009-q90.jpg
  261,181 sample009-q90.jpg.zpaq
  282,991 sample009-q90p.jpg

[Shelwien]

If its lossy, maybe it makes sense to also compute some metrics?
Like http://cbloom.com/exe/imdiff.zip

[Matt Mahoney]

After I found libpng12.dll so I could run imdiff, here are some results. I ran it with each of the 9 image comparison methods -0 through -8. For each one, I compared sample009.bmp with 11 files: jpeg with quality 10 through 90, a copy of the original file (imdiff = 0), and sample009.remade.bmp as before with bits=5, rate=16. I made each jpeg file using "cjpeg -quality 10 -progressive" (or 20..90) and converted back using "djpeg -bmp". As you can see, the image quality of scanline bits=5, rate=16 is close to 40 using method RMSE_RGB and around 10 to 20 for the other measures.

Compressed file sizes:
    35,251 sample009-q10p.jpg
    59,561 sample009-q20p.jpg
    78,400 sample009-q30p.jpg
    93,946 sample009-q40p.jpg
   107,833 sample009-q50p.jpg
   121,874 sample009-q60p.jpg
   145,537 sample009-q70p.jpg
   185,893 sample009-q80p.jpg
   282,991 sample009-q90p.jpg
 1,013,525 sample009.bmp.zpaq
   303,274 sample009.simple.bmp.zpaq

RMSE_RGB
29.295 cjpeg -quality 10 -progressive | djpeg -bmp
23.815 -quality 20
21.411 -quality 30
19.952 -quality 40
18.839 -quality 50
17.703 -quality 60
16.255 -quality 70
14.253 -quality 80
11.306 -quality 90
0.000  exact copy
20.662 scanline bits=5 rate=16

SCIELAB_RMSE
21.335
13.941 -quality 20
11.321
9.839
8.998
8.207
7.358
6.238
4.777
0.000
16.266 scanline

SCIELAB_MyDelta
19.664
10.173 -quality 20
7.369
5.905
5.098
4.449
3.735
2.900
1.930
0.000
11.726 scanline

MS_SSIM_Y
0.956 -quality 10
0.980
0.988
0.991
0.993
0.994
0.995
0.997
0.999
1.000 exact copy
0.966 scanline

MS_SSIM_IW_Y
0.965 -quality 10
0.985
0.990
0.993
0.994
0.996
0.997
0.998
0.999
1.000 exact copy
0.969 scanline

PSNRHVSM_Y
1086.066 -quality 10
297.490
132.047
75.814
46.907
30.974
17.693
7.856
1.761
0.000
1480.543 scanline

MyDctDelta_Y
28.638 -quality 10
12.954
8.720
6.911
5.800
4.985
4.030
2.933
1.669
0.000
43.079 scanline

MyDctDelta_YUV
76.731 -quality 10
43.593
32.239
26.368
22.343
19.096
15.226
10.911
6.243
0.000
84.226 scanline

Combo
5.063 -quality 10
4.279
3.917
3.694
3.528
3.377
3.173
2.892
2.453
0.000
5.043 scanline

[Shelwien]

Thanks, I suppose SSIM should be more relevant there though.
And I guess it means that jpeg is still better than this kind of lossy transformation.

[Matt Mahoney]

Image quality is a very subjective thing. For example, you could record more data where people look, such as faces, and less of the background. I recall a product for compressing ID badges that did just that. But I don't think there is a good way to measure quality this way.

JPEG is based on studies of low level perception. The eye is most sensitive to spatial frequencies of 0.5 to 1 degree in brightness, and much less sensitive to high frequencies in color. Thus, it transforms RGB to YUV, then throws away most of the UV. In http://mattmahoney.net/dc/dce.html#Section_615 I show how the different components contribute to the image. Notice in the last picture where all of the AC components of UV are discarded and the picture hardly looks any different.

I think there are ways to do much better, but it would require more intelligent understanding of what is in the picture.

[Karhunen]

I use a tool called "gbmtools"' that quantizes truecolor to palleted files with its "gbmpal" utility. I like it because it reminds me of an old color TV I had that had side by side RGB pixels and produced a "slit-like" dispersion effect. GBM does a similar thing, but the pixels are on a diagonal:
This of course, is Matt's avatar pic converted by gbmpal -m tripel matt_original.png matt_pallete.png

Oh yeah, back in the day especially on BBS systems, there was a "giflite" utility that would color average areas or mosaic them for better LZW compression.

[toi007]

I made some better improvements now it uses de quantitization method
http://www.jpg2bmp.com/YUV/YUV.zip
and theres instructions
let me tell you its not totally worst than jpg similar quantitization values give similar Kb but without Discrete cosene transform the quality of image its a bit blurry
use values of y=10 to y=20
use values of U and V of 20 to 60