[3D Rendering Tutorial]
Tom Arah looks at the developments in image file formats.
In RW67 I looked at the holy trinity of bitmap file formats: TIFF for print images, JPEG for photographic Web images and GIF for flat colour Web images. As we saw, each format has its own special strengths that suit it for its particular role, but none is perfect. Rather their main use is as exchange standards, common denominators that can be used reliably with different programs and different workflows without the compatibility problems of application-specific formats. Increasingly, however, both print and Web designers are looking to push the envelope and many new file formats are being devised to meet the new demands and perhaps to knock the current standards from their pedestal.
For images destined for print the fundamental requirement is good colour support. It is by providing this that the TIFF format, with its support for RGB, Lab and especially CMYK colour models, established itself. However, theres much more to successful print than just storing pixel values. In particular its important to recognise that photographic images are unlikely to be printed directly from their originating bitmap editor, but instead must fit into a wider print-oriented workflow. This immediately requires additional functionality such as DTP-based colour management and compositing capabilities.
In fact, although the TIFF format was devised long before such issues arose, its extensible tag-based nature has enabled it to be adapted to the new requirements. You can embed "non-image data" within TIFFs, for example, by using Photoshops File>Info command to add keywords, caption and so on. Since version 5, Photoshop has also defaulted to embedding an ICC profile into any TIFF that it produces describing the current RGB or CMYK colour space. Future releases of the major DTP applications will be able to use these profiles to automatically adjust pixel values where necessary to provide consistent device-independent colour.
As well as embedded textual information, the TIFF format can also accommodate extra image data as alpha channels. When working within Photoshop these alpha channels can be used for storing pixel-based selections, but are even more useful within XPress and now InDesign 1.5 where they can be used for generating a vector clipping path. Clipping paths define the outline of the current bitmap image that will be sent to the output device and are essential for creating DTP-based designs in which imported photographs arent necessarily rectangular. In fact the TIFF format is also able to cope with the simple vector information necessary to define the clipping path so that you can store the intended final shape for your composited image either as an alpha channel or as a path.
In a DTP program such as XPress the TIFFs ability to store clipping paths and alpha channels opens up layout possibilities.
The TIFF format has proved surprisingly adaptable within high-end DTP-based workflows, but there is another format that was actually designed from the ground up to fill this role the EPS (Encapsulated Postscript) format. As its name suggests, each EPS image is made up of the same Postscript commands that will be eventually be sent to the Postscript-based output device. This means that when producing the final output, the host application can simply merge the EPS information into the Postscript stream - the only parameters that the DTP package needs to read and control are those that define the EPS bounding boxs size and position.
The most obvious strength of the EPS formats programmatic base is that it can describe vector information which is why the format is usually identified with drawing rather than photo-editing packages. In fact the EPS is just as capable of handling bitmap information. Save an EPS from Photoshop and open the resulting file into a text editor and youll see how this is done. At the top of the file are the header comments including the all-important %%BoundingBox parameters. Next comes a relatively short block of Postscript commands which does the actual drawing, scaling and cropping of the image and then comes the bitmap data. This graphics screen representation consists of a stream of hexadecimal digits (0-F) in which each byte of image data ends up as two bytes of code.
The advantage of the format is its focus on successful print. As with TIFF this includes support for essential features such as colour management, clipping paths and colour modes such as Lab and CMYK, but EPS takes things further. Using the DCS 2.0 (Desktop Colour Separation) version of EPS developed by Quark, for example, you can create multichannel separations including multiple spot colours. Alternatively using the vanilla EPS format you can control individual images halftoning requirements and create duotones, tritones and quadtones where images are converted to grayscale and then recoloured depending on their tonal curve. This is useful not just for special effects but for maximizing the impact of two colour budgets and producing the richest possible photographs.
The Postscript-based EPS is the only format capable of handling such print-oriented formats as spot colour duotones.
Unfortunately EPS focus on eventual output is also its huge weakness. The use of 7-bit ASCI code, for example, ensures readability and maximum portability but is criminally wasteful for an exchange medium a typical 600 x 400 image with 700k of uncompressed pixel data, for example, produces a TIFF of under 500k but an EPS of around 2MB. Far worse is the fact that the data in the image only makes sense when interpreted by a Postscript device. Thats fine for high-end imagesetters but no use at all for non-Postscript devices such as inkjet printers and, far more importantly, displays. At its worst this means that your EPS image will print perfectly as imageset colour separations, but you wont be able to proof it or even see it onscreen in your DTP application!
The end result is that while the EPS format is in many ways ideal for high-end print workflows, it is atrocious for onscreen design. Adobe attempted to tackle the problem and with Postscript Level 2 provided the option to store bitmap information in binary and even JPEG format. More importantly it allowed a preview TIFF image to be embedded in the file which appears onscreen and is sent to non-Postscript printers, but is replaced by the Postscript data when output to supporting devices. These workarounds certainly help but have led to compatibility problems and dont provide a total solution. After all, why would you settle for a poor quality 8-bit TIFF preview when in most cases a single truecolour TIFF will do everything that you need?
Originally Adobe thought that the EPS formats fundamental viewing problem would be solved by the integration of its Display Postscript technology at the OS level, but the overheads on this proved just too great to be practical. Instead Adobe came up with a new file format, PDF (Portable Document Format), that incorporated all the main benefits of EPS without the downsides. The PDF, while built on exactly the same Postscript print-oriented architecture, offers in-built image compression (JPEG or lossless LZW) and turns onscreen display from a problem into an advantage. In particular double-clicking on any PDF automatically opens it up into the ubiquitous Acrobat Reader program for viewing.
This tie in with Acrobat technology has tended to mean that PDF is seen as a document format rather than a bitmap format. In fact the PDFs bitmap support is impressive. Photoshop 5.5 can save RGB, grayscale or CMYK images in PDF format complete with control over JPEG or lossless LZW compression. Within a supporting program like InDesign you can then link to or embed the resulting PDFs just as you would with TIFFs. The advantage of being able to bring in vector PDFs from Illustrator and bitmap PDFs from Photoshop and saving them as multiple page document PDFs from InDesign which can then be sent direct to any Postscript Level 3 device are clear, with one format encompassing the entire design-to-print workflow.
PDFs are associated with Acrobat documents but can also act as an advanced bitmap file format.
PDFs importance as a bitmap file format will certainly increase but at the moment it remains in limbo, falling between two stools. To begin with it doesnt yet offer all the high-end print capabilities of EPS such as duotones. At the same time its strong print focus means that, while it does offer clipping paths, it doesnt yet offer alpha channels. This is particularly important as nowadays designers expect to be able to take full control of both vector and bitmap images within their DTP environment. Its no longer good enough just to have rectangular boxes linking to external bitmaps. Nowadays images are live and integral parts of the overall design process.
Increasingly then image editability is becoming important. The obvious way of maintaining maximum information and maximum editability is to stick with the native application-specific format. Of course it was to avoid this go-it-alone anarchy that file format standards had to be developed in the first place, but the situation with bitmap images is quite special. Currently the vast majority of designers are working on their images in Photoshop and then exporting them to TIFF to use in their DTP application. Why not just cut out the middleman and support the industry standard Photoshops PSD format directly?
After all the format is well known. The core format PSD 3.0 format is built on a short header specifying the image size and colour channels and then three information sections called the Colour Mode Data Block, Image Resources Block and Layer and Mask Information Block defining features such as duotone settings, channels and paths and layer opacity and blend mode respectively. After that comes the image data. Naturally the PSD format can support all the advanced features weve already looked at such as duotones, clipping paths and channels but it also offers one feature that no other file format does. While every other format must be flattened on export, PSD is the only format that supports layers. Any program that supports PSDs directly can then leverage this layer information as Adobe ImageReady and Deneba Canvas show. Currently the DTP support is fairly basic but the possibility of changing image blend modes or editing layer text or tweaking adjustment layers depending on the actual spread in which the image appears is creatively mouthwatering.
Maximum editability is maintained by directly supporting Photoshops own multilayered PSD format.
In some ways PSD, as the native format of the most powerful and overwhelmingly dominant photo-editing application, is the natural ideal for a bitmap image format. However it also has serious limitations. In particular the fact that PSD is an application-specific format is a huge drawback to whole-hearted support from non-Adobe applications. And, while the full benefits of the format arent being leveraged, using PSD as an exchange standard is overkill. Currently then the situation is split. TIFF still provides all that is needed for most day-to-day DTP work, EPS fills the niche role for advanced print work, PDF is developing for future integrated workflows and PSD support holds out the potential for maximum power.
So much for current print-oriented workflows, but what about the very different requirements of the Web? As we saw in issue 67, two bitmap file formats are dominant here: the JPEG with its range of lossy compression tactics for squeezing every last byte out of continuous tone photographic images and the simple indexed GIF format for logo-style images with less than 256 colours. Surprisingly, however, both formats simply emerged into these crucial roles with no preplanning. When the question of LZW licensing arose to threaten the free use of the all-important GIF, the W3C took the opportunity to set up a committee to develop a new Web-optimised bitmap format from scratch.
The result was PNG (Portable Network Graphics). The format is deliberately simple with a header "chunk" followed by a palette chunk for indexed images, the image data chunk and then an image trailer chunk to mark the end of the image. In addition optional "ancillary" chunks can handle chromaticity, gamma, text data and so on. The image data is either indexed for 1 to 8-bit images or is stored as RGB data up to a 16-bit depth with an optional 8-bit alpha value. Compression is based on a variation of Phil Katzs Deflate system and is optimized by pre and post filtering the image. Various predictive filters are built in to the standard such as Sub which stores the difference between the current pixel and the pixel to its left, Up which compares it to the pixel in the scan line above and Adaptive which uses the best scheme for each scan line. The result is a compression scheme which adapts to the individual image so that while vertical or diagonal lines are difficult to compress in a GIF, in a PNG they can be handled as efficiently as horizontal areas of repeated colour.
The result is a format that can efficiently and losslessly handle images ranging from bi-level line-art through to state-of-the-art 48-bit photographic images. Moreover PNG offers some unique advantages. The format doesnt just support a transparent key colour as GIF does but also, through its alpha mask, offers true variable transparency. Likewise the format doesnt just support colour profiling but also enables gamma information to be embedded so that colours can be kept consistent across different platforms such as the Mac and PC. The format is also easily extensible as Macromedia has (rather confusingly) shown by making PNG the native format for its largely vector-based Fireworks program.
PNG can handle full colour or indexed images and offers various compression strategies depending on the individual image.
Even with these advantages, however, the format has yet to take off. To begin with theres just no way that lossless compression can come near the file size reduction that JPEG offers. PNGs limit to single images also gives GIF89a an advantage in terms of animated GIFs. The real problem though is support. Theres not much point in a Web format if you cant see it and only the most recent browsers support PNG natively. The biggest threat of all, however, is that PNG has already been superceded. The formats main use would be as a GIF replacement, but theres actually already a much stronger alternative. The typical logo-style images and buttons that GIFs are primarily used for would actually be much better handled as vectors. And thats exactly what Macromedias Flash SWF format currently enables.
Even more important as a potential replacement for GIFs and SWFs in the future is the advent of the W3C-devised SVG (Scalable Vector Graphic) format. I looked at this in detail in RW61 and as I said then its important not to get too carried away by a format that is only just coming off the drawing board, but the potential is enormous. What makes the format so exciting is that it is a truly open standard written in XML (Extensible Markup Language). Effectively this means that each image is built up programmatically in the same way that Postscript describes page layouts and images. Also like Postscript the SVG markup language enables bitmap data to be handled as well as vector, but then breaks new ground taking the format into new areas of scriptable animation and interactivity.
The XML-based nature of SVG owes much to the EPS format and could be the model for a future universal design file format.
This is exciting enough in the near term but in the longer term it opens up even more power. The real advantage of XML is not just that it is open but that it is extensible. New public features can be added to the core standard without affecting backward compatibility as can private features. The nearest parallel is to current Web apps which all work with universally readable HTML files but which also contain application-specific features, such as private tags for maintaining library items. Applying the same idea it could mean that in the future all design applications whether drawing, photo-editing, DTP, Web or multimedia focused could be saving their files to a single XML-based design file format.
The benefits would be enormous. Thanks to the formats universally understood architecture its files would be immediately viewable through the browser/OS and also capable of producing highest quality output through devices optimised to the markup language. Effectively SVG and PDF would merge. In terms of workflows, the universal and advanced nature of a language built on the knowledge gained over the last twenty years would allow all programs to open files produced by any other while maintaining a high degree of editability. While the application was working on its own files meanwhile, the languages extensibility would mean that no power would have to be sacrificed to maintain compatibility. The format would offer the best of all worlds as an open and advanced exchange standard straddling all media and all workflows while maintaining maximum application-specific power through extensibility.
In other words at some point in the future you might be able to forget completely about the myriad of competing design-based file formats as the strengths of all are pooled into just one. Its an exciting prospect but in the meantime make the most of todays advanced bitmap formats and especially the all-important standards. It will be some time yet before TIFF, JPEG and GIF are dislodged from their perch.
File format information based on OReillys definitive Encyclopaedia of Graphics File Formats by James Murray and William vanRyper.
Hopefully you've found the information you were looking for. For further information please click here.
For free trials and special offers please click the following recommended links:
For further information on the following design applications and subjects please click on the links below:
[3D], [3ds max], [Adobe], [Acrobat], [Cinema 4D], [Corel], [CorelDRAW], [Creative Suite], [Digital Image], [Dreamweaver], [Director], [Fireworks], [Flash], [FreeHand], [FrameMaker], [FrontPage], [GoLive], [Graphic Design], [HTML/CSS], [Illustrator], [InDesign], [Macromedia], [Macromedia Studio], [Microsoft], [NetObjects Fusion], [PageMaker], [Paint Shop Pro], [Painter], [Photo Editing], [PhotoImpact], [Photoshop], [Photoshop Elements], [Publisher], [QuarkXPress], [Web Design]
To continue your search on the designer-info.com site and beyond please use the Google and Amazon search boxes below:
|designer-info.com: independent, informed, intelligent, incisive, in-depth...|
All the work on the site (over 250 reviews, over 100 articles and tutorials) has been written by me, Tom Arah It's also me who maintains the site, answers your emails etc. The site is very popular and from your feedback I know it's a useful resource - but it takes a lot to keep it up.
You can help keep the site running, independent and free by Bookmarking the site (if you don't you might never find it again), telling others about it and by coming back (new content is added every month). Even better you can make a donation eg $5 the typical cost of just one issue of a print magazine or buy anything via Amazon.com or Amazon.co.uk (now or next time you feel like shopping) using these links or the designer-info.com shop - it's a great way of quickly finding the best buys, it costs you nothing and I gain a small but much-appreciated commission.
Thanks very much, Tom Arah
[DTP/Publishing] [Vector Drawing] [Bitmap/Photo] [Web] [3D]
[Articles/Tutorials] [Reviews/Archive] [Shop] [Home/What's New]