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.....!

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 t
o
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 Photos
hop,
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 ima
ge
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' fo
r
every...single...pixel. (this is called line-length encoding if you care - i
t'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 su
re
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 pe
ople
choose the former (time over space) especially these days due to the widespr
ead
availability of memory.

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

-dhaley


>I'm confused.....!

--
~david-haley

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

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

>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 f
or
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 a
dd
to the size of the file. If the layer is LARGER than the image, then the lay
er
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 contai
n
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 lossle
ss
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

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.

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

> 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

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

> 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