Hi! On Wed, Oct 4, 2017 at 3:51 PM, Elle Stone <ellestone@xxxxxxxxxxxxxxxxxxxx> wrote: > On 10/04/2017 09:02 AM, Jehan Pagès wrote: >> >> Hi! >> >> On Wed, Oct 4, 2017 at 2:28 PM, Jehan Pagès <jehan.marmottard@xxxxxxxxx> >> wrote: >>> >>> Hi again! >>> >>> On Wed, Oct 4, 2017 at 1:01 PM, Elle Stone >>> <ellestone@xxxxxxxxxxxxxxxxxxxx> wrote: >>>> >>>> Actually the image is at 32-bit floating point precision, all the layers >>>> have alpha channels, most of the layers have masks, and there are a >>>> couple >>>> extra channels (saved masks) in the channels dialog. >>>> >>>> Ignoring the masks and the extra saved channels, and assuming I'm doing >>>> the >>>> right math, this would be: >>>> >>>> 4000*6000*7*32*4 = 21 504 000 000 / 1024^3 ~ 20 GB >>> >>> >>> Sorry I was stupid earlier. By multiplying by 24 (or here 32), we get >>> the size in bits, we want in bytes (instead, we must multiply by 3 >>> bytes for 32 bits). So a single mono-channel image should be >>> 4000*6000*3 bytes. >>> So assuming each layer has alpha and mask, that makes 5 channels per >>> layer and each channel uses 3 bytes: >>> 4000*6000*3*7*5 ~ 2.34 GB. >> >> >> Ok so I meant 4 bytes of course! I can't even do basic maths right >> anymore! :P >> >> 4000*6000*4*7*5 ~ 3.2G. > > > Hi Jehan, > > So a byte is 8 times a bit? Nowadays, on all common hardware, yes. That depends on the hardware, the processor in particular. And basically this is the smallest memory size which you can manipulate (we cannot just grab a single pixel). I am told there used to be hardware where bytes could be other value than 8 but I never saw such a hardware in my life. And I'm pretty sure most software nowadays assume that 1 byte == 8 bits and would likely crash horribly on a different kind of hardware (if even they can build). :-) > For people like me who can never remember the > difference between a byte and a bit, is there a one-sentence explanation for > why there are bytes *and* bits? Well a bit is just 2 values (0 or 1). But as I said, we can't manipulate bits. We only manipulate bytes. This is hardware limitation. This i the reason why there are bytes and bits. >> Ok so I had a quick look at the code. >> For the size displayed in the status bar, it seems it would use the >> size as returned by each GimpObject through the get_memsize() virtual >> method: https://git.gnome.org/browse/gimp/tree/app/core/gimpobject.c#n445 >> >> You can get an idea of the expected size by looking at GimpTemplate >> code which is used to guess the future memory size (to warn before >> image creation if the expected size will be big): >> https://git.gnome.org/browse/gimp/tree/app/core/gimptemplate.c#n426 >> >> We can see that the expected size seems to be based on the initial >> layer + the selection + the projection (which apparently always has >> alpha and multiplies the result by 1.33: >> https://git.gnome.org/browse/gimp/tree/app/core/gimpprojection.c#n326). >> So for your image with 7 layers, alpha (and assuming all with mask), >> following this estimation algorithm: >> 4000*6000*4*7*5 + 4000*6000*4 + 4000*6000*16*1.33 ~ 3.7GB. >> >> This estimation is quite close to the actual 3.8GB GIMP gives you. >> With the few more channels you said you had, I guess that's about it. >> :-) > > > Thanks! That's a nice explanation! This might be useful to put in the user's > manual, if it isn't already there. Maybe. But I'm not sure it is useful to go into that much details which is really implementation dependent. Just saying that the image in memory is uncompressed and would use a lot more memory than on disk should be enough, no? We could add some example computation, but I think a less accurate computation like my initial ones (basically stop at: a single layer image size, with alpha and 32-bit per pixel, would be: width * height * 4 * 4) would be more useful to grab the concepts rather than adding stuff like projection and multiplying by 1.33 because of pyramid levels which is like cryptic language. Anyway feel free to check if the manual already has such text and propose some additional text if missing. :-) Jehan P.S.: I was also wrong when dividing by 1024^3 to get GB. Our code uses g_format_size() which says that 1kB == 1000 B. This is another very annoying historical thing about bytes is that originally their multiples used to be converted in different ways (depending on whether you were the technical department or the marketing one! :P). Since it made no sense (kilo should always be 1000, that's international standard), the kibi has been invented which is the binary prefix for multiples of 1024. So our code is good on the new standard, and I was wrong on using 1024 instead of 1000. This makes my estimation about 3.9 GB and not 3.7 in the end so a bit more than the 3.8 you actually see in GIMP. But well… that was just an estimation and is close enough. ;-) > Best, > Elle -- ZeMarmot open animation film http://film.zemarmot.net Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
