How do I save/reload a 45GB image in PS CS?

Some versions of Windows have absolute file size limitations which can cause this. I thought too that CS has some maximum file size limitations considerably less than 45gig.
DM

"Douglas Gennetten" wrote in message

Seems like RAW is the only option (too large for tiff), but I am having problems re-opening large RAW files.

Thanks,

-Douglas

On looking at the help file, CS has an absolute limit of 300,000 x 300,000 pixels file size. This means a file size at 300 dpi of about 450 Gig!! Must be windows problem.

"Douglas MacDonald" wrote in message

Some versions of Windows have absolute file size limitations which can

cause

this. I thought too that CS has some maximum file size limitations considerably less than 45gig.
DM

"Douglas Gennetten" wrote in message

Seems like RAW is the only option (too large for tiff), but I am having problems re-opening large RAW files.

Thanks,

-Douglas

On 12-Feb-2004, "Douglas MacDonald" wrote:

On looking at the help file, CS has an absolute limit of 300,000 x 300,000 pixels file size. This means a file size at 300 dpi of about 450 Gig!! Must be windows problem.

300 dpi has nothing to do with file size. 300,000 x 300,000 x 3 = 270G

—
Tom Thackrey
www.creative-light.com
tom (at) creative (dash) light (dot) com
do NOT send email to (it’s reserved for spammers)

Not interested in this dpi verses pixels argument Tom. It’s purely a waste of breath.
Empty 16 bit file is over 500 gig. Put a few layers and images in it and it will grow. Your file size is 8 bit, 72 dpi.

"Tom Thackrey" wrote in message

On 12-Feb-2004, "Douglas MacDonald" wrote:

On looking at the help file, CS has an absolute limit of 300,000 x

300,000

pixels file size. This means a file size at 300 dpi of about 450 Gig!! Must be windows problem.

300 dpi has nothing to do with file size. 300,000 x 300,000 x 3 = 270G
—
Tom Thackrey
www.creative-light.com
tom (at) creative (dash) light (dot) com
do NOT send email to (it’s reserved for spammers)

In article <6RWWb.53843$>, Douglas
MacDonald wrote:

Not interested in this dpi verses pixels argument Tom. It’s purely a waste of breath.

Hold your breath while typing and you won’t waste your breath. Tom is right. You can’t tell the size of an image by the dpi.

<http://homepage.mac.com/stmoody/.Pictures/Ebay/100.jpg> is a 100dpi image.

<http://homepage.mac.com/stmoody/.Pictures/Ebay/1200.jpg> is a 1200 dpi imiage.

But these are both the same picture. They are both the same image size. They are both the same file size.

The dpi of an image has nothing to do with the size of the file.

Same comment returned to you Steve. It’s a non issue and a total waste of time. You are wrong, I am wrong but I am right too just as you are. It all depends on what interpertation you put on a measurement. I simply won’t enter into a useless discussion on the merits of choosing a measurement. I will however welcome discussions about (almost) any other subject. OK? DM

"Steve Moody" wrote in message

Hold your breath while typing and you won’t waste your breath. Tom is right. You can’t tell the size of an image by the dpi.

snipped because it’s as irrelivant as the question: how big is a pixel and a dot?

On 12-Feb-2004, "Douglas MacDonald" wrote:

"Tom Thackrey" wrote in message

On 12-Feb-2004, "Douglas MacDonald" wrote:

On looking at the help file, CS has an absolute limit of 300,000 x

300,000

pixels file size. This means a file size at 300 dpi of about 450 Gig!!
Must be windows problem.

300 dpi has nothing to do with file size. 300,000 x 300,000 x 3 = 270G

Not interested in this dpi verses pixels argument Tom. It’s purely a waste of breath.
Empty 16 bit file is over 500 gig. Put a few layers and images in it and it
will grow. Your file size is 8 bit, 72 dpi.

Interested or not, Douglas, the fact is you are wrong.

You can’t tell that ‘my’ file is 72dpi it could be any dpi. Do you see 72 in the calculation anywhere? bits per color, color chanels per pixel, pixel dimensions, layers, compression, and overhead all affect file size. The number of pixels per inch does not, its only role is to determine the dimensions of the image when printed.

The file I described is 8bits/color, 3 colors/pixel, 300Kx300K pixels, uncompressed, 1 layer. If you make it 16 bits/color the size doubles. If you convert it to CMYK (4 colors/pixel) the size increases by 1/3. If you change the pixel dimensions to 150Kx150K the size decreases by 3/4. If you change it to 1ppi or 1000ppi the file size remains exactly the same.

Pixels vs ppi (dpi) is analogous to miles vs mph, the number of miles between Seattle and San Francisco remains constant no matter how fast or slow you drive.

—
Tom Thackrey
www.creative-light.com
tom (at) creative (dash) light (dot) com
do NOT send email to (it’s reserved for spammers)

In article <lSZWb.54003$>, Douglas
MacDonald wrote:

