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

This day of 31 May 2004 21:43:28 -0700, (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

On 31 May 2004 21:43:28 -0700, (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

In article , David Haley
wrote:

[… snip Mr. Haley’s opinions regarding programming and Photoshop …]

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.

This day of Tue, 01 Jun 2004 09:08:48 -0500, (jjs)
proclaimed:

In article , David Haley
wrote:

[… snip Mr. Haley’s opinions regarding programming and Photoshop …]

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

In article , David Haley
wrote:

This day of Tue, 01 Jun 2004 09:08:48 -0500, (jjs)
proclaimed:

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? 🙂

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, (jjs)
proclaimed:

In article , David Haley
wrote:

This day of Tue, 01 Jun 2004 09:08:48 -0500, (jjs)
proclaimed:

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? 🙂

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$>, "Captain
Blammo" 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/downloads/detail.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

In article <LCcvc.52146$>, "Captain
Blammo" 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.

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

In article <Hnovc.52363$>, "Captain
Blammo" 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?

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?

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

On Tue, 01 Jun 2004 02:19:11 -0700, David Haley
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.

This day of Thu, 03 Jun 2004 19:34:03 GMT, -xiray-
proclaimed:

On Tue, 01 Jun 2004 02:19:11 -0700, David Haley
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.

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

-dhaley

—
~david-haley