Adrian Mariano wrote:
In my case I believe that I ran 'dispwin profile.icc' without the -I option. Does this load the profile or does it only load the calibration contained in the profile?
dispwin profile.icc only loads calibration, dispwin -I profile.icc additionally installs the profile (copies to appropriate location in the filesystem) and sets it as default for the display. After installation, to reload the calibration you can use dispwin -L which loads the calibration of whatever the current display profile is (dispwin -c -L might be more robust because it clears the current calibration before loading).
I think that you have to restart firefox to get changes in the profile to be recognized. I have the color management extension installed in firefox and there is a box where I can specify the profile filename; when I specified the color swapped profile and then restarted firefox I did observe the swapped colors used in firefox.
Yes, I restarted Firefox, but still no go. If I specify the profile it should use with the extension, it works.
Just to confirm that I understand properly, if I were to calibrate my display to gamma=2.0, say, it wouldn't matter if all the applications were color managed because they'd look at the colorspace for the images and make the appropriate translations. The only reason it matters is because of the non-color managed apps. Is that right?
Sounds right. The profile will correct differences (which it will do more or less reliably depending on how accurate the profile is).
But is that really true? If I only have 8 bits to work with and all of my images are really in sRBG (say) then if I calibrate to gamma=2.0 then I need a second conversion to get by sRGB data mapped to my display.
I'm not sure what you mean by "second conversion", but I assume you mean the profile conversion from source (image) to destination (monitor) colorspaces in colormanaged apps. Which gamma you calibrate to impacts how much the profile has to "work" to achieve the given source tonal response. But it is indeed generally better to have the calibration offload some of that work from the profile conversion.
Wouldn't it be optimal in this case to instead calibrate the display to sRGB so that I only have one layer of mapping (in 8 bits) to display the data there? In other words, I should get less banding and artifacts when viewing the sRGB source data if I calibrate the display to sRGB even though this is farther from the display's native response. It seems like I should calibrate to the expected color space of my data.
If it is foreseeable that most if not all images you view are actually sRGB (and we assume that sRGB images indeed should be viewed with a sRGB gamma, and not just encoded with it but viewed on say a gamma 2.x monitor), then I agree it is surely a good idea to use that as tone curve when calibrating.
But if I have no idea what the data's colorspace is, or data comes in many different color spaces, then I should calibrate to the monitor's native response. (Or not calibrate at all? Only profile?)
Calibration still helps to get neutral grayscales, so in most cases it is a good idea to calibrate not only profile. If you can't know which data comes in, a response close to the monitor's native one might help reduce visible banding. Or you could estimate an average gamma of your data and use that. There is unfortunately no single, universal "right" way to do it :) (and if softproofing comes into play, things get even more complicated because then source and display profile are decoupled tonal response wise by the proof profile in betweeen)
Can anybody direct me to a good image to use to test for banding?
To test for banding, smooth gradients from 0-255 R-G-B values should do (but please keep in mind that totally banding-less is not possible on an 8-bit display).
Regards, Florian