Same comment returned to you Steve. It’s a non issue and a total waste of time. You are wrong, I am wrong but I am right too just as you are. It all depends on what interpertation you put on a measurement. I simply won’t enter into a useless discussion on the merits of choosing a measurement. I will however welcome discussions about (almost) any other subject. OK?

You’ve succeeded in showing where your depth of Photoshop knowledge does not reach. And it’s basic kowledge at that. No need to reply. I don’t plan on reading your misinformation.

From: "Douglas MacDonald"

Same comment returned to you Steve. It’s a non issue and a total waste of time. You are wrong, I am wrong but I am right too just as you are.

DPI only has meaning when you scan or print, it’s irrelevant when you view a file on the screen.

Steve and Tom are right, you were wrong. Let it go …

"Douglas Gennetten" wrote in message

Seems like RAW is the only option (too large for tiff), but I am having problems re-opening large RAW files.

Frankly, I think you are putting us on. What is this image that requires 45gb? And you _can_ work on an image as sections. No excuses.

In article <6RWWb.53843$>, Douglas
MacDonald wrote:

Not interested in this dpi verses pixels argument Tom. It’s purely a waste of breath.

Huh? But Tom was absolutely correct. Output resolution has nothing to do with file size. Period. What in blazes are _you_ talking about (i.e., "dpi vs ppi")?????

Phil

"Tom Thackrey" wrote in message

On 12-Feb-2004, "Douglas MacDonald" wrote:

On looking at the help file, CS has an absolute limit of 300,000 x

300,000

pixels file size. This means a file size at 300 dpi of about 450 Gig!! Must be windows problem.

300 dpi has nothing to do with file size. 300,000 x 300,000 x 3 = 270G
—
Tom Thackrey
www.creative-light.com
tom (at) creative (dash) light (dot) com
do NOT send email to (it’s reserved for spammers)

"Douglas MacDonald" …

Same comment returned to you Steve. It’s a non issue and a total waste of time. You are wrong, I am wrong but I am right too just as you are. It all depends on what interpertation you put on a measurement.

Nonsense. Filesize does not depend on dpi or ppi at all, period.

In fact, the dpi is just an arbitrary number stored in the image. If an image is 72 dpi, it just means it has a value "72" somewhere in the file, and you can freely change it to 150 or 1000 without changing the image (or its filesize).

It’s nothing more than a hint to be used when printing. And in my opinion, the dpi could have been left out of images at all, since it’s usually at the layout / document editting stage where you determine how large (in cm/inches) an image will be on paper, thereby ignoring its original dpi.

snipped because it’s as irrelivant as the question: how big is a pixel and a dot?

In terms of disksize (what this topic was all about), how big a pixel is depends on the color format and bitdepth, and NOT on dpi / ppi.

Enable the large document format and save that way.

But as explained in the manual: older versions of Photoshop can’t read it, and neither can other applications (because most of them don’t go over 2 Gig per file).

Chris

In article , Douglas Gennetten
wrote:

Seems like RAW is the only option (too large for tiff), but I am having problems re-opening large RAW files.

Thanks,

-Douglas

Frankly, I think you are putting us on. What is this image that requires 45gb? And you _can_ work on an image as sections. No excuses.

Actually, no. And here is some hard evidence:
www.gennetten.com/FortCollinsAerial

No excuses? Well, In fact I have one. My goal is to process this entire 45GByte image as one contiguous zoomview. Cannot be don "as sections".

Doug

Same comment returned to you Steve. It’s a non issue and a total waste of

This issue resurfaces interminably. DPI, in and of itself, has nothing to do with file size. In fact, for many images DPI is totally meaningless. Take a digital camera image: where are the "inches" in the DPI?

Back on topic… the inital problem I was having was difficulty SAVING my 45Gb file. No problem creating and processing it in PS8. I did however, find the answer to my own question. It turns out in Preferences there is a check box (unchecked by default) for enabling "large files" using the PS8-only ".psb" file extension. Using this, I’m having no trouble at all opening, editing and resaving my gigapixel image.

Thanks,

Douglas Gennetten

In article ,
(Douglas Gennetten) wrote:

Actually, no. And here is some hard evidence:
www.gennetten.com/FortCollinsAerial

No excuses? Well, In fact I have one. My goal is to process this entire 45GByte image as one contiguous zoomview. Cannot be don "as sections".

Well, it’s about time others took up Zoomview. It’s been out forever and part of PS since V7. The CS version, if that is what I am seeing, looks better.

I am guessing the large file option of CS will not help with this, correct? In that case, you will have to find a way to section out the job. The Zoomview that I knew pared the file in a definite way so the image can be sectioned. That, with some creative HTML should work.

Tell us about the picture. Do you know the technical details?

www.gennetten.com/FortCollinsAerial

….

Tell us about the picture. Do you know the technical details?

Currently, this is 20 2 Gbyte sections. I’m in process creating a new version that is 4 10 GByte sections. I had hoped for one contiguous 40 Gbyte version but Adobe’s viewpoint exporter fails around 10Gb.

The original image is 2-pixels-per-meter captured with high altitude aircraft.

Douglas Gennetten wrote:

www.gennetten.com/FortCollinsAerial

…

Tell us about the picture. Do you know the technical details?

Currently, this is 20 2 Gbyte sections. I’m in process creating a new version that is 4 10 GByte sections. I had hoped for one contiguous 40 Gbyte version but Adobe’s viewpoint exporter fails around 10Gb.
The original image is 2-pixels-per-meter captured with high altitude aircraft.

Out of curiosity where did you get the image from, I never knew people would have images that big let
alone be trying to work on them. The spec of the machine you are using must be pretty high just to even
open the image in the first place.

Stuart

—

Stuart …

Out of curiosity where did you get the image from, I never knew people would have images that big let
alone be trying to work on them. The spec of the machine you are using must be pretty high just to even
open the image in the first place.

Stuart

It is an aerial photo of the type commonly provided to local municipalities for government planning. Captured at a remarkable 2 pixels per meter, high-altitude aircraft and gigapixel stitching make this a tedious capture process.

The machine I am using is a 4-Proc 2Ghz 2Gb Win2K server with several 200Gb drives attached – each having 20-40GB free. I spread the Photoshop scratch over four drives and reduced the History setting to the minimum of "1".

The original is a single ".sid" file, opened in the MrSid viewer (lizardtech.com) where 4Gb tiff segments can be exported 4Gb at a time.

A lot of time was spent waiting between steps in this cycle: canvas-expand base image; open next 4Gb tiff; drag onto base as new layer; position layer (surprisingly fast an easy with ‘snapping’ behavior); flatten base image.

Occasionally, I did a save in the new .PSB large image format. During this save, it’s interesting to watch the performance meters for the 4 procs and the variation in memory usage. Lots of antics going on.

This is quite likely the largest displayable image being delivered over the web. It stretches the newly-enlarged (thanks to PS8) limits of Viewpoint Zoomview export.

The new much-improved version will hopefully go live in a few days — as soon as I can get the 200K+ files zipped and ftp’d to my generous ISP.

Douglas Gennetten
www.gennetten.com/FortCollinsAerial

In article ,
(Douglas Gennetten) wrote:

[…]
This is quite likely the largest displayable image being delivered over the web. It stretches the newly-enlarged (thanks to PS8) limits of Viewpoint Zoomview export.

I’ve done a lot of Zoomview work for one of our departments. I’m glad to see someone else using it and I look forward to seeing your site. Spread the word.

(FWIW, Zoomview’s image parsing is pretty easy to figure out, and there are other tools as useful without requiring a plug-in on the client machine. But Zoomview is just so sexy.)

"Douglas Gennetten" wrote in message

municipalities for government planning. Captured at a remarkable 2 pixels per meter, high-altitude aircraft and gigapixel stitching make

Correction: captured at 2 pixels per FOOT. When you zoom in, you can actually make out
individual high voltage power lines and their shadows.

Thanks for that, I never knew people would be using images that size, so I suppose there will be plans to
upgrade to 64bit systems at some point. I would think the extra memory capacity would be very appealing
when working on images of that size.

Stuart

Douglas Gennetten wrote:

Stuart …

Out of curiosity where did you get the image from, I never knew people would have images that big let
alone be trying to work on them. The spec of the machine you are using must be pretty high just to even
open the image in the first place.

Stuart

It is an aerial photo of the type commonly provided to local municipalities for government planning. Captured at a remarkable 2 pixels per meter, high-altitude aircraft and gigapixel stitching make this a tedious capture process.

The machine I am using is a 4-Proc 2Ghz 2Gb Win2K server with several 200Gb drives attached – each having 20-40GB free. I spread the Photoshop scratch over four drives and reduced the History setting to the minimum of "1".

The original is a single ".sid" file, opened in the MrSid viewer (lizardtech.com) where 4Gb tiff segments can be exported 4Gb at a time.

A lot of time was spent waiting between steps in this cycle: canvas-expand base image; open next 4Gb tiff; drag onto base as new layer; position layer (surprisingly fast an easy with ‘snapping’ behavior); flatten base image.

Occasionally, I did a save in the new .PSB large image format. During this save, it’s interesting to watch the performance meters for the 4 procs and the variation in memory usage. Lots of antics going on.
This is quite likely the largest displayable image being delivered over the web. It stretches the newly-enlarged (thanks to PS8) limits of Viewpoint Zoomview export.

The new much-improved version will hopefully go live in a few days — as soon as I can get the 200K+ files zipped and ftp’d to my generous ISP.

Douglas Gennetten
www.gennetten.com/FortCollinsAerial

—

Enable the large document format (.PSB) in preferences, then select it in the save dialog.

Chris

In article , Douglas Gennetten
wrote:

www.gennetten.com/FortCollinsAerial

…

Tell us about the picture. Do you know the technical details?

Currently, this is 20 2 Gbyte sections. I’m in process creating a new version that is 4 10 GByte sections. I had hoped for one contiguous 40 Gbyte version but Adobe’s viewpoint exporter fails around 10Gb.
The original image is 2-pixels-per-meter captured with high altitude aircraft.