A few thoughts,
Was black point compensation ticked in export?
What version firefox are you using? Firefox 77 had a bug which disabled color management for certain images. Firefox 78 fixed that, but can show some color distortion on images with v4 profiles. Here’s some steps to ensure Firefox color management is set up correctly: How to configure Firefox color management
Can’t help what others are doing. Can only ensure things are optimal at your end, but srgb v2 profiles should display correctly on most monitors.
I followed the instructions here, and that is kind of the core problem. It says I should change a couple of Firefox defaults (to force it to use my monitor profile). But then another user will certainly see the image different than me since he certainly did not change the defaults. Right? This is exactly what I want to avoid…
Almost. I cannot make firefox look exactly as GIMP, unless I don’t use monitor profile and I don’t save any ICC_Profile data in the exif (or if I delete the exif). If not, if I do everything as I am supposed to do, I see the images in firefox with slightly different contrast.
While all this is pretty cool and exciting stuff for color theorists like me — I still do not recommend embedding ICC profiles in Web graphics/photos because it is not reliable — unless your are using Firefox, Value1 and have a "calibrated’ monitor — you may only be fooling yourself about what other people are seeing.
So, for web usage, better user sRGB but do not embed any profiles?
Yes, both in Gimp and RawTherapee (did not find anything at export time, but at color management). Could not find this in Darktable.
I use Firefox 84, Chrome 88.
But then, if I change my configs, other users will not have changed theirs…
Sorry, maybe I was not clear enough. I know how to make all my software look exactly the same for me, but I need to ensure that others see as close as I see. That’s my ONLY problem.
I was a bit confused as well but it seemed as though he said at some point that the most common is if no profile it will assume srgb and then convert to the users display which was the best approach?? I needed to give it another read….
I cannot say that this is my problem, but it describes it pretty well.
Look at what it says in this article from 2015.:
Firefox then and now, or the difference black point compensation makes
… As of 2015 and version 31, Firefox still doesn’t support black point compensation, which means that if . . .
you have properly calibrated and profiled your monitor, and your monitor has a reasonable black black point
you have your color managed image editor set to use relative colorimetric intent with black point compensation for display to the monitor
you produce a finished image ready for display on the web
you view the finished image in Firefox
. . . then as displayed by Firefox the shadows in your image will be more or less crushed compared to how the same image is displayed in your color managed image editor.
Black point compensation “compensates” for the fact that monitors can’t display “no light”. Without black point compensation, all shadows darker than the darkest dark your monitor can actually display are simply crushed to solid black. In a high key image image or an image that has few important shadows, you might not notice any difference. In an image that’s supposed to have rich dark shadows, the difference can ruin your appreciation of the image as all the shadow detail turns to muck.
Then this is the problem with no solution. What are you going to do? Go around to every house in the world with a monitor calibrator to ensure their screen displays accurate colours? Find the browser with best colour management and install it on every single screen worldwide? Impossible. That’s why I said you can’t help what others are doing. That’s up to the screen makers and browser devs. It’s the unfortunate reality of showcasing your work on the web - it might display different to the viewer than it did the creator.
EDIT: Ok, I understand this thread now basically boils down to, should one publish images to web with embedded srgb profile or not?
Also keep in mind this, from the same article:
So it depends on your target audience.
Also keep in mind, that information is about 8 years old. Web colour management may have improved since then.
I always embed profiles, but no doubt others know more about this than I do.
As I wrote in the first post, I know how to make everything look the same for me. I want a setting that, for the majority of “normal” non technical users, they see my images as close as possible to mine.
Not just that:
Should I use monitor profile or not? (This is the main one)
Black compensation or not?
Is there any flavor of the standard (!!) sRGB better than others?
All questions pointing to the same: to make the majority of non technical users see my images as close as possible to mine. There is certainly a solution to this, not sure if someone knows it.
This is indeed interesting, and solves partially my problem.
This is also a valid point. 6 years is an eternity in these matters.
I am trying to learn something that I have no idea about!
Whether you use a monitor profile doesn’t seem relevant to the question, as you can’t embed a monitor profile in the image, and you have no control over what monitor profile your viewers will use. But in general, you should definitely calibrate your monitor, which will produce a profile, and you should then tell each application to use that profile. Calibration will give you greatest accuracy, and using it in every program will give a consistency. If all your programs, and web browser, are using the same profile, but the colours are different, then it is an issue with the colour management in program/browser, not the profile. Either the program/browser is not recognising the profile, or it is not colour managed properly.
Yes to black point compensation. You don’t want those blacks unnecessarily crushed. I don’t know if the issue you raised is still a problem in Firefox or not, but if you dont tick Black point compensation they will always get crushed to black. Whereas if you tick Black point compensation, they will only get crushed to black on browsers that don’t support it. At least that’s my understanding.
Someone above linked to elle stone’s website. She has an article or two on the different flavours of srgb. Where given the choice I use v2. V4 profiles are typically best for editing, but not every platform displays them correctly (or at least that was the case a few years ago), so v2 is safer for finished product.
However, using a color managed (CM) display in all your software impacts how you process the image. Let’s say, if it looks lighter when activating CM display, you will compensate the exposure/curve to make it darker. To you, the end results of both workflows (with/without CM) should be (approximately) visually equal. But then the other user at other computer will see both visually different.
I guess that with CM the end result of what I see should be closer to what the other users see, right? Sorry if this is a silly question…
Yes. I learned this the hard way when I had a low quality LCD monitor and I ended up processing all my pictures with a magenta tint. I calibrated my mid range IPS monitor when I bought it, and basically did not have to change anything. After several years, each time I try to see if it is calibrated, it is spot on. (I don’t have special hardware for calibration, I check it with charts).
My problem could be here. I don’t know where is the black point compensation in Darktable (the only place in the manual where the expression “black point compensation” appears is for printing). In GIMP and RawTable it is clear.
Interesting. I always used V4 in RawTherapee. Maybe I should switch to V2.
Someone correct me if wrong, I’m quite sure we are viewing the image in output space when softproof is off. So if ouptut profile is set to srgb (as it should be if saving to web), then there is no need to softproof srgb, as you are already seeing it. However if output profile is set to something else (eg. rec 2020 or pro photo) and you want to see how it looks for web display, then softproofing in srgb makes sense. (Even then, a difference might not be noticeable, if a) all colours are in srgb gamut, or b) your monitor can’t display more than srgb - but I digress).
However contrary to what I said before, there is probably no need to soft proof according to monitor profile either, given we are already viewing on that device, so its a good thing you mentioned it. If I had a reason for soft proofing monitor profile, I can’t recall what it was!
If you do two edits of the same image image, 1) on calibrated display, properly colour managed, 2) uncalibrated display, not colour managed, then you will likely get two different results. Lets say you place edit 1 and edit 2 on different screens, side by side, and edit them so they look exactly the same - it doesn’t mean they really are exactly the same. In fact, they are different. Ie. If you were to display them on the same screen, they would both look different. So all we can really do as photographers is get things looking how we want on a calibrated display, with properly colour managed workflow. That way, what we see is correct. And what viewers with calibrated monitors see is correct. And those with uncalibrated monitors, we cross our fingers and pray its not too far off, but in some cases it will be.
I don’t know where black point compensation is in darktable either. I seem to recall Aurelien saying somewhere they didn’t use it in the pixel pipe, but I have no idea if they use it in export profiles.
In my case I have taken Aurelien’s recommendation to set my histogram profile to rec2020 for gamut and clipping (so matching my working profile). I then set my softproofing to sRGB. Since profiles go input-working -output -display-histogram and also when you select soft proofing it uses the softproofing profile your display when I toggle to softproofing in srgb it will use that as my display profile and change the histogram to show srgb and no longer rec2020 . If I am wanting to check something like say a colorchecker rgb values I would have to do it in softproofing to get expected values since the colorpicker uses the histogram profile to retrieve the values or of course I could change the histogram profile but i find this easier. My monitor is not calibrated and it is noticeably different switching from from display to the standard sRGB profile. Apparently this is common when using the profile that comes with the monitor as monitors cant really display a true black so there is a bit of a toe in the display mapping…So in my case I can see a bit of a difference but I mainly use it as a means to toggle the histogram and colorpicker…rather than as a way to determine output There was a lot of discussion and some confusion revealed in this old issue…Choice of display profile affects histogram, color picker values and overexposure indicators · Issue #3271 · darktable-org_darktable.pdf (1.1 MB)
For me, it seems rather simple (conceptuallyat least):
First, you have to make sure that your image has the colours as close to correct as possible, which means on your side you use calibrated and profiled processing and display.
Next, you want the best option to show what you want to your users. But you have no control over what device and software they use. So export to sRGB and embed the profile you use. That is all you can do… A colour managed application on a profiled device will then show the colours you planned (more or less)
You cannot control which flavour of sRGB will be used by your end users (either now or next year), so don’t worry about it.
You can’t do anything about their device profiles and black point compensation(°), so just ignore that for exporting your image. Specifically, do not embed your device specific info in images you publish.
(°) A I understand it, black point compensation is also device dependant, so not something you can set for display on someone else’s device/medium.
RawTherapee has a convenient button to switch between working/output profile in the histogram. Even if I see lots of clipping in sRBG and no clipping in rec2020 (my working profile), I don’t see any difference in the image, only in the histogram.
Understanding the essential operation of color transform is the most insightful thing I’ve done to understand color management. Once you get that, the rest is just stitching together transforms.
So, the camera records a scene, and that data has to be worked before it’s presentable in a way humans can appreciate. One of the things that needs to be done is to transform the data down from its spectral response to a colorspace that can be worked with or displayed. This is the first of a few color transforms, and it works like this:
The raw data needs to be assigned a set of color primaries, usually 9 numbers that represent some notion of its color. These can be in a profile file (ICC or DCP), or come from a list stored internally by the raw processor.
The transform is a two-step operation: The camera primaries are then used to transform the image data to the XYZ colorspace, which is based on the original 1931 CIE color-matching experiments. Really, the XYZ space is just a common intermediate in this process, keeps us from having to maintain camera profiles for every destination.
The image data in XYZ is then transformed to the destination colorspace. This could be a working space like ProPhoto or Rec2020, or it could be direct to a display-sized colorspace like AdobeRGB or sRGB.
The above describes the general process of a transform, in the context of the first one that needs to be done out of camera space. I wrote something about a year ago that describes how transforms are generally used in raw procesing; you can find it here: