[forum.kde.org] [Bug 386161] Cannot log in to KDE community forums
https://bugs.kde.org/show_bug.cgi?id=386161 Elle Stone changed: What|Removed |Added CC||ellestone@ninedegreesbelow. ||com --- Comment #4 from Elle Stone --- Feel totally free to close this bug. I can't reproduce it as I finally managed to log in, as I already said in the comments. Though today I had to request to reset my password (to exactly what it already was) in order to log in to make this comment. Why does kde bugs not use kde identity? It would be nice, per my original request in the comments to this bug, if there were a clear page of "what to do when login fails", with the page leading to an actual contact email or forum where help can be obtained without first signing in. I think the root problem of my inability to sign in (today, and also in 2017), is that KDE "something" (bugs? identity? something else?) is storing (or hopefully *was* storing, as I did delete an old email address today, that I thought had long ago been deleted) an old email address and user name, somewhere, which gets triggered when I attempt to log in using my current email and address. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 386396] Eliminate useless and misleading libpng terminal message
https://bugs.kde.org/show_bug.cgi?id=386396 --- Comment #1 from Elle Stone <e...@ninedegreesbelow.com> --- Hmm, digiKam terminal output just printed a useless libpng warning that I've never seen before: digikam.dimg: "/hdd/edit/edit/archiveprints/20080416 pond leaves/586-587.png" : PNG file identified libpng warning: iCCP: profile 'ICC profile': 0h: PCS illuminant is not D50 The profile in question is an old Kodak Romm profile directly from the old Kodak website. Apparently libpng is now checking profile illuminant values, and complaining about the following discrepancy (using iccToXml to print out the profile contents: What is in the old Kodak profile: What is in most profile's illuminant field (until iccMAX comes along and makes it OK to use other illuminants): This libpg warning is useless. Users won't know what to do with it. The profile is fine just as it is. Yes, the D50 illuminant values are slightly off from what is normally found in V2 and V4 ICC profiles. No, this small difference won't make a bit of practical difference to the user, especially in a V4 CMM such as LCMS2 provides. All this warning does is confuse the user (if they see it) and waste processing time to detect and print. AFAIK no other file format prints such warnings. As the warnings are about things that make no difference whatsoever to users, it would be good to disable the libpng warnings to keep them from being printed to the terminal, where they might confuse users. In fact they do confuse users, as a search on the internet will quickly show. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 386396] New: Eliminate useless and misleading libpng terminal message
https://bugs.kde.org/show_bug.cgi?id=386396 Bug ID: 386396 Summary: Eliminate useless and misleading libpng terminal message Product: digikam Version: 5.7.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: FilesIO-PNG Assignee: digikam-bugs-n...@kde.org Reporter: e...@ninedegreesbelow.com Target Milestone: --- Upon creating a new database, and probably every time digikam is run, the following lines are printed to the terminal: digikam.dimg: "/usr/share/digikam/data/sample-aix.png" : PNG file identified digikam.metaengine: Loading image history "" digikam.metaengine: DateTime => Exif.Photo.DateTimeOriginal => QDateTime(2010-07-27 06:40:05.000 EDT Qt::TimeSpec(LocalTime)) libpng warning: iCCP: known incorrect sRGB profile For unfathomable reasons, libpng searches for and flags certain sRGB profiles as problematic. Once such profile is an sRGB profile that is commonly found on Windows computers and consequently also in images downloaded from the internet. There is absolutely nothing wrong with this profile and probably nothing with other profiles that libpng flags. But the error messages cause consternation for users. This GIMP bug report has a patch that shows how to eliminate this misleading libpng "known incorrect sRGB profile" terminal message: Deal with libpng error gracefully when exporting an image with the color profile "sRGB IEC61966-2.1": https://bugzilla.gnome.org/show_bug.cgi?id=765850#c3 The GIMP bug report references an imagemagick forum discussion on the topic. Quoting from the GIMP bug report: #Begin quote: The attached patch suppresses these libpng terminal warnings. It just adds this option: png_set_option(pp, PNG_SKIP_sRGB_CHECK_PROFILE, PNG_OPTION_ON); But maybe I should have added all of this as per the third-from-last post #if defined(PNG_SKIP_sRGB_CHECK_PROFILE) && \ defined(PNG_SET_OPTION_SUPPORTED) png_set_option(png, PNG_SKIP_sRGB_CHECK_PROFILE, PNG_OPTION_ON); #endif This option to suppress the libpng known incorrect sRGB profile warning is available starting with libpng 1.6.11, which was released back in 2014. #End quote. Of course the patch attached to the GIMP bug report (https://bug765850.bugzilla-attachments.gnome.org/attachment.cgi?id=334241) won't work with digiKam. But the relevant code changes to disable the png warnings are hopefully easy to port over to digiKam. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 381625] Copying/Moving photograph files between albums does not give Overwrite/Rename/Cancel options if file with same name exists in the destination album.
https://bugs.kde.org/show_bug.cgi?id=381625 Elle Stone <e...@ninedegreesbelow.com> changed: What|Removed |Added CC||e...@ninedegreesbelow.com --- Comment #13 from Elle Stone <e...@ninedegreesbelow.com> --- I'm trying to sort through a *lot* of image files - for which there are quite a few duplicates and also quite a few files in the wrong folder. Whenever I move an image file from one album to another, if there is already a file by that name, two things happen: 1. A "popup" - very discrete and easy to overlook, sort of glides up from the bottom of the screen to say that there is already a file by the same name in the destination album. It's very easy to overlook this "glide up" and very discrete notice. As noted already, there are no options provided to "overwrite" or "move and rename" or "do nothing". 2. The thumbnail does immediately - but only temporarily! - disappear from the album currently being viewed!!! This is not a good thing!!! It looks like the image was actually moved, but it wasn't, and eventually the "moved" item shows back up in the original album. Going to the file manager to move these files around really isn't an option as the file names all are very similar. I guess I'll try opening another image viewer, though that will make the screen very crowded. This is on digiKam 5.7.0. Automatically renaming with an added number doesn't sound like a good solution. In my case it would just create more files that I'd need to sort through. The simplest thing would be to simply not move the file at all, and also don't make it *look* like the file was moved, which is currently what is happening. Although I am running Gentoo, so perhaps this "temporarily disappears from view" problem is specific to my Gentoo distribution. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 309341] digiKam doesn't write XMP-tiff Orientation tag for raw files
https://bugs.kde.org/show_bug.cgi?id=309341 --- Comment #6 from Elle Stone <e...@ninedegreesbelow.com> --- (In reply to caulier.gilles from comment #4) > This file still valid using last digiKam 5.0.0 ? > > Gilles Caulier I don't know about 5.0.0, but for 5.7.0 writing to the sidecar doesn't seem to work very well under any circumstance, at least not when using sqlite. I'll try to remember to check the orientation flag if/when I switch to mariadb. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 312551] showFoto displays camera jpegs with AdobeRGB DCF information with a blue color cast
https://bugs.kde.org/show_bug.cgi?id=312551 --- Comment #9 from Elle Stone <e...@ninedegreesbelow.com> --- (In reply to caulier.gilles from comment #7) > This problem still reproducible with digiKam 5.0.0 ? > > Gilles Caulier Checking digiKam 5.7.0, this no longer appears to be a problem. I seem to recall the actual problem was with profiles supplied by some other KDE package, and those profiles have been fixed. My apologies for taking so long to check digiKam - I had completely forgotten about this bug report. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 383326] Moving a tag does not update the parent tag correctly
https://bugs.kde.org/show_bug.cgi?id=383326 Elle Stone <e...@ninedegreesbelow.com> changed: What|Removed |Added CC||e...@ninedegreesbelow.com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 386224] Metadata is not updated when moving tags
https://bugs.kde.org/show_bug.cgi?id=386224 Elle Stone <e...@ninedegreesbelow.com> changed: What|Removed |Added CC||e...@ninedegreesbelow.com -- You are receiving this mail because: You are watching all bug changes.
[forum.kde.org] [Bug 386161] Cannot log in to KDE community forums
https://bugs.kde.org/show_bug.cgi?id=386161 --- Comment #1 from Elle Stone <e...@ninedegreesbelow.com> --- (In reply to Elle Stone from comment #0) > How do I recover my KDE community forums login information? I did eventually manage to log in, by iterating through several possible combinations of passwords and user names, combined with making a few lucky guesses regarding the user name. Even so, I think this bug should remain open until KDE forums implements an obvious and straightforward way for a user to deal with situations where an attempt to log into the forums has failed. A link to a "how to" would solve the problem, including not just "how to reset the password" (which I didn't need to do - I had the right password) but also "how to retrieve the user name or else get a new user name", and as a last resort an actual way to send an email to someone at KDE who can deal with problems not covered in the "how to". -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 386161] New: Cannot log in to KDE community forums
https://bugs.kde.org/show_bug.cgi?id=386161 Bug ID: 386161 Summary: Cannot log in to KDE community forums Product: kde Version: unspecified Platform: Gentoo Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: e...@ninedegreesbelow.com Target Milestone: --- I tried to log into KDE community forums. My login attempts were rejected as invalid. I tried to request a new password. My attempt was rejected as not being recognized or some such thing. I tried to register again, even though I'm already registered, and my attempt to register was rejected as spam. I clicked on the sysadmins link and was taken to an LDAP login page. As I can't log in directly to the forums, I'm pretty sure I won't be able to log in using whatever LDAP is. How do I recover my KDE community forums login information? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 --- Comment #16 from Elle Stone <e...@ninedegreesbelow.com> --- (In reply to Tyson Tan from comment #15) > MS and Adobe both supplies a sRGB V2 profile with their software. Adobe also > provides a color profile download that includes sRGB and AdobeRGB profiles. Do you have a link? I checked the Adobe website about a month ago, and there were no sRGB profiles in the download pack, and haven't been for quite awhile. > Last time I checked, the said sRGB profiles was produced by ICC in the meta > information. Ubuntu also has a similar sRGB profile to generate default ICC > for everything. If you cannot find them, I can extract them later for you. I'm not sure what you mean by "Last time I checked, the said sRGB profiles was produced by ICC in the meta information." A kind person sent me two files exported from CS5 and CS6 with embedded sRGB profiles, and the copyright was by Hewlett-Packard. The sRGB profiles downloadable from color.org are copyrighted by the ICC. These are the only sRGB profiles I've ever seen that are copyrighted by the ICC. Your offer to send extracted profiles is very kind, but there's no need. I have an extensive collection of sRGB profiles from a previous investigation of "the" sRGB profile. And I'm pretty sure that if you extracted a profile from an image and sent the profile to me, and the profile wasn't copyrighted as CC0, public domain, etc, then you'd be violating the profile copyright. Fortunately you can easily eximine embedded profiles by using exiftool: exiftool filename.png As an aside, the sRGB profile embedded by CS5/CS6 (one on Windows, one on Mac) in the two images that were sent to me is a profile that libpng marks as "known incorrect sRGB profile". The CMM tag says "Lino" and the copyright tag says Hewlett-Packard. I could be wrong, but I think this profile might be distributed by the OS, not by PhotoShop. Of course this doesn't preclude the possibility that there really is an ICC-copyrighted sRGB profile distributed along with some versions of PhotoShop. If Firefox with default settings on OSX treats the old "Lino" profile as sRGB, how does it treat Graham Gill's sRGB.icm profile? If you wouldn't mind checking, I included a png with Graham Gill's profile embedded in my post to my website (http://ninedegreesbelow.com/bug-reports/browsers-and-icc-profiles.html). > The cheapest workaround is simple: change the default value of “Embed sRGB > profile” to UNCHECKED, and ideally add some explanation text below so people > don’t try to be smart by checking it. We are already doing that when > exporting JPG, why not PNG too? I understand that as a developer, you want > things to work according to the standard with a correct process. But people > just want to see correct result. As long as the user has a chance to check the box to embed the profile, and keep that box checked, instead of having to check it every time, your solution sounds reasonable. But it results in what the esteemed Bruce Fraser called "mystery meat" images. In an ICC profile color managed workflow, images need embedded ICC profiles. I understand that there are exceptions. And it's a shame that Firefox has created such a disaster for color managing images posted to the web. But it would be best if Krita users have the option to made a choice to embed (or not embed) a profile and have that choice "stick" until they deliberately make the opposite choice. Best, Elle -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 367832] Do not export PNG with Embed sRGB profile checked by default because Firefox color shift and more.
https://bugs.kde.org/show_bug.cgi?id=367832 Elle Stone <e...@ninedegreesbelow.com> changed: What|Removed |Added CC||e...@ninedegreesbelow.com --- Comment #13 from Elle Stone <e...@ninedegreesbelow.com> --- (In reply to Tyson Tan from comment #0) > 9) . . . Adobe Photoshop's sRGB > embedded picture is not affected because Photoshop embeds the official sRGB > profile from ICC. Krita is affected because sRGB-elle-V2-srgbtrc.icc is not > official and Firefox consider it to be a calibrated ICC. >From curiosity, which official sRGB profile from the color.org website (http://www.color.org/srgbprofiles.xalter) does PhotoShop embed? Or does PhotoShop use some other sRGB profile, maybe a V4 matrix profile? If PhotoShop embeds a V4 version of sRGB (matrix or LUT), then Firefox default settings (as of v 38) will ignore the embedded profile. In case it might be useful, I put up a test page so people can easily check to see what their browser/OS/settings do with various versions of the sRGB profile embedded in pngs (I'll try to add the same images saved as jpegs later today): http://ninedegreesbelow.com/bug-reports/browsers-and-icc-profiles.html > Actual Results: > So all and all, Firefox is doing its job according to the rules, while the > OS is supplying it with a wrong reference, causing the color shift to > happen. There is nothing we can do about it unless the ICC people realized > it. Or they did this for some unknown reason. Firefox is doing its job according to its own rules. The real rule is that untagged images should be treated as if they are sRGB images, not as if color management were suddenly disabled. To get Firefox to "act by the rules" you need to change the default settings. > Expected Results: > Although it's technically not Krita's fault, we can do something to avoid > being affected. So far Krita saving as JPG has ICC off by default, which is > a good thing. All we need is to turn off ICC for PNG (and all other > universal formats that has the ability to embed ICC). Disabling embedding ICC profiles to satisfy mishandled color management in various browsers and operating systems, and/or to accomodate user ignorance seems to me to be a very bad idea for a color-managed editing application. Having a special "export for the web" option that tries to accomodate browser issues on various OS's might be a possibility. It might work to change the default Krita sRGB profile to the V4 version with the parametric curve. Firefox with default settings doesn't read V4 profiles. Quoting from Comment 9 in the first post: "9) Firefox detects the embedded ICC profile of the picture. If it's sRGB, it will not color manage it, hence no color shift. Adobe Photoshop's sRGB embedded picture is not affected because Photoshop embeds the official sRGB profile from ICC. Krita is affected because sRGB-elle-V2-srgbtrc.icc is not official and Firefox consider it to be a calibrated ICC. " Has this "detect and don't color manag sRGB images" been implemented in Firefox? I remember hearing some discussion on this point. If this is part of the problem, then a bug report should be filed with Firefox to revert this behavior. The so-called justification for this move was to keep web developers happy, who can't be bothered to simply remove the embedded ICC profile before uploading web design elements. The simpler course would be if Firefox made the default setting for color management be 1 instead of 2. My opinion counts for exactly nothing as I'm not planning on making a campaign out of fixing browser and OS color management. But in my opinion: * OSX color management pipeline seems broken, and if it is, it needs to be fixed instead of expecting developers to work around the problems: https://bugzilla.gnome.org/show_bug.cgi?id=708579 * Color.org needs to change their profile copyrights to be compatible with free/libre software and also stop pretending Linux doesn't exist, and also fix their V2 sRGB profile so the purported black point and the TRC actually agree, and maybe even figure out how to have sRGB white R=G=B=1.0f map to LAB (100,0,0) in relative colorimetric conversions, instead of to off-white (99.998820, 0.018274, -0.016832). * Color.org needs to supply a V4 sRGB profile that is a bog-standard matrix profile, and also supply better guidelines regarding "use this profile for this purpose". Surely no one is embedding the V4 LUT sRGB profiles in images uploaded to the web. But if they are, then at this point in time these profiles are either being ignored or else sometimes very wrongly interpreted depending on the browser and the settings and probably on the OS, or if the browser does correctly read these profiles, the resulti
