Slashdot Mirror
Viewers for Large Images?
mateub asks: "Before setting off to write something of our own, we have been looking for an image viewer that can deal with large (e.g. 10k by 10k pixel) CMYK TIFF images. Note that this is not necessarily the same thing as saying that the file is large, but usually it will be. A smart program could allocate enough memory to show the 1k by 1k pixels of a normal monitor and read other parts of the file when the user scrolls. Not fast, but functional. We've tried ImageMagick, and it isn't that smart--it runs out of memory even on my 1GB RAM, 4GB swap workstation. It appears The Gimp and xv can't even handle CMYK. Are there any programs that can display these images?"
xzgv is the viewer of my choice, it is fast and efficient, it should be able to handle these big files
But I seem to recall hearing from some people who work creating visual effects for movies that Discreet: Combustion is a very good software only solution for working with extremely high resolution images.
It's overkill because of the price, that fact that it is an editing tool, and that it is designed to work with video at higher resolutions than the still pictures you are dealing with, but it would probably work for what you want if you can't find anything else...
Photoshop does its own VM to handle the memory needed for the image. As far as I remember it needs four times as much disk space than the original picture (this is needed for things like filtering and undo).
I don't know of a cheaper alternative that would do the trick. If I had to write such an app, I would look into mechanisms to install a custom pager that would handle the image data - using the image file as backing store - this is basically what you describe (loading the parts that are needed), but integrated with the VM mechanism.
If the app needs some basic functionality like zooming, things are a little more tricky: lets say you want to dispay a 1/10 zoomed out version of the image, then you need to process the whole file to calculate the reduced image. As this is expensive, you would probably want to cache the result.
This could again be done using a custom pager, that simply clear the memory when the pages are swapped out, and regenerate the needed pages when the memory needs to be swapped in again.
If you decide to write the application yourself, and you are using an Intel architecture, then you might consider using the Intel Image Processing Library.
The library provides a set of low-level image manipulation functions in DLL and static form. A part of the API deals with tiling of big images, so that only the viewable fraction of the image is loaded in the memory. The library comes with a demo app that demonstrates its capabilities including the tiling of images.
The tiff spec originally used striped chunks of image, ie exactly what you might expect to be dumped directly from the buffer of a fax or scanner. (later they added square tiles, which made it easier to embed jpeg encoded images in tiff). While it is technically possible to encode the whole tiff in a single strip (of compressed image data), thus screwing any attempt at random access, the standard says you shouldnt do this and aims for small strips - in terms of memory.
This has nothing to do with how large the strips are in pixels though. If you viewer wanted to load a 100 pixel square region and the page width is 1M pixels, you will actually be forced to load at least 100x1M pixels into memory.
Bottom line is that in general tiff is a poor format for very large images. And while other image formats are different, they, too, are often not designed for random access to areas of a much larger image. If you really have large images then you should consider storing them in a different format, or even creating a client-server viewer so you don't have to install a gig of ram on the desktop of everyone who wants to look at the image. Depends on your app though. For photoshopping, just add more ram, for a db of x-ray images you would probably want to store images in a format designed for random access to small areas by remote client machines, and various thumnail levels for image navigation.
BTW I deal with A1 scans and I'm pretty sure the (proprietary and fairly crap) image viewer we use takes the client-server approach. I dont speak as an expert in this area but I have written software to convert TIFFs to other formats in the past.
-Baz
It supports just about any file type you can think of including video and audio as well as compressed archives and even scans unrecognized files.
It's available for PC and Mac but the mac version is more limited and slower than the pc counterpart. There's also a slimed down version of the original image viewer that is fast as lightning.
check it out
http://www.acdsystems.com
MoRe... LaTeR... -=PJK=-
While this topic is well outside my usual area of (in)expertise, I think these guys products might be able to help you out... That is, if you were not absolutely tied into the TIFF format for your viewable files. As others have pointed out, TIFFs are a poor format for very large images.
Anyway, LizardTech's technology is used by plces like the USGS and Library of Congress to allow instant access to very large scanned maps and other documents. In particular, you might want to check out their software aimed directly at working with big photos.
I've seen a demo of their software in action. An entire CD-ROM (or more) of overlapping images (aerial photography in this case) that were geographically positioned could be viewed using their software. You could pan & zoom in near real time, and this was about 4 years ago! Their software uses wavelet compression.
The software was only on Windows at the time, but according to their download page they have both a browser plug-in and standalone viewer for Linux.
I have a 10000 x 10000 pixel cmyk image open in photoshop right now, as I browse, on a PIII/600 laptop with 192 megs of ram using photoshop 5.5 set to use no more than 70% of available ram.... An image of that size is 381.5 megs.... photoshop really likes to have 3x the picture's size in ram (one for the image, one for working space and one for undo purposes) so if you have a machine with 2 GB of ram and 70% allocated to photoshop, you would be working in real time, as it is, I can successfully manipulate an image that large scrolling around and making edits, even on a laptop.
As far as the Apple goes..... don't fall into that trap... A P4/2GHz with 2 GHz of Ram and the fastest 2d video card you can manage to get your hands on (lots of companies have not been pushing 2d performance lately, but there are some good ones out there, I have always liked ATIs cards for 2d performance/price ratio.
resolution (72 vs 300 dpi) is a non concern, a 10000 x 10000 pixel image is still the same file size regardless of resolution, the physical size can will be radically different dependant on the resolution in ppi, 300 being about 33x33 inches, and 72 being a little over 4 times that in each dimension, but its the file size/memory requirement that you need to deal with not physical size.
Sometimes Open Source is great, sometimes, there just is no substitute for the commercial offerings. I love GIMP, its a fantastic program, for what it does, but photoshop has been refined over a lot fo years into what it is, and for professional image manipulation, nothing can touch it (especially in the CMYK arena)
Lest anyone think I am just talking out of my ass, I spent 12 years working in printing, 9 of them doing desktop publishing/photo reoutching/typesetting and illustration work for commercial printers. My opinion? a nice P4/2+GHz or Athlon 2000+XP or better yet a dual setup if you can afford it, 2 GB Ram, a nice fast 2d video card and photoshop any version 5 or better (though my favorite is still 6.0)
I reject your reality
Check out Remote View. It's a tool designed for really large satellite images, but can be used for a any standard type of image. This tool is optimized for HUGE images upwards of 1GB apiece. I've had a lot of luck with it.
You didn't specify an operating system, price or hardware concerns...
Sorry, editing error. I mentioned that in my first draft, started to go off on a tangent, deleted the tangent... Anyway:
Our application runs on Linux, HP-UX and soon, Cygwin on Windows. We have some Apple machines around as well, but most of our users won't, so Apple isn't really an option. Ideally, the viewer would run under the three OS's listed, but we could settle for a different viewer for Windows, for example.
adéu,
Mateu
"And we're happy here, but we live in fear, we've seen a lot of temples crumble..." - Concrete Blonde
If you're on an SGI, use the ImageVision libraries/tools. We were using it to process big images (60K x 20K x 5, 16 bits per channel) nearly 10 years ago. It will read as much of the image that is needed and will cache some of the tiles so going back over an area won't require another disk read. If the output is to an SGI video card, some image processing operations will be hardware accellerated. ImageVision homepage
the good ground has been paved over by suicidal maniacs
actually there are some hard and fast limits to image render sizes in imlib2. sorry to disappoint.
Geoff "Mandrake" Harrison
Some Random UI Hacker
If you're on a Wintel platform, Irfanview (www.irfanview.com) is a great freeware tool that can open damn near any format of image (some that other viewers can't) and is a small download. I've opened some pretty dang big images in there (a 42 meg jpeg that was ungodly huge), and it loaded fine (and it can open cmyk images and do basic manipulation, resizing, color adjusting, etc...). I've been using the program since version 1.2 and love it (it's at 3.61) and recommend it to anybody that needs a simple graphic viewer (it's a helluva lot faster than ACDSee).
Ignoranus: A person who is both stupid and an asshole.
You're thinking of local echo. I have, however heard that old apps may refer to this a half-duplex.
If you are going to do this sort of thing a lot, don't use TIFF. There are a few tiled formats around for GIS applications, and and hierarchical formats like JPEG2000 or PhotoCD should also be a reasonable choice (but not much tools support yet).
Of course, rather than writing your own, if you really need CMYK, why not add CMYK support to the Gimp? The Gimp already does the tiling and has lots of other useful features.
Its possible that you could utilize one of the source available versions from jpeg.org like jasper as a backend. You can specify cmd line options to get reduced resolution versions from the encoded files. This has the benefit that you'll never have to decode the data for the higher resolutions if you don't need it.
t.
Just FYI, Photoshop will support any image up to 30,000x30,000 pixels in size, I've done it personally on a 512MB box.
For 10k^2, and 1GB ram like you say, it shouldn't be a problem (after all 10k^2 CMYK is only 381MB uncompressed).
Stick with an industry standard, full-featured program unless you can't.
MadCow.
I used to have a sig, but I set it free and it never came back.
I haven't tried it on anything bigger than 2Kx2K, but it's really an excellent tool.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks