Viewers for Large Images? 64
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?"
Re:Photoshop on an Apple (Score:1)
So if you maxed out your 256MB RAM in Photoshop and it isn't a "smart program" he will need 4GB RAM.
Again it all boils down to whether Photoshop is "smart" or not.
Re:Photoshop on an Apple (Score:3, Informative)
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)
Re:Photoshop on an Apple (Score:2, Interesting)
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
xzgv (Score:3, Interesting)
Re:xzgv (Score:5, Informative)
Now adapts rendering method for big images. When the number of pixels in the image exceeds the value set by image-bigness-threshold (as set in config file or on command-line, defaulting to 2 million pixels), it's drawn piece-by-piece on demand rather than all-at-once. The all-at-once behaviour is worth keeping around for smaller images, as it gives much nicer scrolling - but for big images it's just impractical, hence this feature.
Which sounds like just the ticket. You could also have linked to the website [browser.org].
Here ends sydb's lesson in karmah whoring.
Re:xzgv (Score:1)
Also, this site [linux.com] has some information on the software suggested: xzgv.
Hopefully you will find this useful.
Re:xzgv (Score:1)
Having looked at xzgv, it looks like the main problem would be getting it running on HP-UX, Windows and Linux, which are our platforms. I edited this important information out of my original post, sorry.
So I'm back to thinking that we could write something more easily with the Java Advanced Imaging library, or libtiff. What do you think?
gràcies,
Mateu
Re:xzgv (Score:2)
I've stopped using GQView since I read the original post...
Re:xzgv (Score:1)
adéu,
Mateu
This is overkill... (Score:3, Insightful)
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...
viewing large CMYK Images . . . (Score:1)
http://www.novadesign.com/fxinfo.htm
.
Photoshop and Virtual Memory (Score:3, Informative)
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.
Re:Photoshop and Virtual Memory (Score:2)
Of course, it would suck if they wanted to manipulate the data, but for viewing only it might be a good idea.
Re:Photoshop and Virtual Memory (Score:1)
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).
Almost right. This setting is adjustable, under Preferences - Memory & Image Cache. Change the cache levels from 4 to say 1 if you're working with large images (eg. 4000dpi medium format RGB slide scans - ooooh Nikon Coolscans rock [grin]). You can also set the amount of physical memory available to Photoshop here, as well as which disks to use for swapping under Plug-ins & Scratch Disks.
Oh, also worth mentioning is that you can purge this cache (and the clipboard, etc.) through "Edit - Purge - All" which is handy if you're swapping-out already and are about to do an memory intensive operation.
I don't know of a cheaper alternative that would do the trick.
Might be worth taking a look at Photoshop Elements [adobe.com], I think you can get this as cheap as $40USD or so if you hunt around. Don't think it supports CMYK though, but then if you're working with press images you'll probably need the full Photoshop anyway.
The Intel Image Processing Library supports this (Score:4, Informative)
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.
Imlib2 ? (Score:1)
Methinks Rasterman and the Enlightenment team may not have had this in mind, but if they did, it'll work.
That previous post about the VM being important is spot on too.
Re:Imlib2 ? (Score:2)
Not easy for striped tiff. (Score:3, Informative)
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
Re:Not easy for striped tiff. (Score:1)
You are right, in general. Fortunately, we need the viewer for an application we are developing that outputs TIFF. So we can control the strip length as well.
We will look into changing formats if necessary, but as this application is for in-house use and most of our users will have fast computers with lots of memory, reading in, say, 900 TIFF strips that are 10,000 pixels wide should be acceptable in most cases. Regardless, you are correct that another approach would be better. I have thought about changing to tiles--it would be tricky, but possible, for this application.
I will think about your client-server idea, though. Thanks.
adéu,
Mateu
ACDSee image browser and graphics manipulation (Score:2, Informative)
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 [acdsystems.com]
http://www.acdsystems.com
Re:ACDSee image browser and graphics manipulation (Score:4, Informative)
ACDSee does choke, however, if the directory has a few thousand images in it. We were training image recognition algorithms and a typical truth category might have as many as 10,000 images. With this many images in a directory, ACDSee became unuseable because it constantly would update the directory contents, filesizes, filetypes (of a network drive) and wouldn't allow user input until it was finished.
Re:ACDSee image browser and graphics manipulation (Score:1)
For example the "Duplicate File" finder won't even load more than 32k images.
OT: anyone knows of a good "find duplicate files" tool ?
Re:ACDSee image browser and graphics manipulation (Score:2)
Conclusions:
1. GNU Tools are the shiznit when it comes to managing large batches of data (CLI beats out GUI every time).
2. Even when GNU Tools are difficult to use (i.e. 32K files), there are work-arounds and they still blow the pants off of GUI file management tools.
I used to get all upset, because NONE of the "File-managers" work worth a darn when it comes to actually managing files!
MrSIDs (Score:2)
While this topic is well outside my usual area of (in)expertise, I think these [lizardtech.com] 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 [lizardtech.com].
I Second MrSID (Score:2)
The software was only on Windows at the time, but according to their download page [lizardtech.com] they have both a browser plug-in and standalone viewer for Linux.
Look at ERMapper ECW too (Score:1)
The difference is the free ECW SDK can do decompession of any size and compression of images up to 500Mb. If you want to compress larger than 500Mb you have to buy the software.
Last I checked, MrSID's free kit could only decompress, any compression required buying the software.
ECW is a little easier to try out.
ERMapper [ermapper.com]
Re:I Second MrSID (Score:2)
RealTimeImage for large images via Int(er|ra)net (Score:1)
Have a look at their Demo [realtimeimage.com]. Viewing 0.5G images on your local computer is very impressive.
Re:RealTimeImage for large images via Int(er|ra)ne (Score:1)
Large Image Reader (Score:2, Interesting)
what platform? (Score:2)
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 [sgi.com]
Re:what platform? (Score:2)
Another vote for Photoshop (Score:1)
Re:Another vote for Photoshop (Score:2)
You're thinking of local echo. I have, however heard that old apps may refer to this a half-duplex.
Irfanview (Score:2, Informative)
Irfanview is *nice* (Score:2)
Hows 21600x21600? (Score:1)
Check out the Blue Marble [nasa.gov] satellite images from NASA! They're huge and really sweet. You can see individual sand dunes on the Sahara!
How about MrSID (for displays of maps, et al.)? (Score:1)
Is that the kind of thing you had in mind?
If so, cf:
http://www.lizardtech.com/
the short answer... (Score:2)
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.
Re:the short answer... (Score:1)
TIFF has a tile format as well. Is there something better about the JPEG2000 or PhotoCD formats over the TIFF one? Especially given that TIFF tool support is quite broad.
But really, the format elegance doesn't matter if an intelligent viewer doesn't exist that knows not to try and read the whole file into memory. Are there viewers like this for JPEG2000 or PhotoCD?
From what I read a few months ago, adding CMYK support to the GIMP, while desirable for the whole graphic arts industry, would be heroic amounts of work. Has the situation improved? Is anyone working on it? How would that compare to the work needed, say, to use the Java Advanced Imaging library (here [sun.com]) to write a viewer?
adéu,
Mateu
Re:the short answer... (Score:2)
The gimp's web page does not inspire confidence in their Windows stability--or are they just being modest?
I've always found the win32 port to be rock solid for me, but I'm not graphics professional, and I only run 98. I've never tried it under other platforms.
Though if all that's needed is a viewer, not an editor, Xzgv is great for big images. GTK has been ported to Windows (enough for Gimp to run, anyway) and it's probably less work to add CMYK to such a small program than Gimp.
With Xzgv on my puny K6-400 with 384MB RAM, I can load 50MB jpegs and tiffs in under 30 seconds, and panning is done in realtime. A modern workstation should handle bigger files even faster. Might be worth the effort to adapt it if adding CYMK doesn't break the speed.
Re:the short answer... (Score:2)
Both JPEG2000 and PhotoCD are not merely tiled, they are hierarchical: you can extract a complete, scaled down view of the image without every looking at the high resolution version. You can also make some global adjustments (color, cropping, etc.) without touching every pixel. And for viewing detail, only small portions need to be decompressed.
From what I read a few months ago, adding CMYK support to the GIMP, while desirable for the whole graphic arts industry, would be heroic amounts of work.
It doesn't look that hard to me. The GIMP already has support for arbitrary numbers of channels. CMYK is just a four-channel image. All you would need to do is write code that loads and saves it, and some code that converts between CMYK and RGB on the fly for display and RGB-based filters.
I think the main reason this hasn't happened is because nobody who understands color can figure out why anybody would want to do such a thing, or even what "viewing or editing CMYK" is even supposed to mean. Just convert to RGB and use RGB tools. Conversions to CMYK are best left to the device drivers that actually do the printing. What the Gimp needs much more than CMYK is 16bit support, IMO.
Well, the Gimp also has the problem for us of requiring lots of work to get it running on HP-UX, and we would also need something for Windows. The gimp's web page does not inspire confidence in their Windows stability--or are they just being modest?
I have had no problems with the Gimp on Windows, but it is a slightly older version. Why not just download it and give it a try? As for HP-UX, "configure" generally works pretty well, but HP-UX is also pretty weird.
Your best bets for high-end graphics (unless you want to pay an arm and a leg) are MacOSX, Solaris, and (for free or research software) Linux.
jpeg2000 (Score:2)
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.
mac (Score:1)
Photoshop supports up to 30k^2 pixels (Score:2)
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.
Irfanview? (Score:1)
BTW: What os?
Java Advanced Imaging (Score:1)
It offers some pretty cool tiling caching strategies for displaying large images. We've written an app that opens up images that are in the order of several hundred MB, and it handles them pretty well.
Maybe IRAF could do (Score:1)