Computer Graphics with Photoshop - I thought I understood what causes file size but I don't.....?

Author

I thought I understood what causes file size but I don't.....?

Dale Glaser

2004-06-01, 4:14 am

I had a friend do something to a document he could remember and end up
with a 150 meg file with an 8 x 10 inch x 300 dpi image (that had many
layers).

I started to tell him that it was all in the pixels and the
resolution and you could figure out file size mathematically from
that, but then when he told me it was an empty file, I myself got
confused...

Are the following true?

1. It doesn't matter whether the pixels are empty or filled with
color, the image size stays the same?

2. As long as you don't resample, or add alpha channels there is
nothing you can do that will change the image size?

3. Even if you add 25 layers, it won't affect the image size?

And/but then...

4. Why does an image with an image size of 140megs only show as 70megs
when I do a Get Info on it from the Finder/Desktop (File Manager)? Is
there a difference between "image size" and "file size"

5. What is the meaning of the numbers in the lower left of an image
window, where the first is supposed to be the "flattened" file size
(which seems to be the same as the image size), and the second is the
"working" size, which changes whenever you do something to the image.
Does the history palette get reflected in this "working" size?

6. Where do all the additions you make to an image with multiple
layers, etc. get reflected as far as image size.

I'm confused.....!

David Haley

2004-06-01, 7:14 am

This day of 31 May 2004 21:43:28 -0700, dglaser@pacific.net (Dale Glaser)
proclaimed:

>I had a friend do something to a document he could remember and end up
>with a 150 meg file with an 8 x 10 inch x 300 dpi image (that had many
>layers).
>
> I started to tell him that it was all in the pixels and the
>resolution and you could figure out file size mathematically from
>that, but then when he told me it was an empty file, I myself got
>confused...
>
>Are the following true?
>
>1. It doesn't matter whether the pixels are empty or filled with
>color, the image size stays the same?

If you understand image size as in brute representation in memory, the yes, that
is probably true. You need bytes to represent the pixels, empty or not. That
being said, I'd be astounded if programs didn't use some kind of algorithm to
represent large portions of empty or same-color pixels in just a few bytes.

>2. As long as you don't resample, or add alpha channels there is
>nothing you can do that will change the image size?

If the above is true, then this is true.

>3. Even if you add 25 layers, it won't affect the image size?

Well, no. You need to store the pixel information for each layer. The merged
version (i.e. no layers) doesn't need to do this, however.

>And/but then...
>
>4. Why does an image with an image size of 140megs only show as 70megs
>when I do a Get Info on it from the Finder/Desktop (File Manager)? Is
>there a difference between "image size" and "file size"

See above; due to compression algorithms. When the image is loaded in Photoshop,
you need to be able to display every one of the visible pixels and therefore
need to store them all somewhere (see below on space vs. time); when the image
is stored on disk you can use all sorts of lossless compression. e.g. if you
have a whole row of empty pixels, you can just say "empty row" which, if you're
moderately clever, is just a few bytes as opposed to representing 'empty' for
every...single...pixel. (this is called line-length encoding if you care - it's
a variant of run-length encoding, but RLE can span rows)

>5. What is the meaning of the numbers in the lower left of an image
>window, where the first is supposed to be the "flattened" file size
>(which seems to be the same as the image size), and the second is the
>"working" size, which changes whenever you do something to the image.
>Does the history palette get reflected in this "working" size?

Can't answer you there... too new to Photoshop to know the specifics. I'm sure
somebody else can help you.

>6. Where do all the additions you make to an image with multiple
>layers, etc. get reflected as far as image size.

I would suppose that the more layers you have, the bigger the working size. And
clearly every undo entry uses memory. Basically the trade-off at runtime is one
of space vs. time: would you rather have it go fast but use lots of memory, or
would you rather have it use less memory by compressing but have to wait all the
time as you compress/decompress the image to display/change it? Typically people
choose the former (time over space) especially these days due to the widespread
availability of memory.

Hope this helps clear some things up. I'm hardly a Photoshop expert but a lot of
these issues are common to any kind of graphics application.

-dhaley

>I'm confused.....!

--
~david-haley

Xalinai

2004-06-01, 12:14 pm

On 31 May 2004 21:43:28 -0700, dglaser@pacific.net (Dale Glaser)
wrote:

>I had a friend do something to a document he could remember and end up
>with a 150 meg file with an 8 x 10 inch x 300 dpi image (that had many
>layers).
>
> I started to tell him that it was all in the pixels and the
>resolution and you could figure out file size mathematically from
>that, but then when he told me it was an empty file, I myself got
>confused...
>
>Are the following true?
>
>1. It doesn't matter whether the pixels are empty or filled with
>color, the image size stays the same?

Basically a pixel is a data structure that has 8 or 16 bits for each
color channel used - 3 for RGB and for for CMYK.

If you have a single background layer, the memory needed for your
image can roughly be calculated as x-pixels x y-pixels x depth.

If you have more than one layer, then you need the size for each layer
plus the memory needed for the result of viewing each pixel through
the layers (background size x (number of raster layers+1)) plus
whatever the program needs for non-raster data.

Programs may allocate the memory for a layer when they are defined
(=create layer) or when they are used the first time (=first time you
change the layer contents). Each stategy has its benefits.

>
>2. As long as you don't resample, or add alpha channels there is
>nothing you can do that will change the image size?

You can change the bits per pixel.
Going to 48bits will double the size. Going to CMYK from RGB will add
one third, opposite way reduce by a quarter. If image contents allows
for reducing to 16bit (65536 colors) instead of RGB or even 256colors
you will reduce the image size by one third or two thirds accordingly.

>
>3. Even if you add 25 layers, it won't affect the image size?
If memory for raster layers is allocated when they are used, virgin
layers will cost almost no memory. But add one brushstroke to each
layer....

>And/but then...
>
>4. Why does an image with an image size of 140megs only show as 70megs
>when I do a Get Info on it from the Finder/Desktop (File Manager)? Is
>there a difference between "image size" and "file size"

Filesize is a very different thing than memory size.
For single layer images there is quite a lot of compression methods,
lossless and lossy.
For multilayer images there are still different methods to compress
each layer so usually the filesize of images is smaller than the
memory size needed to work with them.

>5. What is the meaning of the numbers in the lower left of an image
>window, where the first is supposed to be the "flattened" file size
>(which seems to be the same as the image size), and the second is the
>"working" size, which changes whenever you do something to the image.
>Does the history palette get reflected in this "working" size?

Working size reflects additional memory used for undo, history, and a
lot more things.

>6. Where do all the additions you make to an image with multiple
>layers, etc. get reflected as far as image size.

Either your activities change raster data - then the changed raster
layer contains your work - or you change parameters (like for
adjustment layers), then again the changes are in the image data and
if you are lucky there is a copy in the undo system.

Michael

David Haley

2004-06-01, 12:14 pm

This day of Tue, 01 Jun 2004 09:08:48 -0500, john@xyzzy.stafford.net (jjs)
proclaimed:

>In article <3uhob0dl928fthqle110mqii49e44bdl4s@4ax.com>, David Haley
><junkmale221@hotmail.com> wrote:
>
>
>What a circus. You are a pertty smart guy, but when Chris Cox drops by
>perhaps we will help you sort out your generalizations. Or not.

And just what is your problem? What did I say that was wrong? Please correct me
if I made a mistake, I would be more than happy to accept an error. In the
meantime however, I'd appreciate it if you weren't so quick to insult.

-dhaley

--
~david-haley

Tacit

2004-06-01, 12:14 pm

>1. It doesn't matter whether the pixels are empty or filled with
>color, the image size stays the same?

For a flat image, this is true. There is no such thing as an "empty" pixel for
a flat image; an "empty" pixel is a white pixel.

For an image in layers, if a layer is empty, then there is no pixel data and an
empty layer doesn't increase the size of a file. If a layer is smaller than the
size of the image, then the pixels outside the layer's bounding box do not add
to the size of the file. If the layer is LARGER than the image, then the layer
may add MORE to the size of the file than what would be indicated by
multiplying the width of the image by the heigth of the image by the number of
bits per pixel.

>2. As long as you don't resample, or add alpha channels there is
>nothing you can do that will change the image size?

You can change the number of bits per pixel, you can add layers which contain
content...

>3. Even if you add 25 layers, it won't affect the image size?

