A JPEG image, if it is non-progrssive loads from top-to-bottom, and not from left-to-right or any other manner.
Doesn't that imply that jpeg uses some row-wise compression technique? Does it (use a row-wise compression technique)?
No, it doesn't. JPEG mainly constitutes the use of chroma channel subsampling, a discrete cosine transform (DCT) and some non-lossy compression such as run-length encoding. The image is divided into blocks, usually 8x8 pixels, and then transformed into a frequency domain representation via DCT. In a non-progressive JPEG, these blocks would be stored left to right, top to bottom. With a progressive JPEG, the lower frequency components will be stored before the higher ones, allowing a low-resolution preview be viewed before the whole image has been transmitted.
As you can rotate a JPEG by 90 degrees quick and lossless I think it's not row-major compression. It's just that the compressed blocks are stored in some order and that happens to be row by row.
Related
According to this site
BMP (Bitmap) is a uncompressed raster graphics image format
1) So does it mean that, BMP doesn't follow compression while image storing at all ?
2) If it does follow compression then it should be called lossy ? But it's lossless why so ?
Also when it is said,
Lossless means that the image is made smaller, but at no detriment to
the quality
3) If the image is made smaller then how can it remain the same.Making it smaller means that it has to follow some compression right?
Edit:
4) JPEG is also a bitmap format then why is it not lossless ?
First, BMP does not allow image compression at all, pixel values are written as is, no compression or size reduction transformation is used. It's uncompressed, so it's not lossy, it's lossless. It is actually possible to compress images (and also audio) in a lossless manner, that is, mathematical operations are performed on the data that remove redundant data, thus decreasing the overall size, since these operations are invertible they are also able to recover the original data (image, audio, etc...). Technically, a bitmap is a 2 dimensional array of pixel values, but a bitmap is widely known as the uncompressed .bmp image format. Compression has two variants, lossy compression, where you drop some portion of your data that can't be recovered, hence lossy; and lossless, where you drop portions of your data that can be recovered by the inverse process. A full treatment on the subject inevitably has to deal with information theory and Shannon's result on coding theory. A simple place to start is with run-length enconding and Lempel-Ziv compression algorithm for lossless compression, and JPEG compression using wavelets for lossy compression.
I used Microsoft Paint to create a 15248 x 6552 solid color picture. I saved it as both .png and .jpg and was expecting the .jpg to be smaller than .png, but it was not.
The .jpg file is 1.49MB, while the .png is 391KB. Shouldnt jpeg being a lossy compression be technically smaller in size?
I read somewhere that .png is better for solid colors etc, so I downloaded a picture form the web (not a solid color) and used paint to save it in both formats. This time the jpeg was smaller than png. Is it solely due to the gradient of colors? if so then why?
Even if the picture is a solid color should jpg encodng be able to compress it even better?
It's to be expected that PNG performs better than JPEG in this scenario.
As pointed out in other answer, PNG does a per-line pixel prediction, followed by ZLIB compression. If the image has a single colour, the prediction will produce a constant zero value for all the pixels, except for the start of each row. Hence the compression will be very effective. I'd bet that if the image were "landscape" (6552 x 15248 instead of 15248 x 6552) the compression would be even a little better.
JPEG compression, instead, divides the image in blocks of 8x8 pixels, and for each one it attempts to quantize finely the low frequency components and coarsely the high frequency components. This works nicely for "natural" (photographic or rendered) images, but no so nicely for images with few colors (or a single one!).
See some comparisons here.
Not necessarily.
PNG is a prediction-based algorithm, which means that it tries to deduct the value of one pixel based on previously coded pixels. I bet the prediction is really accurate for a solid image, thence the very good results.
JPEG accepts different "quality levels" which determine the size of your compressed file. The size differences between your experiment and the web version are likely due to that (unless you're downloading a different image, of course!).
Note that JPEG may introduce some image artifacts because it is a lossy algorithm, while PNG will recover the exact input image for you.
I've found for the same picture that if you save as PNG 1st then JPG the PNG will be smaller and if saved as JPG 1st it will be smaller than the PNG saved afterwards
I am finding the entropy value of an RGB image after histogram processing using the Y plane as follows:
i % the original image
y1=rgb2ycbcr(i);
y=y1(:,:,1);cb=y1(:,:,2);cr=y1(:,:,3);
he1=histeq(y);
r1=cat(3,he1,cb,cr);
r1=ycbcr2rgb(r1);
g1=rgb2gray(r1);
e1=entropy(g1);
Now I followed the procedure:
imwrite(r1,'temp1.jpg');
i2=imread('temp1.jpg');
g2=rgb2gray(i2);
e2=entropy(g2);
But now e1 and e2 are different. Why it is so?
You're writing the image r1 to disk using the JPEG compression standard. JPEG is lossy, which means that what is written to disk is not the same as what was originally stored in memory. Though the images look perceptually the same, if you compared the colour values between corresponding pixels, the majority of them will be slightly different. These slight differences is why the JPEG standard gives high compression ratios and thus smaller file sizes.
If you want to ensure that what you write to file is the same as what you read in, use a lossless compression standard, such as using PNG. As such, change the destination filename so that you're using PNG, not JPEG:
imwrite(r1,'temp1.png'); %// Change
i2=imread('temp1.png'); %// Change
g2=rgb2gray(i2);
e2=entropy(g2);
JPEG is a lossy image compression which can give a high compression ratio.
As far as I know, information loss takes place in JPEG during quantization.
Are there any other steps in JPEG compression where the loss takes place or can take place?
If it takes place, then where?
There are 3 aspects of JPEG compression which affect the quality and accuracy of images:
1) Loss of precision takes place during the quantization stage. Accuracy of the colors is lost in order to reduce the amount of data generated.
2) Errors are introduced during the conversion to/from the RGB/YCC color spaces.
3) Errors are introduced during the transformation to/from the frequency domain. The Discrete Cosine Transform converts pixels into the frequency domain. This conversion incurs errors in both directions.
Another place where loss can take place in JPEG compression is the chroma subsampling stage.
My understanding is that most JPEG-compressed images use 4:2:0 color subsampling: after converting each pixel from RGB to YCbCr, the Cb values for a 2x2 block of pixels are averaged to a single value, and the Cr values for that 2x2 block of pixels are also averaged to a single value.
The JPEG standard also supports 4:4:4 (no downsampling).
I've done a bit of fiddling around with PNGs over the last couple days and I am upset with my findings. I'm concluding that the majority of my results deal with compression. So this weekend I'm going to dive into advanced compression articles. I wanted to share my findings so far. To see if anyone has any advice on achieving my goal and to maybe point me in the right direction.
I am currently working on a project where I need to obtain the smallest possible file size within a window of less than 15 seconds.
The majority of the images I am working with are PNG-8bpp with a full 256 color palette. Most of these images I could represent accurately with 5bpp (32 colors).
PNG indexed however only supports 1,2,4, and 8bpp. So my idea was to strip the PNG format to the minimal information I needed and write an encoder/decoder to support IDAT sections with 3,5,6, or 7bpp.
Test 1:
Original File: 61.5KB, 750 * 500, 8pp Palette, 256 colors, No tRNS
After Optimizations (Reductions to 4bpp, Strip Anx Chunks, & PNGOUT): 49.2KB 4bpp, 16 Colors
Human Interpretation: I can see 6 distinguishable colors.
Since I only need six colors to represent the image I decide to encode the IDAT using 3bpp to give me a max palette of 8 colors. First I uncompressed the IDAT which results in a new file size of 368KB. After applying a 3bpp to IDAT my new uncompressed file size is 274KB. I was off to what seemed to be a good start... Next I applied deflate to my new IDAT section. Result... 59KB.
10KB larger than using 4bpp.
Test 2:
Original File: 102KB, 1000 * 750, 8bpp, 256 Colors, tRNS 1 fully transparent color
After Optimization: 79KB, 8bpp, 193 colors, tRNS 1 full transparent color
Human Interpretation: I need about 24 colors to represent this picture.
24 colors can be represented in 5bpp at 32 colors. Using the same technique above I was able to achieve much better results over uncompressed but again I lost at compression. Final size compressed... 84KB. Then I tried at 6,7bpp... same result poorer compression that at 8bpp.
Just to be sure I saved all the uncompressed images and tried several other compression algorithms... LZMA, BZIP2, PAQ8... same result smaller compression size at 8bpp than at 5,6, or 7bpp AND smaller size at 4bpp than at 3bpp.
Why is this occuring? Can I tweak/modify a compression algorithm to target a PNG like format that uses a 5,6, or 7bpp format that beast 8bpp compression? Is it worth the time... and yes saving another 10KB would be worth it.
What you're seeing is that by using odd pixel sizes, your effective compression decreases because of the way PNG compression works. The advantage of PNG compression over just using straight FLATE/ZIP compression is the filtering. PNG compression tries to exploit horizontal and vertical symmetry with a small assortment of pre-processing filters. These filters work on byte boundaries and are effective with pixel sizes of 4/8/16/24/32/48/64 bits. When you move to an odd size pixel (3/5/6/7 bits) you are defeating the filtering because identically colored pixels won't "cancel each other out" horizontally when filtered on 8-bit boundaries.
Even if the filtering weren't an issue, the way that FLATE compression works, reducing the pixel size from 8 to 7 or 6 bits won't have much effect either because it also assumes a symbol size of 8-bits.
In conclusion...the only benefit you can achieve by using odd sizes of pixels is that the uncompressed data will be smaller. By breaking the pixels' byte boundary symmetry, you defeat much of the benefit of PNG compression.
GIF compression supports all pixel sizes from 1 to 8 bits. It defines the symbol size as the pixel size and doesn't use any pre-filtering. An 8-bit GIF image, if compressed as 7-bit pixels, wouldn't suffer less compression, but also wouldn't benefit because the compression depends more on the repetition of the pixels than the symbol size.
DEFLATE compression used by PNG has two main techniques:
finds repeating byte sequences and encodes them as backreferences
encodes bytes using Huffman coding
By changing pixel length from 8-bit you're out of sync with byte boundaries and DEFLATE won't be able to encode repeating pixel runs as repeated bytes.
And thanks to Huffman coding it doesn't matter that 8-bit pixels have unused bits, because the coding will encode bytes with variable-width codes assigning shortest ones to most frequently occurring values.