Jakt to policzył? 6480 x 3888 x 32 / 8) = 100,776,960

https://github.com/johnnylambada/WorldMap

The map itself is quite large (6480,3888), so it's way too big to fit in memory all at once (6480 x 3888 x 32 / 8) = 100,776,960 -- over 96 megs.

Czy ktoś mi może wyjaśnić co to jest to "x 32 / 8"?
I skąd się wzięło "over 96 megs"?

Rozchodzi się o ten obrazek

który jest jpegiem, a jego dane to:

File — basic information derived from the file.
File Type JPEG
File Type Extension jpg
MIME Type image/jpeg
Encoding Process Baseline DCT, Huffman coding
Bits Per Sample 8
Color Components 3
File Size 5.7 MB
Image Size 6,480 × 3,888
Y Cb Cr Sub Sampling YCbCr44 (1 1)

"x 32" to rozumiem że ktoś przyjął bit depth 32 - błędnie (?) bo przecież to jpeg więc ma 8 x 3 kolory = 24.

"/ 8" to rozumiem że chodziło o zamianę bitów na bajty

zatem przyjmując jednak poprawne 24 zamiast 32 wychodzi
75582720b czyli około 9.45MB.

No ale nijak nie wyjdzie 96 megs...

marian pazdzioch napisał(a):

"/ 8" to rozumiem że chodziło o zamianę bitów na bajty

zatem przyjmując jednak poprawne 24 zamiast 32 wychodzi
75582720b czyli około 9.45MB.

No ale nijak nie wyjdzie 96 megs...

dzielisz przez 8 żeby z bitów zrobić bajty, a potem znowu dzielisz przez 8?

możesz to sobie inaczej policzyć. jeden piksel = 3 bajty. pikseli jest 6480 x 3888 = 25194240 (25,2 Mpix), więc bajtów jest 25194240 x 3 = 75582720 = 75,6 mega

4 bajty na piksel biorą się prawdopodobnie z tego, że szybciej jest pomnożyć przez 4 (przesunięciem bitowym) niż pomnożyć przez 3, więc bufor ramki zwykle jest formacie RGB (po 8 bitów na kanał) + wyrównanie do 32 bitów (czyli 8 bitów nieużywane). dodatkowo na ciasno upakowanych 3-bajtowych pikselach nie da się zrobić operacji atomowych, ale na 4-bajtowych już tak. to może się teoretycznie przydać.

EDIT:
6480 x 3888 x 3 x 8b = 604661760b
czyli 75MB

jednak wciąż nie 96 megs, jakkolwiek rząd wielkości się zgadza

marian pazdzioch napisał(a):

jednak wciąż nie 96 megs, jakkolwiek rząd wielkości się zgadza

już napisałem czemu

Wibowit napisał(a):

4 bajty na piksel biorą się prawdopodobnie z tego, że szybciej jest pomnożyć przez 4 (przesunięciem bitowym) niż pomnożyć przez 3, więc bufor ramki zwykle jest formacie RGB (po 8 bitów na kanał) + wyrównanie do 32 bitów (czyli 8 bitów nieużywane). dodatkowo na ciasno upakowanych 3-bajtowych pikselach nie da się zrobić operacji atomowych, ale na 4-bajtowych już tak. to może się teoretycznie przydać.

wnioskuję to stad, że gość mówi o trzymaniu tego w pamięci:

marian pazdzioch napisał(a):

https://github.com/johnnylambada/WorldMap

The map itself is quite large (6480,3888), so it's way too big to fit in memory all at once (6480 x 3888 x 32 / 8) = 100,776,960 -- over 96 megs.

dla przykładu, na moim służbowym laptopie jedynym trybem bufora ramki pulpitu jest True Color (32-bit)

True color (24-bit)
24 bits almost always use 8 bits each of R, G, and B (8 bpc). As of 2018, 24-bit color depth is used by virtually every computer and phone display[citation needed] and the vast majority of image storage formats. Almost all cases of 32 bits per pixel assigns 24 bits to the color, and the remaining 8 are the alpha channel or unused.

oczywiście to nie jest żaden dowód, ale wątpię by ktoś się bawił w wymuszanie 24-bitowego bufora gdzieś tam, skoro 32-bitowe piksele to w zasadzie standard od dawna.

Dzięki, bardzo treściwa odpowiedź.

Karty graficzne już od dawna nie obsługują 24-bitowych trybów pracy, zamiast tego są 32 bity które marnują 25% bufora.