About making pictures   - software  by  Waeshael


requirements for making good pictures


If you look at pictures on LeicaImages.com, all the best have been “breathed on.” There are no good pictures that haven’t been post processed. Very few cameras with fixed lenses can capture what you see in the scene. When most pictures are captured, the shadows are too dark, and the highlights too white. And the colors aren’t those of the scene. Unless you have a camera system that allows you to pre-process the image in the camera (like the SONY NEX), you are bound to do some post processing to make the picture look good. In any case, you have to reduce the image to fit the requirements of web browsers.

If you shoot RAW, then you need the manufacturers software (which comes with the camera) to convert it to TIFF. Some camera’s RAW data cannot be properly demosaiced with all-in one software.

You also need a good picture editor that enables you to selectively change the picture (dodge and burn, color changes etc.) Usually the software that converts from RAW is not a tool designed for editing, though it will allow you to make overall picture changes from demosaicing to white balance, noise reduction etc.

Finally you need a tool that will make a good job of scaling for the Web.

On LeicaImages many people use Lightroom to do all these things, but it’s not the best software for dodging and burning and is not capable of merging many photos for a composite. Pictures need to be adjusted in selected areas or selected colors to make them look right - dodge and burn; hue chroma and valance, local contrast enhancements, noise reduction, lifting tones in the shadows, controlling highlights. Photoshop can do these things, as can Live Picture (Mac Classic only.)

Firefox, Safari, and Chrome browsers

Browsers, apart from the current Firefox, are color blind. They have no idea what color space is attached to the image. This is true for iPAD, iPad mini, iPhone 4-5, Nexus 7, Nexus 10, Safari on Mac, Internet Explorer on PC. So when you post a picture to the WEB to be viewed in a browser it won’t look like it did in your editor. You must use a program that can actually embed the proper colors into the file, and also removes the EXIF tag that indicates the color profile of the original image. I don’t know how Lightroom does this. I use Graphic Converter for Mac, Version 8, or I use SIlkypix Studio 4 and 5.  Graphic Converter 8 runs on Intel Macs. It only costs $40. I could not be without it. More on this later. I have SIlkypix 4 running on one Intel Mac Mini, and on a Powerbook PPC running Tiger (more on why I use Tiger, later.)

Pictures that come straight from your camera have a header file attached to them that describes the way the camera made the picture. This is EXIF data, and every editor can read it. The colors the camera made are described by a “tag” which will say sRGB, or “uncalibrated” if it is Adobe 1998 color space. If you shoot RAW you define which color space you want to tag the image with in the RAW processor when you save the file.

The window was shot on film with M6 camera and 35 Summicron, in 1997. The picture of the child was shot in 1945 on 120 film and scanned probably around 2004. The pictures were combined in Live Picture and built out to a TIFF image. This was adjusted for color again and a frame added in Snapseed. The image was sent to Graphic Converter for scaling and conversion to WEB format with the color space embedded into the file - no EXIF header.

This seems complicated, doesn’t it. If you tried to do this in Lightroom 4, or Aperture you would be unable to recreate this image. If you are a Photoshop expert, you could do something similar.


Evolution of sensor photo site layout showing Fufifilm super CCD sensors that can’t be understood without the manufacturer’s approved software. Adobe products can’t do it right.

In any case, the image consists of RGB numbers that are meaningless unless the key to decoding them is included somewhere in the editing process, either in the file header, or as assigned to the image by the default setting of the editor.

If the browser gets an image with no key, it has to guess what the key may have been. Firefox and Chrome browser assumes the color profile was sRGB, and so converts the numbers in the file to sRGB numbers. The browser assumes that the monitor also uses the sRGB color space - it doesn’t, but the color space of most monitors is close to sRGB, but not exactly. If you edit with the same monitor you browse with, you won’t see any difference. Your audience doesn’t have anything to compare with. You just assume that they are seeing what you see - wrong! Their monitor may be uncalibrated. Also the picture source color profile may have been proprietary and called “camera color space” and you have to convert it to sRGB in your editor before saving to the JPG file.

In the case of Firefox browser, it can read the EXIF tag and will convert the colors according to the tag.

In the case of Safari browser on any device, it will ignore any tag, and convert the image to the colorspace of the device’s display.

When you compare images on Firefox, Safari, and Chrome browsers, you will that only Firefox has the same color as your editor, the other pictures are usually more red.

If someone has converted the image to any other color space than sRGB, say, Adobe 1998, then only Firefox will do the proper color conversion. The other browsers will be way off in color.

The way to fix this problem is to embed the colors into the actual file so that the numbers in the file correspond to the sRGB color space. It then doesn’t matter what colorspace was used to make the picture. But you must remove any EXIF color tag from the header, otherwise you will be converting colors twice in some browsers.

Let’s talk about tablets and phones. They are all color blind to the profile that is attached to the file. When you send a picture to this device not only does it ignore the color profile, but it changes the image also. In the case of the iPAD and iPhone the image is re-compressed to make uploading to the cloud faster, but it is also scaled down to something under 2 MB. Many image servers in the cloud, then re-compress it to take up less space on their hard drives (Facebook etc.) If you send your picture through a tablet, you must control what happens to it otherwise when someone views your picture it will be a poor copy of the original.

The proper way to look at pictures is in a viewer, on a monitor that is color calibrated. If you must look at them in a Browser, then Firefox on a calibrated monitor. Because you don’t know whether the photographer embedded the color profile in his picture.

Firefox on a tablet is no better than Safari or Chrome.