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

[Andrew Goodbody]

On 04/03/12 15:24, Jean-François Rabasse wrote:
>
> On Sun, 4 Mar 2012, Andrew Goodbody wrote:
>
>> OK, I think we have sorted out what is happening. Both images are
>> marked as being in ProPhotoRGB colour space. But only the one uploaded
>> by FLickrUploader has the embedded ICC profile. The one uploaded by
>> Digikam does not have the embedded profile. I am guessing that the
>> resize for upload is not preserving the embedded profile. Giles, can
>> that be fixed?
>>
>> Then we have the issue about gwenview etc not using an embedded
>> profile to display an image properly.
>
> Gwenview yes, but also some browsers. Antonio signaled the problem with
> Chrome. Konqueror (used as local image viewer or web browser) doesn't
> handle the profile neither, and shows also the « greenish » version of
> Jim's image.
> For web usage, seems difficult to assume that any user, using any version
> of any existing browser, Firefox, Konqueror, Chrome, Safari, Opera, etc.
> could see the correct colours.

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.

>> So for a workaround, Jim should export any jpegs that he intends to
>> upload with Digikam into the sRGB colour space.
>
> Seems safe.
> My own opinion is that colour profiles are rather intended to images
> edition software, PhotoShop, GIMP et al., or printing workflows, than
> for images display.

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

> Used for images display means the colour information is split into two
> parts, the JPEG scanlines RGB triplets plus the corrective profile data.
> If the profile part is lost through an export/upload processing (what
> happened to Jim), or is ignored by the final viewing program (what
> happened to those of us using non profiles aware browsers), author's
> initial colours are out.

Unfortunately true, but does not only apply to display of images, also 
applies to editing and printing.

> Perhaps a reasonable model for standard web usage could be sRGB default,

sRGB is already the de facto default colour space for web usage.

> 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.

> However, what could be useful in export/upload modules is at least to
> issue a warning, something like « Hey, your image uses an embedded colour
> profile and may not be viewed correctly by any user on the earth. Do you
> still wish to continue ? »
> (Or propose a downsizing+compression+sRGB reencoding process.)
>
> Regards,
> Jean-François

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.

Andrew