If the layers are empty, then no.

>4. Why does an image with an image size of 140megs only show as 70megs
>when I do a Get Info on it from the Finder/Desktop (File Manager)? Is
>there a difference between "image size" and "file size"

Photoshop (.PSD) files are compressed on disk, using a simple form of lossless
compression called "Run Length Encoding."

--
Biohazard? Radiation hazard? SO last-century.
Nanohazard T-shirts now available! http://www.villaintees.com
Art, literature, shareware, polyamory, kink, and more:
http://www.xeromag.com/franklin.html

jjs

2004-06-01, 12:14 pm

In article <1r4pb0ta57858fc1odu956h5dmllrkprl0@4ax.com>, David Haley
<junkmale221@hotmail.com> wrote:

> This day of Tue, 01 Jun 2004 09:08:48 -0500, john@xyzzy.stafford.net (jjs)
> proclaimed:

>
>
> And just what is your problem? What did I say that was wrong? :)

Just ribbing the newcomer. If you let the credits of PS scroll, you will
see Chris Cox's name in the credits. From time to time he swoops in here
with some good, terse words regarding PS's structure and behavior. A few
of his posts are quite memorable. Enjoy.

David Haley

2004-06-01, 7:14 pm

This day of Tue, 01 Jun 2004 10:15:54 -0500, john@xyzzy.stafford.net (jjs)
proclaimed:

>In article <1r4pb0ta57858fc1odu956h5dmllrkprl0@4ax.com>, David Haley
><junkmale221@hotmail.com> wrote:
>
>
>
>Just ribbing the newcomer. If you let the credits of PS scroll, you will
>see Chris Cox's name in the credits. From time to time he swoops in here
>with some good, terse words regarding PS's structure and behavior. A few
>of his posts are quite memorable. Enjoy.

Ah, just passing the newbie through the hazing, eh? I suppose that seems to be
common to just about every NG so I shouldn't be surprised to find it here. :)
I'm looking forward, then, to reading one of Chris Cox's posts.

-dhaley

--
~david-haley

Captain Blammo

2004-06-01, 11:14 pm

> Ah, just passing the newbie through the hazing, eh? I suppose that seems
to be
> common to just about every NG so I shouldn't be surprised to find it here.
:)

Yes, he's currently giving me a nice little haze too. I made the terrible
slip of asking how to write little scripts for PS, thus implying (since PS
scripting seems to be a little limited) that the program was less than
adequate.

Luckily, I was quickly corrected and shown that it is in fact *me* that is
inadequate. Whew, that was a close one.

Now I realise that an hour spent in Photoshop banging my head against the
proverbial wall is just somehow better than 5 minutes spent doing it the
easy and logical way. Jjs showed me the light.

Thanks jjs, I love you man

Ewan

jjs

2004-06-02, 4:14 am

In article <QQavc.52101$Np3.2259590@ursa-nb00s0.nbnet.nb.ca>, "Captain
Blammo" <eas6@nbnet.nb.ca> wrote:

> [...]
> Thanks jjs, I love you man

Group hug!

I'd be interested in your opinion of PS's scripting interface (Javascript,
some kind of VB, and Applescript.) Not too good for U*x veterans, but...

Captain Blammo

2004-06-02, 4:14 am

> I'd be interested in your opinion of PS's scripting interface (Javascript,
> some kind of VB, and Applescript.) Not too good for U*x veterans, but...

Well, I only just found out that a free download to enable scripting support
in Photoshop 7.0 was even available. For those that don't know, it's here:
http://www.adobe.com/support/downlo....jsp?ftpID=1536

Since I only just found it, I can't really say anything about it, but upon
preliminary examination it looks quite handy. The commands are easy to call,
and pretty well any scripting language gives you the ability to do what you
want with a minimum of hassle.

The main benefit is that it's much better to have Photoshop scripting than
having to use an external solution, just because Photoshop is best for most
editing, and it's annoying to have to switch out and copy files etc. Also,
I've used the PS commands enough to be annoyed at the slightly different
results an external program might give, and I know which commands are good
to use because I've been clicking their little buttons for years.

