When I observing the JPEG files with specific quality factor, I want to analyse the Proportion distribution of DC and ACs. i.e, I want to know how much size the DC and ACs take up within JPEG files, respectively. Is there any public revelant statistical data ? Or how can I do it by myself ?
Related
I have MRI T2-weighted scans of the human brain. However, the size of them is only 128x128 pixels each of 1.71875/1.71875 mm size. I use these scans to find the perfusion parameters: CBV, CBF and MTT. However, some people confused me saying that the quality of images is not enough for the analysis - even though the images are gathered from a medical institution.
I also heard some rumors that since the paramagnetic tracer is used during the scans the quality is sufficient, because we need to capture a flow of the tracer. If we increase the resolution, the time between scans will also increase and we won't capture a flow of the tracer correctly.
Are there any specialists in this area who could explain the situation of the images quality? Is it reasonably enough or it should be better?
I have a series of ~300 high resolution images (~0.5 gigapixel) which I want embedded as PhotoOverlays in Google Earth. I have them in either of two formats, ~250mb geotiff's (georeferenced & warped) and ~100mb jpg's (which I can localize in GE with explicit coordinates). These images are of very small areas (~100m^2). Ultimately, I will want to share the images online.
Are the file sizes big enough to need Image Pyramids?
If so, is gdal_retile an appropriate tool to produce the pyramids and the KML?
I've used bigtiff library(coming from libtiff to deal with files larger than 4GB) to generate a 8GB image. It can be saved and display successfully, however, it's still to large to be transferred or shared. So I'm trying to compress it with the jpeg support from bigtiff(or libtiff), but it doesn't seem to work for me.
TIFFSetField(out,TIFFTAG_COMPRESSION,COMPRESSION_JPEG);
TIFFSetField(out,TIFFTAG_JPEGQUALITY,30);
TIFFSetField(out,TIFFTAG_JPEGCOLORMODE,JPEGCOLORMODE_RGB);
As above, I set the Jpeg quality tag to 30, and the program can be compiled correctly. However, the result turned out to be a image with jpeg quality equaling to 75 with compression ratio 0.99.
Does anyone have any idea about what's going on here or any suggestions?
Thanks,
sunhmy
There is no such thing as a JPEG quality value. Quality settings are simplifications JPEG encoders use to select quantization tables.
One encoder may use a range of 0-100.
Another might use 1-8.
You would need to find out what BigTif uses as its range of "Quality" values. It's 30 may well correspond to your 75.
You might want to play around with different values to find out.
Earlier I read about mozjpeg. A project from Mozilla to create a jpeg encoder that is more efficient, i.e. creates smaller files.
As I understand (jpeg) codecs, a jpeg encoder would need to create files that use an encoding scheme that can also be decoded by other jpeg codecs. So how is it possible to improve the codec without breaking compatibility with other codecs?
Mozilla does mention that the first step for their encoder is to add functionality that can detect the most efficient encoding scheme for a certain image, which would not break compatibility. However, they intend to add more functionality, first of which is "trellis quantization", which seems to be a highly technical algorithm to do something (I don't understand).
I'm also not entirely sure this quetion belongs on stack overflow, it might also fit superuser, since the question is not specifically about programming. So if anyone feels it should be on superuser, feel free to move this question
JPEG is somewhat unique in that it involves a series of compression steps. There are two that provide the most opportunities for reducing the size of the image.
The first is sampling. In JPEG one usually converts from RGB to YCbCR. In RGB, each component is equal in value. In YCbCr, the Y component is much more important than the Cb and Cr components. If you sample the later at 4 to 1, a 4x4 block of pixels gets reduced from 16+16+16 to 16+1+1. Just by sampling you have reduced the size of the data to be compressed by nearly 1/3.
The other is quantization. You take the sampled pixel values, divide them into 8x8 blocks and perform the Discrete Cosine transform on them. In 8bpp this takes 8x8 8-bit data and converts it to 8x8 16 bit data (inverse compression at that point).
The DCT process tends to produce larger values in the upper right corner and smaller values (close to zero) towards the lower left corner. The upper right coefficients are more valuable than the lower left coefficients.
The 16-bit values are then "quantized" (division in plain english).
The compression process defines an 8x8 quantization matrix. Divide the corresponding entry in the DCT coefficients by the value in the quantization matrix. Because this is integer division, the small values will go to zero. Long runs of zero values are combined using run-length compression. The more consecutive zeros you get, the better the compression.
Generally, the quantization values are much higher at the lower left than in the upper right. You try to force these DCT coefficients to be zero unless they are very large.
This is where much of the loss (not all of it though) comes from in JPEG.
The trade off is to get as many zeros as you can without noticeably degrading the image.
The choice of quantization matrices is the major factor in compression. Most JPEG libraries present a "quality" setting to the user. This translates into the selection of a quantization matrices in the encoder. If someone could devise better quantization matrices, you could get better compression.
This book explains the JPEG process in plain English:
http://www.amazon.com/Compressed-Image-File-Formats-JPEG/dp/0201604434/ref=sr_1_1?ie=UTF8&qid=1394252187&sr=8-1&keywords=0201604434
JPEG provides you multiple options. E.g. you can use standard Huffman tables or you can generate Huffman tables optimal for a specific image. The same goes for quantization tables. You can also switch to using arithmetic coding instead of Huffman coding for entropy encoding. The patents covering arithmetic coding as used in JPEG have expired. All of these options are lossless (no additional loss of data). One of the options used by Mozilla is instead of using baseline JPEG compression they use progressive JPEG compression. You can play with how many frequencies you have in each scan (SS, spectral selection) as well as number of bits used for each frequency (SA, successive approximation). Consecutive scans will have additional frequencies and or addition bits for each frequency. Again all of these different options are lossless. For the standard images used for JPEG switching to progressive encoding improved compression from 41 KB per image to 37 KB. But that is just for one setting of SS and SA. Given the speed of computers today you could automatically try many many different options and choose the best one.
Although hardly used the original JPEG standard had a lossless mode. There were 7 different choices for predictors. Today you would compress using each of the 7 choices and pick the best one. Use the same principle for what I outlined above. And remember non of them encounter additional loss of data. Switching between them is lossless.
I'm going to let users upload images of 300x300 compressed with JPEG. Is there a way to determine what the maximum file size of such an image would be?
I can imagine this can be tried by compressing random noise at 100 quality, but is there a theoretical maximum?
Say that the image is totally uncompressable random noise, could it be 3 bytes per pixel (24-bits colour) and a margin for the metadata? Or could such an image turn out larger than the original when compressed?
From wikipedia:
For highest quality images (Q=100), about 8.25 bits per color pixel is required
http://en.wikipedia.org/wiki/JPEG#Sample_photographs
So, for Q=100 on an 300x300 image, that would result in (300 * 300) px * 8.25 bits/px = 742,500 bits = ~ 93 kB
There are also lossless JPEG coding modes, which are practically not used (last sentence, second paragraph). But they would have the RGB typical 24 bits/pixel.
There is no limit on jpeg metadata size, which means there's no limit to the size of a jpeg file. See this answer I've linked for an explanation of why and also for an example of a realistic situation where the metadata might get large: What is the maximum size of JPEG metadata?
So if assuming a maximum practical/realistic size suits your purpose, then you should factor that example into your calculations. In many contexts it would be fine to just reject things outside of that maximum as outside the domain of your program's intended usage.
But if you absolutely must rely on theoretical, then unfortunately it's a big bold ∞
Note: I do not have a huge amount of personal experience with the jpeg specification, so I am going off of what people have said about repeated fields being allowed, as well as multiple comment fields. Please correct me if you find evidence to the contrary.