trouble with image degradation using DK with kipi-plugin: flickr export
Locked
12
12
trouble with image degradation using DK with kipi-plugin: flickr export
 
|
When I upload a photo to flickr with the kipi-plugin from Digikam, I
get bad coloration. When I upload using the flickr web uploader I get color as I've developed. One thing: I've developed these in photoshop running under a windows virtual machine. But then uploaded with digikam under linux - and get the problem. I can upload using the flickr web interface under linux with no problem. here's an example: http://www.flickr.com/photos/jdory/6799702398/ Bottom image is with Digikam export. Here's more info: digiKam version 2.5.0 Exiv2 can write to Jp2: Yes Exiv2 can write to Jpeg: Yes Exiv2 can write to Pgf: Yes Exiv2 can write to Png: Yes Exiv2 can write to Tiff: Yes Exiv2 supports XMP metadata: Yes LibCImg: 130 LibClapack: internal library LibExiv2: 0.21.1 LibJPEG: 80 LibJasper: 1.900.1 LibKDE: 4.8.00 (4.8.0 LibKExiv2: 2.1.0 LibKGeoMap: 2.0.0 LibKdcraw: 2.0.1 LibLCMS: 119 LibPGF: 6.11.32 - internal library LibPNG: 1.5.7 LibQt: 4.8.0 LibRaw: 0.14.4 LibTIFF: LIBTIFF, Version 4.0.0 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc. Marble Widget: 0.12.97 (0.13 Release Candidate 2) Parallelized demosaicing: Yes Database backend: QSQLITE LibKface: 2.0.0 LibKipi: 1.3.0 LibOpenCV: 2.3.1 Libface: 0.2 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: trouble with image degradation using DK with kipi-plugin: flickr export
|
|
I cannot see any color difference.
If you upload a RAW file from digiKam to Flickr, it will take embeded JPEG image from RAW instead to process RAW file, to speed-up downloading. Gilles Caulier 2012/3/3 Jim Dory <[hidden email]>: > When I upload a photo to flickr with the kipi-plugin from Digikam, I > get bad coloration. > > When I upload using the flickr web uploader I get color as I've developed. > > One thing: I've developed these in photoshop running under a windows > virtual machine. But then uploaded with digikam under linux - and get > the problem. I can upload using the flickr web interface under linux > with no problem. > > here's an example: > http://www.flickr.com/photos/jdory/6799702398/ > > Bottom image is with Digikam export. > > Here's more info: > > > digiKam version 2.5.0 > Exiv2 can write to Jp2: Yes > Exiv2 can write to Jpeg: Yes > Exiv2 can write to Pgf: Yes > Exiv2 can write to Png: Yes > Exiv2 can write to Tiff: Yes > Exiv2 supports XMP metadata: Yes > LibCImg: 130 > LibClapack: internal library > LibExiv2: 0.21.1 > LibJPEG: 80 > LibJasper: 1.900.1 > LibKDE: 4.8.00 (4.8.0 > LibKExiv2: 2.1.0 > LibKGeoMap: 2.0.0 > LibKdcraw: 2.0.1 > LibLCMS: 119 > LibPGF: 6.11.32 - internal library > LibPNG: 1.5.7 > LibQt: 4.8.0 > LibRaw: 0.14.4 > LibTIFF: LIBTIFF, Version 4.0.0 Copyright (c) 1988-1996 Sam Leffler > Copyright (c) 1991-1996 Silicon Graphics, Inc. > Marble Widget: 0.12.97 (0.13 Release Candidate 2) > Parallelized demosaicing: Yes > Database backend: QSQLITE > LibKface: 2.0.0 > LibKipi: 1.3.0 > LibOpenCV: 2.3.1 > Libface: 0.2 > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: trouble with image degradation using DK with kipi-plugin: flickr export
|
|
I see the difference. The one uploaded from Digikam is more washed out.
Look at the ground the animal is sitting on and the hair on the back of its neck. There is more red in the one uploaded by FLickrUploader. I expect that it is a colour space issue. The one uploaded with FlickrUploader is in ProPhotoRGB. I cannot get permission to check what the one uploaded by Digikam says it is. Andrew On 03/03/12 17:41, Gilles Caulier wrote: > I cannot see any color difference. > > If you upload a RAW file from digiKam to Flickr, it will take embeded > JPEG image from RAW instead to process RAW file, to speed-up > downloading. > > Gilles Caulier > > 2012/3/3 Jim Dory<[hidden email]>: >> When I upload a photo to flickr with the kipi-plugin from Digikam, I >> get bad coloration. >> >> When I upload using the flickr web uploader I get color as I've developed. >> >> One thing: I've developed these in photoshop running under a windows >> virtual machine. But then uploaded with digikam under linux - and get >> the problem. I can upload using the flickr web interface under linux >> with no problem. >> >> here's an example: >> http://www.flickr.com/photos/jdory/6799702398/ >> >> Bottom image is with Digikam export. >> >> Here's more info: >> >> >> digiKam version 2.5.0 >> Exiv2 can write to Jp2: Yes >> Exiv2 can write to Jpeg: Yes >> Exiv2 can write to Pgf: Yes >> Exiv2 can write to Png: Yes >> Exiv2 can write to Tiff: Yes >> Exiv2 supports XMP metadata: Yes >> LibCImg: 130 >> LibClapack: internal library >> LibExiv2: 0.21.1 >> LibJPEG: 80 >> LibJasper: 1.900.1 >> LibKDE: 4.8.00 (4.8.0 >> LibKExiv2: 2.1.0 >> LibKGeoMap: 2.0.0 >> LibKdcraw: 2.0.1 >> LibLCMS: 119 >> LibPGF: 6.11.32 - internal library >> LibPNG: 1.5.7 >> LibQt: 4.8.0 >> LibRaw: 0.14.4 >> LibTIFF: LIBTIFF, Version 4.0.0 Copyright (c) 1988-1996 Sam Leffler >> Copyright (c) 1991-1996 Silicon Graphics, Inc. >> Marble Widget: 0.12.97 (0.13 Release Candidate 2) >> Parallelized demosaicing: Yes >> Database backend: QSQLITE >> LibKface: 2.0.0 >> LibKipi: 1.3.0 >> LibOpenCV: 2.3.1 >> Libface: 0.2 >> _______________________________________________ >> Digikam-users mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-users > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: trouble with image degradation using DK with kipi-plugin: flickr export
|
|
It's probably a side effect of resizement of image before uploading...
Can you share original image to check if sRGB is set by PhotoShop or another one ? Gilles Caulier 2012/3/3 Andrew Goodbody <[hidden email]>: > I see the difference. The one uploaded from Digikam is more washed out. Look > at the ground the animal is sitting on and the hair on the back of its neck. > There is more red in the one uploaded by FLickrUploader. I expect that it is > a colour space issue. The one uploaded with FlickrUploader is in > ProPhotoRGB. I cannot get permission to check what the one uploaded by > Digikam says it is. > > Andrew > > > On 03/03/12 17:41, Gilles Caulier wrote: >> >> I cannot see any color difference. >> >> If you upload a RAW file from digiKam to Flickr, it will take embeded >> JPEG image from RAW instead to process RAW file, to speed-up >> downloading. >> >> Gilles Caulier >> >> 2012/3/3 Jim Dory<[hidden email]>: >>> >>> When I upload a photo to flickr with the kipi-plugin from Digikam, I >>> get bad coloration. >>> >>> When I upload using the flickr web uploader I get color as I've >>> developed. >>> >>> One thing: I've developed these in photoshop running under a windows >>> virtual machine. But then uploaded with digikam under linux - and get >>> the problem. I can upload using the flickr web interface under linux >>> with no problem. >>> >>> here's an example: >>> http://www.flickr.com/photos/jdory/6799702398/ >>> >>> Bottom image is with Digikam export. >>> >>> Here's more info: >>> >>> >>> digiKam version 2.5.0 >>> Exiv2 can write to Jp2: Yes >>> Exiv2 can write to Jpeg: Yes >>> Exiv2 can write to Pgf: Yes >>> Exiv2 can write to Png: Yes >>> Exiv2 can write to Tiff: Yes >>> Exiv2 supports XMP metadata: Yes >>> LibCImg: 130 >>> LibClapack: internal library >>> LibExiv2: 0.21.1 >>> LibJPEG: 80 >>> LibJasper: 1.900.1 >>> LibKDE: 4.8.00 (4.8.0 >>> LibKExiv2: 2.1.0 >>> LibKGeoMap: 2.0.0 >>> LibKdcraw: 2.0.1 >>> LibLCMS: 119 >>> LibPGF: 6.11.32 - internal library >>> LibPNG: 1.5.7 >>> LibQt: 4.8.0 >>> LibRaw: 0.14.4 >>> LibTIFF: LIBTIFF, Version 4.0.0 Copyright (c) 1988-1996 Sam Leffler >>> Copyright (c) 1991-1996 Silicon Graphics, Inc. >>> Marble Widget: 0.12.97 (0.13 Release Candidate 2) >>> Parallelized demosaicing: Yes >>> Database backend: QSQLITE >>> LibKface: 2.0.0 >>> LibKipi: 1.3.0 >>> LibOpenCV: 2.3.1 >>> Libface: 0.2 >>> _______________________________________________ >>> Digikam-users mailing list >>> [hidden email] >>> https://mail.kde.org/mailman/listinfo/digikam-users >> >> _______________________________________________ >> Digikam-users mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-users >> > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: trouble with image degradation using DK with kipi-plugin: flickr export
|
|
In reply to this post by Andrew Goodbody
On Sat, Mar 3, 2012 at 9:28 AM, Andrew Goodbody <[hidden email]> wrote:
I cannot get permission to check what the one uploaded by > Digikam says it is. > > Andrew > I'll unset it - it was private and will appear temporarily at the top of photostream: http://www.flickr.com/photos/jdory/ > On 03/03/12 17:41, Gilles Caulier wrote: >> >> I cannot see any color difference. >> >> If you upload a RAW file from digiKam to Flickr, it will take embeded >> JPEG image from RAW instead to process RAW file, to speed-up >> downloading. >> >> Gilles Caulier Gilles, If you don't see any difference, I also get that if I view it under my linux desktop in chrome browser. Under firefox it seems different. If I view it under my windows vm, then I see a clear difference. If I view it under my work windows workstation, I also see the difference. So I may have other issues going on. I don't remember having this problem using my convoluted workflow in the recent past, but haven't done any photo work in some time so not sure when or what changed. These are all jpegs I upload saved from tiff images. thanks guys for replys. /jim _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: trouble with image degradation using DK with kipi-plugin: flickr export
|
|
In reply to this post by Gilles Caulier-4
On Sat, Mar 3, 2012 at 10:07 AM, Gilles Caulier
<[hidden email]> wrote: > It's probably a side effect of resizement of image before uploading... > > Can you share original image to check if sRGB is set by PhotoShop or > another one ? > > Gilles Caulier For sharing original: I've got the original tiff from a scanned slide. It is about 31MB tiff image. Then the photoshop adjusted jpeg which is on flickr now. Was it the original you wanted to see (not photoshopped but scanned using viewscan software)? Otherwise the original is on flickr now and I've set the permissions to public. It is possible that my workflow is the problem. I'm used to working in photoshop and Lightroom under the winxp VM (I'm invested in the programs so hard to abandon). Haven't really made the switch to DK yet, though prefer it for some things so still use it for like uploading to flickr - tagging, general viewing and searching. So these recent Africa photos I did using photoshop and basically just adjusted the curves a bit, took a little of the blue out of them as they are scans from 30 year old slides, some sharpening.. etc. Nothing much in the way of processing. When upload to flickr with DK export, it looks like blue is back, the warming up I did is gone. thanks, Jim _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: trouble with image degradation using DK with kipi-plugin: flickr export
|
|
Lørdag den 3. marts 2012 11:08:53 Jim Dory skrev:
> On Sat, Mar 3, 2012 at 10:07 AM, Gilles Caulier > > <[hidden email]> wrote: > > It's probably a side effect of resizement of image before uploading... > > > > Can you share original image to check if sRGB is set by PhotoShop or > > another one ? > > Hi Jim, If the flickr kipi-plugin resizes the image for uploading, check the jpeg settings it uses, compression and resampling can be changed. Personally, I disable resampling and do a high quality for good results. Anders _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: trouble with image degradation using DK with kipi-plugin: flickr export
|
|
>> On Sat, Mar 3, 2012 at 10:07 AM, Gilles Caulier
>> >> <[hidden email]> wrote: >> > It's probably a side effect of resizement of image before uploading... >> > >> > Can you share original image to check if sRGB is set by PhotoShop or >> > another one ? >> > > > Hi Jim, > > If the flickr kipi-plugin resizes the image for uploading, check the jpeg > settings it uses, compression and resampling can be changed. Personally, I > disable resampling and do a high quality for good results. > > Anders Ok - that may be it.. quality was set for 85 and Resize was checked. I'll try another pic but right now it is a sunny day and I think I have to get outside and enjoy some winter snow activities.. /jd _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: trouble with image degradation using DK with kipi-plugin: flickr export
|
|
At first glance to this topic I browsed flickr site using chrome and did'nt see any difference like Gilles so what I figured out was a monitor issue or something like that; but now I compare flickr site using Firefox and chrome in two different windows and actually it is clear what Jim observed.
Very interested in other possible examples also using jpeg produced by digital camera and not only scanned images. Antonio
Il giorno 03 marzo 2012 23:16, Jim Dory <[hidden email]> ha scritto:
-- Antonio Trincone http://publicationslist.org/antonio.trincone http://www.icb.cnr.it/antonio.trincone/ http://sites.google.com/site/phototrincone/ http://sites.google.com/site/cvtrincone/home http://imaginesvolantscriptamanent.blogspot.com/ _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: trouble with image degradation using DK with kipi-plugin: flickr export
|
|
On Sun, 4 Mar 2012, Antonio Trincone wrote: > At first glance to this topic I browsed flickr site using chrome and did'nt > see any difference like Gilles so what I figured out was a monitor issue or > something like that; but now I compare flickr site using Firefox and chrome > in two different windows and actually it is clear what Jim observed. Very > interested in other possible examples also using jpeg produced by digital > camera and not only scanned images. > Antonio Hello... When Jim signaled the problem, I had a look at his images and I clearly saw the difference. One image with good looking warm tones, and the other a bit washed out and with a greenish overall tone. (And I saw that with my Firefox 10.0.1) After Antonio's e-mail, I've just did some extra tests and (maybe) found something interesting : 1. I look at the Flickr image with Firefox, looks good 2. I download the image file on my computer then open the file with Gwenview. Looks greenish ! (See my screen shot here : http://e-artefact.eu/scratch/screenshot-1.jpg The Firefox window is on the right of the screen, the Gwenview window on the left.) 3. More, I don't use the Flickr site any longer and open the downoaded image file from my disk, with Gwenview and with Firefox. (I.e. gwenview <filename> &; firefox <filename> &) Same results, see my screen shot : http://e-artefact.eu/scratch/screenshot-2.jpg So what : - Not a monitor effect, obviously, my screen is setup on sRGB color space - a viewer application effect, clearly. Antonio mentionned Firefox vs. Chrome, same with Firefox vs. Gwenview I had a look at the (downloaded) image file. It embeds an ICC color profile (Kodak ProPhoto RGB.) I did and extra test by creating a new JPEG file from the downloaded image, stripped from ALL what is not image datax (no more APP1, APP2 sections). Then, the displayed image always looks greenish, whatever the viewer is. My opinion : Some applications (e.g. Firefox) are able to display a JPEG image, using embedded color profiles, some (Chrome or Gwenview) aren't. Probably, images for the web should be processed in a compatible way to always provide JPEG data compatible with sRGB space, not relying on the use of an embedded color profile. If this could help Jim... Regards, Jean-François _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: trouble with image degradation using DK with kipi-plugin: flickr export
|
|
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. So for a workaround, Jim should export any jpegs that he intends to upload with Digikam into the sRGB colour space. At least that's how it seems to me... Andrew _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: trouble with image degradation using DK with kipi-plugin: flickr export
|
|
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. > 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. 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. Perhaps a reasonable model for standard web usage could be sRGB default, 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.) 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 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: trouble with image degradation using DK with kipi-plugin: flickr export
|
|
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 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: trouble with image degradation using DK with kipi-plugin: flickr export
|
|
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. (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 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: trouble with image degradation using DK with kipi-plugin: flickr export
|
|
In reply to this post by Andrew Goodbody
Ok, I knew that I should be using the sRGB and figured I was as I set
it up in photoshop once. But maybe after a few upgrades and perhaps some uninformed tinkering, I borked that setting. I checked photoshop and it is set in 'Color Settings' as sRGB IEC61966-2.1. After I posted this problem I checked Digikam's color setting and it was I thought on sRGB IEC61966-2.1 (srgb_color_space_profile.icm) but not sure where it should be there. There's a couple to choose from. I suppose it must have been on the Scarce: ProPhoto Kodak setting but I wouldn't have chosen that one. I'll research how it should be set up. /jim _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: trouble with image degradation using DK with kipi-plugin: flickr export
|
|
On 04/03/12 18:41, Jim Dory wrote:
> Ok, I knew that I should be using the sRGB and figured I was as I set > it up in photoshop once. But maybe after a few upgrades and perhaps > some uninformed tinkering, I borked that setting. I checked photoshop > and it is set in 'Color Settings' as sRGB IEC61966-2.1. I have never used photoshop but my brother has. He had a similar issue with images looking washed out when uploaded to the web due to colour space issues. All I really remember about his solution was that he found a different place in the photoshop settings to specify the colour space of exported files. The image that looks correct, the one with the embedded profile, this one shows no sign of editing by digikam in the exif data. So I really do think that the ProPhotoRGB is coming from photoshop. Keep digging in the settings. > After I posted this problem I checked Digikam's color setting and it > was I thought on sRGB IEC61966-2.1 (srgb_color_space_profile.icm) but > not sure where it should be there. There's a couple to choose from. I > suppose it must have been on the Scarce: ProPhoto Kodak setting but I > wouldn't have chosen that one. > > I'll research how it should be set up. > > /jim Andrew _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: trouble with image degradation using DK with kipi-plugin: flickr export
|
|
On Sun, Mar 4, 2012 at 11:19 AM, Andrew Goodbody <[hidden email]> wrote:
> > I have never used photoshop but my brother has. He had a similar issue with > images looking washed out when uploaded to the web due to colour space > issues. All I really remember about his solution was that he found a > different place in the photoshop settings to specify the colour space of > exported files. > The image that looks correct, the one with the embedded profile, this one > shows no sign of editing by digikam in the exif data. So I really do think > that the ProPhotoRGB is coming from photoshop. Keep digging in the settings. > Under Edit/Assign profile../ there was the ProPhoto setting.. I changed it to the sRGB one and the image I happened to have open reverted back to undesirable state. So that seems to be it. thanks, sure appreciate it. Jim. _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: trouble with image degradation using DK with kipi-plugin: flickr export
|
|
In reply to this post by Jean-François Rabasse
On 04/03/12 18:14, Jean-François Rabasse wrote:
> 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. I think we basically agree about this in fact, but you are not quite understanding what I was saying. To answer your points above, I agree that the KDE software should encourage the use of sRGB, at least for when images are targeted for display on the web, to ensure the greatest amount of interoperability with current software, including non-KDE software. But we cannot prevent people from making other choices. There are many valid reasons for wanting to use a different colour space, which is after all why the other colour spaces exist in the first place. So it would be very good to get an option in the various web upload plugins in digikam to convert the images to sRGB as part of the upload, possibly even make it the default action. But if the user chooses not to do that then any pre-existing embedded profile should be preserved through the resize process. What I was saying was not about new images created or edited by KDE software but that in order for the KDE software to be able to best cope with images that are not in sRGB but do have an embedded ICC profile then that should result in an image that can be displayed properly directly on the user's computer. Currently Gwenview seems to be ignoring the embedded profile. This is just a bug that should be fixed IMO. This has nothing to do with non-KDE software nor anything to do with display on the web. I have the file locally and it is not rendered correctly by the KDE software I have on this machine. Andrew _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Jim Dory-2
Progress that is. I've been tagging 1000s of images and I must say that
doing so brings my dual-core Lenovo desktop to its knees. It's not pretty LOL But, Digikam is doing the job. But I noticed that the progress bar that says "Writing metadata to files. Please wait...(0%)" never says anything else -- that percentage stays at 0 no matter how long it takes and what I assumed (?) was a progress bar doesn't progress. Is that right? Guy -- "There is only love, and then oblivion. Love is all we have to set against hatred." (paraphrased) Ian McEwan Guy Stalnaker [hidden email] _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Please, feedback in this file :
https://bugs.kde.org/show_bug.cgi?id=295263 Note : specify which CPU you have. Operations are paralelized, and we need to know if you have multi-core or not... Thanks in advance. Gilles Caulier 2012/3/5 Guy Stalnaker <[hidden email]>: > Progress that is. I've been tagging 1000s of images and I must say that > doing so brings my dual-core Lenovo desktop to its knees. It's not pretty > LOL > > But, Digikam is doing the job. But I noticed that the progress bar that says > "Writing metadata to files. Please wait...(0%)" never says anything else -- > that percentage stays at 0 no matter how long it takes and what I assumed > (?) was a progress bar doesn't progress. > > Is that right? > > Guy > > > -- > "There is only love, and then oblivion. Love is all we have > to set against hatred." (paraphrased) Ian McEwan > > Guy Stalnaker > [hidden email] > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
«
Return to digikam-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |