[Digikam-users] trouble with image degradation using DK with kipi-plugin: flickr export

[Jean-François Rabasse]

On Sun, 4 Mar 2012, Andrew Goodbody wrote:

Hi Andrew,

Em, I wouldn't like you to think I contest colour profiles and their
rendering role. I fully agree with you.
My remarks aimed one and only one issue, « showing images on the web,
to other (possibly) unknown people », nothing more.

> But Giles can fix Gwenview and the others that use kipi-plugins. Also there 
> will be plenty of images already in existence that will need this fix in 
> order to display properly. Also we will never be able to get everyone to 
> always 'do the right thing'. So we need to make the best of what there is and 
> that means being able to make use of an embedded profile.

Yes, Gilles and other KDE involved persons can provide support for that, 
that's true. But what about non KDE software ? Not that easy to get from
Google profiles support for the Chrome browser, or to get from the GNU
project support for e.g. EOG. (I've checked images software I have under 
hand on my computer, only three of them support profiles, Firefox, 
Digikam, The GIMP. But not Dolphin/Gwenview, Konqueror, Eye of Gnome, 
F-spot, ...)

I agree with you about « make the best of what there is », except for
the web. IMHO, the world wide web is a world wide system, and the best
is what concern world wide users. This is no longer a technical issue 
but a matter of interoperability. To how many users do we wish to show
our images, whatever they use as web browers, smartphones, etc.
It may change in a future, (color profiles support), but it's not the
case today.

Btw, it would be interesting to get feedback, about initial Jim's image,
from users using some of the other major browsers, MS-IE or Apple 
Safari. Is embedded profile supported ? Does the image looks with warm 
tan tones or greenish tones ?


> I don't really see the distinction. The embedded profile helps to 
> interpret the image data whether that is for editing, printing or 
> display.

If I made the distinction between images editing and printing, and 
images display, it was again in a web context only.
People doing editing and printing tasks, on a computer, use more
sophisticated software that all support profiles. People that just 
browse the web and look at images use ... what they have under hand.
Sad but true :)


>> encoded in the Truecolor triplets of the JPEG scanlines.
>> Nothing extra would be required for final colours rendering.
>> (Also, uploaded files could be stripped of any non image data.)
>
> But you already have defined the extra ie sRGB. I do not understand what you 
> mean by 'Truecolor'. There is no single 'true' representation of colour. You 
> are always working in one colour space or another. Jim's problem is that his 
> photos are in ProPhotoRGB and so render incorrectly when attempted to be 
> displayed with the default assumption of sRGB. If the default assumption 
> happened to be ProPhotoRGB instead of sRGB, Jim's photos could render 
> correctly with 'nothing extra' except of course the knowledge of ProPhotoRGB.

In my remark, « extra » was refering to extra provided information 
(profile data embedded in the image file) for image rendering. Choosing 
sRGB space is not providing extra data but using an implicit default reference.

Truecolor refers to the image encoding model; each pixel of the image matrix
encodes a RGB triplet (or RGBA if alpha channels are supported). And, you're
right, a RGB triplet is coordinates set into a colour space.
(On the opposite, in the Pseudocolor model, each pixel of the image 
matrix references an integer index into a color palette, not a colour 
definition. To render the image, one need the pixel value, the color palette
data, the colour space used.)

Thus my remarks were just stating that :
- If you, image owner, do the rendering wrt a sRGB space, you only need 
to upload to your online album the by pixel RGB information for your 
image, i.e. the JPEG scanlines sections for the image matrix.
- If you upload non sRGB image information, you also need to provide the 
used profile and let the end user do the final rendering.
But if that end user uses a software not aware of colour profiles, that 
end user will see your image with wrong colours.

That's why I prefer the first solution in a web context.
I'm not a professional, just images hobbyist, and my « end users » are 
family and friends.
I would never risk myself to point their attention to ICC profiles 
issues and proper software to use if they want to see my images as I'd like
them to see. All what I could expect as feedback would be « but why does your
image look so green ? »:-)
So, I prefer to do the job myself, and give a simple sRGB image as a
default pre-rendering, with the reasonable assumption everyone would 
see something correct. Not perfect perhaps, but correctly viewable.


> But this is also a good idea and would be good to have. I just don't see it 
> being sufficient on its own. So my vote is to properly display images with an 
> embedded colour profile but also warn about uploading images that are not in 
> the sRGB space. The user should also be able to choose whether or not the 
> uploaded image contains the embedded profile with a suitable warning about 
> consequences for the chosen combination.

Agree 100%. The important thing is that software *warns* before dropping
some information. It belongs to the software user to decide what could 
be discarded and what is mandatory. Totally agree with that.

Jean-François