Bitmap images contain pure representation of raw data. A 512x512 24bit bitmap image (like game textures) is 768KB in size, as it should be. Why a 512x512, but 8-bit instead of 256KB, is 257KB? Also a 256x256 8-bit image is 65KB instead of 64! (66,614 bytes instead of 65536 bytes); but for the 24 bit one, it is exactly as it should be.
Thanks...I'm confused.
What do you mean with "bitmap image"? It is true that they contain raw data, but they may contain a header also.
And/Or there could be some rounding error in whatever interface is telling you "65 Kb". What is the exact length in bytes for the 64K image? Is it 65536 bytes, or something more?
Related
The tests I made were not conclusive.
There are imagens with 3MB, but with small dimensions that generate small strings.
There are images with few Ks, but with large dimensions that generate large strings.
What is the weight of each of these characteristics?
And does the image format count?
There is a direct relationship between:
the size of a JPEG-encoded image and its base64 representation,
between a TIFF-encoded image and its base64 representation,
between a PNG-encoded image and its base64 representation.
That relationship is that the base64 version will be around 33% bigger.
However, there is no relationship between an image and its base64 representation if the file format is not specified. The reason is that the file format (and image content) are likely to grossly affect the compression achieved - if indeed the format supports compression.
For example, the same simple red rectangle of size 1024x768 pixels could take:
5MB to encode as an uncompressed TIFF, or
5kB as an LZW compressed TIF, or
9kB as a JPEG, or
2.5MB as a BMP
all we can say is that the base64 versions will be around 33% bigger.
Note further, that it is not even sufficient to stipulate that you want to predict the size of the base64 representation when, say, JPEG encoded - because the size will still depend on the quality setting used for the JPEG encoding... likewise the compression method and bit-depth used in a TIFF encoder.
I'd like to know which is the image format which permits me to encode losslessly 0xFFFFFF colors, but I need the one which occupies less space on disk. I know that BMP, JPEG(variant), TIFF, PNG,(just to say some) are lossless, but which one is the one that, considering also zipping or whatever, can occupy less space?
A PNG image (16million.png) containing all possible RGB888 colors was published in 1996. It occupies 115,989 bytes. I have converted the same image to a MNG file of just 472 bytes. The current version of pngcrush (1.8.0) brings the PNG file down to 91514 bytes.
See Khalid Sayood's Lossless Compression Handbook.
If on the other hand you are asking about a format that can represent a single pixel in any one of the 16 million colors, then PNG takes 69 bytes
including the 8-byte PNG signature, the IHDR, IEND, and IDAT chunk overhead, and several bytes of zlib overhead within the IDAT chunk, while a simple PPM file only takes 14 bytes to represent such single-pixel images (P6 1 1 255 \n red green blue).
Between those extremes, the best compression depends upon the content of the image.
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.
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.
When I encode Rgb24 frame with H264 I get "input width is greater than than stride"...
By the way if I give raw image which is Yuv420p, ffmpeg successfully encodes it...
What I wanted to know is:
i) Do we have to give Yuv format for encoding? Can't give rgb frame for encoding h264?
ii) If we can give rgb frame, what is the trick?
I know this is a bit late (no answers since 2010), but it sounds like you need (or needed) to adjust the wrapping of your image data.
From the following MSDN article (I know it's MSDN, but its explanation of the concepts involved is REALLY good):
When a video image is stored in memory, the memory buffer might
contain extra padding bytes after each row of pixels. The padding
bytes affect how the image is stored in memory, but do not affect how
the image is displayed.
The stride is the number of bytes from one row of pixels in memory to
the next row of pixels in memory. Stride is also called pitch. If
padding bytes are present, the stride is wider than the width of the
image, as shown in the following illustration.
Read more here
Look at what you've specified for both your image width and image stride. Whatever data you are supplying for the row has more bits than you're specified for the stride (and I'm guessing the width as well, if they are in agreement).