On Thursday 10 Sep 2015 22:07:44 waben...@gmail.com wrote: > Mick <michaelkintz...@gmail.com> wrote: > > On the same hardware I noticed that a CMYK photograph converted to > > sRGB looked mostly the same (indistinguishable) on Linux, but the > > sRGB colours were brighter on MSWindows. > > > > I tried this by dual booting between MSWindows and Linux. > > > > Then I tried it by running MSWindows within a VM on a Linux host and > > the MSWindows showed a clear difference in brightness between the two > > formats. > > > > Finally, I checked on an AppleMac and the difference between the CMYK > > and sRGB photographs was even more prominent than MSWindows. > > > > So, the Linux renedering seems to be misleading the user. Have you > > noticed the same? > > > > BTW, both Linux machines that I tried this on are running radeon > > drivers - are these to blame? The AppleMac is running Intel graphics > > with its 'retina' monitor. Is it a matter of somehow tuning the Xorg > > settings on my Linux PCs? > > First I must say that even though I'm working as a photographer I'm not > an expert on Color Models. The professional exposure and print service > that I use only accepts RGB Color Models. They use laser projectors to > expose photographic papers. No conversion to CMYK is necessary. > If I order fine art prints, they are doing the conversion by them self. > All I have to do is softproofing my pictures in Lightroom using their > different ICC profiles, to make sure that I don't deliver pictures that > are out of the destination gamut. > So I don't have any practical experiences with CMYK pictures. I only > have some incomplete theoretical knowledge about it. > > CMYK is a subtractive color model and RGB is an additive color model, > they are working completely different. It is not possible to convert > one in to the other by just simply adjust some gamma curves or using a > LUT as it is done by color management systems like lcms. > > When you are watching a CMYK picture, your picture viewer has to convert > it to a RGB color space (sRGB or AdobeRGB or similar), because that is > what your monitor needs. And I think there are not much picture viewers > that are able to display a CMYK picture. > > This conversion can not be done by the graphics driver, regardless what > kind of OS you use. Indeed Linux drivers can only use 8 bits per color > channel (that's really poor IMHO) and Windows can use 10 bits per channel > (depends on the graphics card), but this can't make big differences in > brightness or saturation. It only leads to smother color transitions in > some pictures. > So I don't think that the drivers have anything to do with your problem. > > Apart from the different color models (CMYK vs RGB) there exist different > color spaces (eg. AdobeRGB and sRGB). When you convert one color space in > to an other, there are parameters like black point compensation and > different rendering intents (perceptual and relative or absolute > colorimetric), that can make a difference in the resulting picture. > > You didn't told exactly what you have done. This makes it difficult to > find a reason for the problem. But I can think of different reasons for > the phenomenon you observed: > > Different picture viewers and/or different color management systems and/or > different color spaces (including different rendering intents respectively > black point compensations). :-) > > -- > Regards > wabe
Thank you all for your answers. They guided me to do some reading in this field, which is quite a science all on its own! The problem I had was caused by the use of ImageMagick's 'convert -colorspace RGB' which is an approximation rather than specific to the colour profile of a particular image. As I posted the colours of the original and the converted looked similarly saturated, over-brightened, on Linux. On AppleMac (different box) and MSWindows (same box and same monitors) the difference between the two images was more noticeable. I spent some time adjusting the brightness, contrast and RGB colours on the two monitors to make them as close to each other as possible and as close to some images I had of some fabrics. I used these because I also had physical samples of these same fabrics, so I could compare them against the real thing. I also used colour patterns I found on the Internet for calibrating monitors. The match between the two monitors was not perfect, because one is LCD and the other a much brighter LED. Then I played with the System Settings/Display/Gamma of KDE, but noticed I could only affect the RGB colours on the left monitor. So I started searching for various applications that would allow me to finely tune the calibration of the monitors. I ended up installing media-libs/oyranos and kde-misc/kolor-manager. The oyranos application connects to the Taxi DB of icc profiles[1] and fetches the icc profiles for different monitors that contributors have submitted calibration settings for. This means that I do not have to use a spectrometer or calorimeter, as long as I am happy to live with some variation that may exist between monitors of the same make and model. Kolor-manager adds a new setting selection in System Settings of KDE which allows me to select each monitor in turn, see the EDID icc that the OS reads from the monitor chipset and then fetch any profiles that people have updated to the Taxi DB and use them instead. In addition, the Kolor-manager saves any such profiles locally in ~/.local/share/color/icc/ and loads what I select when X starts. There are other non-KDE applications like monica, which adds gamma correction values to .monicarc and then a call for loading these values in .xinitrc, or .bashrc, so that when X starts the appropriate icc file is sourced. Peter's description does not mention which application loads the .icc file that the hughski creates, but I'm guessing there must be something that does read it, if the monitor settings are indeed altered. With the monitors sorted as best as I could adjust them manually I loaded the icc files with Kolor-manager. I could not see any change in the colors displayed by the monitors. They are both wide gamut monitors, so perhaps the RGB changes were within the narrower RGB spectrum and that's why I did not notice a difference - not to mention that my eyes are not they used to be. :p Having done all this, I revisited ImageMagick. I ran identify -verbose and discovered that the original jpg image did not have an embedded icc profile. So I reran the command specifying a cmyk profile for the input file and an sRGB for the output file. The result is now satisfactory and comparable on all operating systems. I am still a bit unclear if on non-KDE dekstops xserver will pick up any icc files for the monitor from ~/.local/share/color/icc and load them at start up all on its own, or if any additional software is necessary to achieve this. Thanks again for your help. [1] http://icc.opensuse.org/ -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
