"Old-and-Busted"
In the old way of doing things, (before tools like D-Storm's Buffer Saver, LW's layered, Photoshop Saver, and the new exrTrader,) if we wanted to, say, generate a render pass that isolated just the specular hits where the lights were glinting brightly off the objects, here's what we'd have to do.

Saving our base Scene as, "sq01sc003_Spec.lws," (so we wouldn't accidentally overwrite this all-important Base with our sometimes destructive modifications,) we'd first change all our lights to affect only the Specular channels of surfaces.

We'd then have to direct the saving path to someplace that made sense, and wouldn't overwrite or be overwritten by other passes, (ie. /sq01sc003_Spec/sq01sc003_Spec_0000.flx ).

The scene would be saved, sent to the Renderfarm, and the process would be repeated for any other passes we may need, (Diffuse, Fill, Luminosity, Shadow, etc.,) for every level, (FG, MG, BG,) into which the Scene needed to be split.

NOTE:
My old preference for file format was the FLX, "Flexible" format, since it was reliable, was low in "noise," supported an Alpha channel, and used 32, floating-point bits to store information for each channel.

What many of us have been told to think of as a "24-bit, full-color image" is, in professional terms, an 8-bit image, meaning that it has 8-bits to store its Red channel information, 8 for Green, and 8 for blue. This is the minimum the average human eye needs to perceive a continuous tone color image.

And the bits in, say, a standard TGA or JPEG image are also "Integer," which means that they are whole numbers... 0, 1, 2... through 255 in an 8-bit image.

Whereas bits that are "Floating-Point" can count: 0, 1, 2, 2 3/4, 2 7/8, 2 166/167, etc.

Floating-Point images generally regard their channel information as percentages where Black is 0%, and White is 100%, but are not bound by 0 and 100%. A pixel can easily be 1,000% of the intensity of the white your monitor can display, or ten times more black than the Black your monitor can display as well.

And, obviously, an image that has 32-bits per channel, can hold more information in one of its channels alone, than in the R, G and B channels combined, of an 8-bits per channel image.

So, if a "continuous tone" image needs only 8 Integer bits per channel, why would you ever want to render to a 32-bit, Floating-Point format? Well, it's important if your final output is film, which can represent significantly more subtlety in color than your monitor can. And/or, if you plan on having a Floating-Point, high-bit-depth compositing package, like Fusion, factor heavily into your pipeline.

With a Floating-Point, 32-bit/channel, image, you can "push" your images colors, contrast, brightness, all over the place, and still preserve the smoothness to even your most subtle, smoothest gradients. This lets you just get "in the ballpark" with the render out of your 3D package... get the grass "roughly green," and the skies "roughly blue," using the (now) real-time feedback of the compositing packages to bring the images to their final glory.

Both images here are having their colors compressed and then re-expanded by an identical, Instanced pair of Brightness tools in Fusion5. The panel on the left shows the result of the original image first being converted to an Integer, 8-bits per channel before being color-corrected – there are huge difference between the original and the affected. The panel on the right shows the same process applied to the image using full, 32-bit float color-space... its result is identical to the input.

The less time you spend in render, the faster your work will be complete.