That said, the ImageMagick for linux has possibilities way beyond the scope
of PS. With some fiddling, you could automatically get images from cameras
or the internet, process them, and send them to displays, webpages and
printers anywhere in the world. Ok, possibly more than a little fiddling,
but still quite feasible.

Ewan

jjs

2004-06-02, 12:14 pm

In article <LCcvc.52146$Np3.2261598@ursa-nb00s0.nbnet.nb.ca>, "Captain
Blammo" <eas6@nbnet.nb.ca> wrote:

> [...]
> That said, the ImageMagick for linux has possibilities way beyond the scope
> of PS. With some fiddling, you could automatically get images from cameras
> or the internet, process them, and send them to displays, webpages and
> printers anywhere in the world. Ok, possibly more than a little fiddling,
> but still quite feasible.

You might look at PS's "droplets". As I mentioned a few days ago, droplets
can be called from the WindoZe command-line to process files passed as an
argument.

Captain Blammo

2004-06-02, 7:14 pm

> You might look at PS's "droplets". As I mentioned a few days ago, droplets
> can be called from the WindoZe command-line to process files passed as an
> argument.

Nice though they are, you still can't pass parameters to them (ie
"ResizeDroplet.exe -w 1024 -h 768 some_picture.jpg"), which greatly limits
your programmatic freedom. For instance, I couldn't determine what size I
want my image made somewhere else, then call PS with the resize command and
approriate parameters. The droplets basically have the same limitations that
the actions do.

It really is a shame that modern programs tend not to have any kind of
command-line interface to speak of these days. scripting is very nice, but
with full command line parameters you can hook a program's capabilities up
to all sorts of other programs and scripts. Thankfully, there's plenty of
linux command line stuff knocking about in case one ever needs it.

Ewan

jjs

2004-06-02, 7:14 pm

In article <Hnovc.52363$Np3.2275900@ursa-nb00s0.nbnet.nb.ca>, "Captain
Blammo" <eas6@nbnet.nb.ca> wrote:

> [...]
> It really is a shame that modern programs tend not to have any kind of
> command-line interface to speak of these days. scripting is very nice, but
> with full command line parameters you can hook a program's capabilities up
> to all sorts of other programs and scripts. Thankfully, there's plenty of
> linux command line stuff knocking about in case one ever needs it.

Could you cut your own parser which writes the javascript. Perl's alliance
in that regard might be useful. No?

Captain Blammo

2004-06-02, 7:14 pm

> > It really is a shame that modern programs tend not to have any kind of
but[color=darkred]
up[color=darkred]
of[color=darkred]
>
> Could you cut your own parser which writes the javascript. Perl's alliance
> in that regard might be useful. No?

Technically yes, though actual invokation would involve writing a javascript
file, opening PS, then activating the script from a menu using some
automatic mouse movement jiggery-pokery. I can't find any way to invoke
scripts apart from the menus anyway, no mention in the manual.

Good point though, PS is certainly the best in terms of the quality of image
manipulation, it might be worth kludging to be accessible via command lines
and auto-generated scripts. Not that I have any idea how to make the mouse
move and click on it's own....

It really is a shame the scripting support doesn't just let you start
scripts from the command line, as that would solve all the problems with
relative ease. Having to start the GUI at all is a bit of a drag really.

Ewan

-xiray-

2004-06-03, 7:14 pm

On Tue, 01 Jun 2004 02:19:11 -0700, David Haley
<junkmale221@hotmail.com> wrote:

>If you understand image size as in brute representation in memory, the yes, that
>is probably true. You need bytes to represent the pixels, empty or not. That
>being said, I'd be astounded if programs didn't use some kind of algorithm to
>represent large portions of empty or same-color pixels in just a few bytes.

Prepare to be astounded then because the TIF format does not do what
you think it should.

David Haley

2004-06-03, 7:14 pm

This day of Thu, 03 Jun 2004 19:34:03 GMT, -xiray- <do_not@e-mail.me>
proclaimed:

>On Tue, 01 Jun 2004 02:19:11 -0700, David Haley
><junkmale221@hotmail.com> wrote:
>
>
>Prepare to be astounded then because the TIF format does not do what
>you think it should.
>

With all due respect the above paragraph is *not* referring to file formats but
to in-program memory representation.

-dhaley

--
~david-haley