Hi Sander,
Excellent, you've applied a correct workflow and you've got a correct result. Isn't it nice when the things go well?
I'll be recalibrating my 'good' monitor and use that profile as my default editing profile. The proof profile will be sRGB and that's what I'll convert t before publishing. Does that sound right or should I keep sRGB as the default and will colors magically get translated to the monitor profile during editing?
That plan isn't too wrong, but it isn't correct either. This is the recommended setup:
1. After calibrating your display, select the resulting ICC profile as the monitor profile in your system. On Windows, you must select it by right-clicking on the desktop, editing screen properties, etc. (I don't remember the step-by-step procedure now, but it's easy to follow). On Linux, there is no standard system color management functionality, so PixInsight's ColorManagementSetup interface allows you to change the monitor profile.
Anyway, to make sure that your monitor is being characterized correctly, open ColorManagementSetup and verify that the correct ICC profile appears selected as the current monitor profile.
2. After image calibration, and once you have carried out the first nonlinear transformation, you must select a working color space. Since you work with raw images that don't embed an ICC profile (i.e., the response of a CCD camera can't be described with an ICC profile), this decision is arbitrary. Basically, you have two main options:
- Use the sRGB space as your working space. This has the advantage that you'll get no surprises. Everything you do is represented as what a mean PC user will see later, when you publish your final image on the web.
- Use a wide gamut space, such as Adobe RGB (1998), Apple RGB, ColorMatch RGB, Beta RGB, etc. This has the advantage that you work into a theoretical space that is much larger than the characteristic space of any output device, including any printer, any display, and of course the sRGB space. You'll be able to boost color saturation much more, and generally you'll get more vibrant colors and more shadow detail with less effort. The disadvantage is that the sRGB space, which is your final goal, can be unable to represent your images properly because you'll generate out-of-gamut pixel values. This can be a serious problem or not, depending on the kind of images you have and how you process them.
Using your monitor's profile as your working profile is, in general, a bad idea. One reason is that it is usually even smaller than the sRGB space (unless you have a high-end monitor with something like a 12-bit rendering engine and a 12-bit capable LCD panel). Using a device-specific color space as a working space is regarded as bad practice, because a device's profile doesn't correspond, in general, to any standard color space.
3. If you use a wide gamut working space, you must transform (a copy of) your image to the sRGB space prior to web deployment. This involves proofing and careful gamut checking, as we have explained. The sRGB profile must be embedded in all versions to be published on the WWW.
4. A similar step to step 3 exists for each output device you use. For example, prior to printing your image on a physical printer, you must use the printer's profile as your proofing profile to verify out-of-gamut pixels, and to preview how your image will look like once printed. Remember that a valid printing profile must characterize both the printer and the paper (or media) you're going to use.
This is more or less a basic color-managed workflow. The key of the whole system is in the profiles. Every physical device used must be accurately described by an ICC profile. If a single element fails, the entire system goes down.
