At the begin sorry for my English.
My purpose is to load rgb array from the bitmap. But there is a difference between size of the image and the product of height * width * 3. When i read about bmp format i notice when the widht % 4 is != 0 then i must add to width some digit to equilibrium. (width%4==1 i must add 3, width%4==2 i must add 2 etc.)
Size of the image is 1 442 454 Bytes, height is 601 and width is 801.
804 * 600 * 3 == 1 441 800 and it is more then size of the image.
801 * 600 * 3 == 1441800 it must less then size of the image (even when I add 54 bits of headers). What i must do to read it correctly? (headers are loaded correctly)
Note that each row is padded to a multiple of 4 bytes (not pixels).
So if you have 801 pixels per row and each pixel is 3 bytes (RGB) them you have 801*3=2403 bytes per row and this will be padded with one additional byte to 2404 bytes. The bitmap size will therefore be 601*2404=1444804 bytes.
If however your row width is only 800 pixels then you have 800*3=2440 bytes per row which is already a multiple of 4 bytes so there will be no additional pad bytes and the bitmap size will be 601*2400=1442400 bytes. With a 54 byte header this gives 1442454 bytes.
Conclusion: your image size is actually 801 x 600, not 801 x 601.
Related
I am not very familiar with old opencv codes. I have an IplImage struct:
IplImage *X;
This struct filled up with data that program reads from a device. I want to show it as image in my gui program. But I am not sure which properties I need to use.
EDIT:
Values of IplImage structs all properties with same order in docs(https://docs.opencv.org/3.4/d6/d5b/structIplImage.html):
4
0
0x557684eba3b4
0x557684eba3a4
GRAY
GRAYGRAY
0
16
192
0
�J�ಃ�O�ӳD������I���|�㲏�u������³��t�p�ݲ?�����F�Q�ⲿ���)���ҳ3�7�|�Ӳ������`�����_�I�_�Ͳ���{����E�5�p���(�(�D�|���L�L�W�����Q�,�r�D�L���ز��³�������������ҳ�̲�0������ܳ��,�³dzj�׳��$�|�����u����N���$���Q�ȳ��ܳڳ��������
�J�ಃ�O�ӳD������I���|�㲏�u������³��t�p�ݲ?�����F�Q�ⲿ���)���ҳ3�7�|�Ӳ������`�����_�I�_�Ͳ���{����E�5�p���(�(�D�|���L�L�W�����Q�,�r�D�L���ز��³�������������ҳ�̲�0������ܳ��,�³dzj�׳��$�|�����u����N���$���Q�ȳ��ܳڳ��������
0
49152
0
1
144
0
0
0
127
256
Why take up 21 bytes, on a 32-bit system, three pointers plus two numbers 5 * 4 = 20 (should be 20 bytes ah)
Thank you for your answer!!!
https://redis.com/ebook/part-2-core-concepts/01chapter-9-reducing-memory-use/9-1-short-structures/9-1-1-the-ziplist-representation/
enter image description here
Your book counts the terminating \0 byte at the end of "one\0" as overhead, bringing the total to 21.
struct s11
{
alignas(16) char s;
int i;
};
does alignas(n) X x mean it would allocate n bytes to hold a X, when X is actually much smaller than n bytes, the rest memory would be all 0s?
when s11.s is in memory 0x0, does that mean s11.i would be at 0x10? However, the following pdiff is 0x4
s11 o;
ptrdiff_t pdiff = (char*)&o.i - (char*)&o.s;
Please explain why sizeof(s11) is not 16 times 2, while sizeof(s1) is 8 times 3?
struct s1
{
char s;
double d; // alignof(double) is 8.
int i;
}
EDIT:
This is what I found after a lot of digging and code snippets, that how alignas affect struct(class) size.
alignas(n) X x means in memory x is located at a place with an offset of multiple of n bytes, starts from 0x00. Therefore, s11.s can be located at 0x00, 0x10, 0x20 and so on. Because s11.s is the first field, it is at 0x00, and it is a char, so it ocupies 1 bytes.
So is the 2nd field. int has an align 4, therefore it can be located at 0x00, 0x04, 0x08, 0x0c, etc. Because the first byte is taken by s11.s, so s11.i is located at 0x04.
when alignof operator used in struct does it affect sizeof
You aren't using alignof operator. You're using alignas specifier.
Using alignas specifier doesn't necessarily affect the size of a class, but it can affect it.
does alignas(n) X x mean it would allocate n bytes to hold a X, when X is actually much smaller than n bytes, the rest memory would be all 0s?
No. If there is padding, there's no guarantee that it would be all 0s. Furthermore, there are cases where the memory can be occupied by other members.
when s11.s is in memory 0x0, does that mean s11.i would be at 0x10?
No.
Please explain why sizeof(s11) is not 16 times 2
Probably because it doesn't need to be. Here is an example layout that would satisfy the alignment requirements:
offset member alignment offset % alignment must equal 0
0 s 16 0 % 16 == 0
1 padding
2 padding
3 padding
4 i 4 4 % 4 == 0
5 i
6 i
7 i
8 padding
9 padding
10 padding
11 padding
12 padding
13 padding
14 padding
15 padding
---
super alignment 16 16 % 16 == 0
while sizeof(s1) is 8 times 3?
Here is an example layout that would satisfy the alignment requirements:
offset member alignment offset % alignment must equal 0
0 s 1 0 % 1 == 0
1 padding
2 padding
3 padding
4 padding
5 padding
6 padding
7 padding
8 d 8 8 % 8 == 0
9 d
10 d
11 d
12 d
13 d
14 d
15 d
16 i 4 16 % 4 == 0
17 i
18 i
19 i
20 padding
21 padding
22 padding
23 padding
---
super alignment 8 24 % 8 == 0
My examples apply to a system where double is 8 bytes and int is 4.
No, it means the starting address of the member s must be aligned on a 16-byte boundary. Probably in the case of it being the first member of a struct, this will result in the struct itself adopting that alignment and not affecting the size.
No, there is no specified alignment pertaining to the member i, so normal alignment rules apply. If you're getting 4 then your system is using integers that have a size of 4 bytes, and are similarly aligned. The value of padding bytes is unspecified.
The first explanation is in my answer to #2. Follow-up incorporting the answer to #1, the size will probably be 16 due to the required structure alignment. And sizeof(s1) is 8 times 3 because of the alignment requirements of the double member causing padding elsewhere, combined with the entire structure's alignment. Moving the char member to the end of the structure will reduce the total size.
I am working on an mp3 decoder, the formula to determine the length, in bytes, of an mp3 frame is
FrameSize = 144 * BitRate / (SampleRate + Padding)
I can't find anywhere that explains what the '144' represents.
Does anyone know?
The 144 represents total bytes-per-frame.
MP3 files are generally encoded as MPEG-1 Layer 3.
There are 1152 samples per frame in type Layer 3.
1152 samples / 8 bits-per-byte = 144 bytes total.
Taking the formula for frame size (in bytes):
FrameSize = 144 * BitRate / (SampleRate + Padding)
We can see (for MP3 with 192 bitrate # 44.1 khz):
144 * 192 / (44.1 + 0) = 626 bytes per audio frame (fraction parts are ignored).
I have a std::string that is base32 encoded and I have a function that decodes it. The function takes a char* input, a char* destination and a length. How do I know what length I will need for the destination? I need to know what array to allocate for the destination. How do I determine the size?
Base32 allows to encode each 5 bits ( as 32 = 2^5 ) using single character.
It means that you need output buffer size for encoding:
dst_size = src_size * 8 / 5 (1.6 times larger)
But as base32 string length must be multiple of 40 bits:
dst_size = (src_size * 8 + 4) / 5
Thus, for decoding (base32->binary) required buffer size is accordingly
dst_size = ceil( src_size / 1.6 )
Actually, the encoded base32 string length is computed as follow :
ceil(bytesLength / 5.d) * 8
bytesLength / 5.f because we want to know how many chunks of 5 bytes we have, and ceil because 0.1 chunk is still 1 chunk
ceil(bytesLength / 5.f) * 8 because a chunk is made of 8 characters.
For the input data 'a' the encoded result will be ME====== because we have 1 chunk of 8 characters : two 5bits encoded characters (ME) 6 padding characters (======)
The same fashion, the decoded length is :
bytesLength * 5 / 8
But here bytesLength is not including the padding characters, thuse for ME====== bytelength is 2, giving 2 * 5 / 8 == 1 we only have 1 byte to decode.
For a visual explanation, see rfc4648 section 9 (page 11)