Re: [Gimp-developer] Size on disk vs size reported on status bar


On Wed, Oct 4, 2017 at 3:51 PM, Elle Stone
<ellestone ninedegreesbelow com> wrote:
On 10/04/2017 09:02 AM, Jehan Pagès wrote:


On Wed, Oct 4, 2017 at 2:28 PM, Jehan Pagès <jehan marmottard gmail com>

Hi again!

On Wed, Oct 4, 2017 at 1:01 PM, Elle Stone
<ellestone ninedegreesbelow com> 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
extra channels (saved masks) in the channels dialog.

Ignoring the masks and the extra saved channels, and assuming I'm doing
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

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):

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:
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. :-)


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. ;-)


ZeMarmot open animation film

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]