I created a monochrome bitmap image and stored it in secondary memory. The dimension of the image is 484 * 114. In monochrome each pixel of the image is represented by 1 bit so the size of the image should be 6.7 kb . But when I check the size by right on file in OS , it is 7.18 KB , I need the explanation why the size is different and not exact as I calculated?
Because of overhead of headers for example; your bitmap won't only store the bits representing your image but also (meta)information containing information such as width, height, bits per plane etc. The actual bitmap data is just a bunch of bytes, without this (meta)information your image might as well be 114 x 484 instead of 484 x 114. Take a look at, for example, the BMP fileformat.
Also, OS'es tend to round filesizes to particular block sizes (like 4Kib). Unless you state the exact filesize in bytes, OS and filetype all we can do is guess.
Related
This is all of the information I was provided in the practice question. I am trying to figure out how to calculate it when prompted to do so on an exam...
How to determine the number of bytes necessary to store an uncompressed grayscale image of size 8000 × 3400 pixels?
I am also curious how the calculation changes if the image is a compressed binary image.
"I am trying to figure out how to calculate it when prompted to do so on an exam."
There are 8 bits to make 1 byte, so once you know how many bits-per-pixel (bpp) you have, this is a very simple calculation.
For 8 bits per pixel greyscale, just multiply the width by the height.
8000 * 3400 = 27200000 bytes.
For 1 bit per pixel black&white, multiply the width by the height and then divide by 8.
(8000 * 3400) / 8 = 3400000 bytes.
It's critical that the image is uncompressed, and that there's no padding at the end of each raster line. Otherwise the count will be off.
The first thing to work out is how many pixels you have. That is easy, it is just the width of the image multiplied by the height:
N = w * h
So, in your case:
N = 8000 * 3400 = 27200000 pixels
Next, in general you need to work out how many samples (S) you have at each of those 27200000 pixel locations in the image. That depends on the type of the image:
if the image is greyscale, you will have a single grey value at each location, so S=1
if the image is greyscale and has transparency as well, you will have a grey value plus a transparency (alpha) value at each location, so S=2
if the image is colour, you will have three samples for each pixel - one Red sample, one Green sample and one Blue sample, so S=3
if the image is colour and has transparency as well, you will get the 3 RGB values plus a transparency (alpha) value for each pixel, so S=4
there are others, but let's not get too complicated
The final piece of the jigsaw is how big each sample is, or how much storage it takes, i.e. the bytes per sample (B).
8-bit data takes 1 byte per sample, so B=1
16-bit data takes 2 bytes per sample, so B=2
32-bit floating point or integer data take 4 bytes per sample, so B=4
there are others, but let's not get too complicated
So, the actual answer for an uncompressed greyscale image is:
storage required = w * h * S * B
and in your specific case:
storage required = 8000 * 3400 * 1 * 1 = 27200000 bytes
If the image were compressed, the only thing you should hope and expect is that it takes less storage. The actual amount required will depend on:
how repetitive/predictable the image is - the more predictable the image is, in general, the better it will compress
how many colours the image contains - fewer colours generally means better compression
which image file format you require (PNG, JPEG, TIFF, GIF)
which compression algorithm you use (RLE, LZW, DCT)
how long you are prepared to wait for compression and decompression - the longer you can wait, the better you can compress in general
what losses/inaccuracies you are prepared to tolerate to save space - if you are prepared to accept a lower quality version of your image, you can get a smaller file
An image is broken down in picture elements (pixels) which means that when I check the attributes of an e.g. JPEG image stored on disk I can see e.g. 532 × 1051 pixels which means the width is 532 the height is 1051.
It also says in the attributes of the file that the color model is RGB which would mean 1 byte for each channel = 3 bytes to describe the color.
So I would assume that the actual size of the image is:
532x1051x3= 1.67MB
But what I see is that the actual file size reported is 45KB.
So does this mean that the 1.67MB is the size of the image in memory?
Also I see as part of the meta data: Image DPI: 96 pixels/inch.
What exactly is this information used for?
But what I see is that the actual file size reported is 45KB
That's because JPEG images are compressed in multiple ways to save up space, sometimes up to a factor of ten so this is not unusual. You can just search for "jpeg compression" and read how it is done in detail if you're interested.
Also I see as part of the meta data: Image DPI: 96 pixels/inch. What
exactly is this information used for?
Generally, as long as you are only interested in the image stored digitally you do not use it at all, because the image is not stored in inches. You could change the DPI and the image itself would not change, just the image header.
DPI only makes sense once you display/print the image. Then you could take it as a general recommendation on which resolution you should print this image. If you want to print a huge landscape with only 50 pixels per inch, it will not look good. If you however want to print a small logo with low DPI it might still look fine. So it really depends highly on the context of the image.
I have read severel posts like this one claiming that the size of a JPG texture can be calculated as
If each pixel contains 32 bits of information, then
307,200 * 32 = 9,830,400 bits of information
Divide by the 8 bits to become a byte value
9,830,400 / 8 = 1228800 bytes (Or 1.17 Mb)
which totally makes sense since each pixel is represented by a color value. Here comes the weird part:
I have these two JPG files
First JPG
which has the dimensions 242x198 and uses 24-bit color values.
Second JPG
which has the dimensions 3840x2400 and uses 24-bit color values.
Then I tried to calculate the sizes using the technique above and concluded that
The first JPG must have the size 242*198*24 = 1149984 bits = 1149984/8/1000 = 143.7 kb - now the actual file size is 47,6 kb?? So the calculation apparently gives a number above the actual size, why?
The second JPG must have the size 3840*2400*24 = 221184000 = 221184000/8/10000 = 27.6 mb - now the actual file size is 7.33 mb. So the calculation apparently gives a number above the actual size, why?
I have myself managed to draw the first JPG and made sure to export it without compression (JPG 100).
The whole point of JPEGs is that they are compressed to take up less space. If you resave your file as a BMP you'll get the sizes you expect (plus a bit extra for headers and alignment).
I am displaying bitmaps with the function SetDIBitsToDevice. This function knows about the total image size via a LPBITMAPINFO structure that has Width and Height fields. It also knows about the region of interest to be drawn via the arguments XDest, YDest, Width, Height. All these are specified in pixels.
So far so good when the image is stored as a canonical one, i.e. with a row pitch (number of bytes between a pixel and the one immediately below) that matches the image width in bytes, with padding (if necessary) to reach the next multiple of four bytes.
For technical reasons, I have images with a larger pitch (but still a multiple of four). For instance, width=1000 but pitch=1024. For a grayscale image (1 byte per pixel), I can trick the function by declaring a width of 1024 in LPBITMAPINFO and a width of 1000 when passed to SetDIBitsToDevice.
But for a 3 bytes per pixels image (RGB), I am stuck because 1024 bytes do not correspond to an integer number of pixels, and I see no way to specify that pitch.
Do you see a workaround or something I missed in the documentation ? (I don't think that the field SizeImage can be of any use.)
What's the maximum size an uncompressed 48x48 image can have? I'd like to set up a reference image for debugging.
48 * 48 = 2304
So, (2304 * number of channels * bytes per channel) bytes
W * H * BitsPerPixel
If BitsPerPixel is 32 (Millions of colors), then it would be 73,728 bits. divide that by 8 to get bytes (9,216). The actual size would vary between the uncompressed formats a bit, especially depending on their color capabilities.
For Bitmaps, this Wikipedia page mentiones some of the color options: http://en.wikipedia.org/wiki/Bitmap
Recently I wrote a primitive PNG writer. You have to put one byte infront of every line and add PNG as well as ZLIB headers and checksums. I'm not sure but I think you can have RGBA images with 16bit per channel. The raw data would be 48*49*2*4=9.4kB. So I would make sure that you can handle 16kB or so.
As you are talking about compression, I assume that you mean an image file.
The maximum size would depend on the file format and bit depth that you allow.
A 96 bpp TIFF image for example would be 46 kB.
A more reasonable format could be a 24 bbp BMP file, which is 7 kB.