[Bug 1436595] Re: Images too bright
This is due to color management. I think I filed a bug report on the Gnome bugtracker with slightly different information, but regarding brightness jumping from 0 to ~5 out of 255: According to http://www.lagom.nl/lcd-test/black.php, with 6-bit dithering, usually "the darkest four shades (0, 1, 2, 3) all are displayed as black regardless of the monitor settings." Most models of my laptop didn't have LED backlights, and maybe the default color profile for my laptop model was intended for those non-LED backlights. Although my screen is 6-bit, shades 1~3 are still discernible. In any case, turning off color management fixed the problem for eog, and presumably for Firefox as well after a restart. ** Changed in: eog (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1436595 Title: Images too bright To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1444881] [NEW] Autocomplete in 'open file' works wrong with folders
Public bug reported: This is related to what might also be a bug, where directories aren't displayed at the top when sorting files by name in the 'open file' dialogue. I think it used to work this way, but changed between Ubuntu 12.04 and 14.10. So the fastest way to open files is often by typing. When an autocompleted folder name is displayed and is the only possible result for a path starting with those characters, pressing tab will cause the autocompleted text to be entered, while pressing enter normally causes the autocompleted folder to be navigated to. If there is a file that starts starts with that folder's name in the same directory, the bug described in this report doesn't occur. But if no such file exists, then if all files in the autocompleted folder start with the same letters, then pressing tab while the autocompleted folder's name is highlighted will cause those common letters to appear. Pressing enter instead of tab at the first step will instead cause a file to be opened with the name of those common letters. The case where I encounter this bug is manual files for ffmpeg, which all start with 'ff' (and Ubuntu doesn't package ffmpeg which is why I'm opening them with gedit). Autocompletion includes the '/' used to denote folders. So, for example, in the folder /tmp/h, you have these files: i il iif/ iiif/ In the 'open files' dialogue, if you type '/tmp/h', an autocompleted '/' appears. The expected behaviour is that if you press enter, you'll navigate to /tmp/h and view the files it contains. What actually happens is it opens '/tmp/h/i' for editing. Immediately after presseing enter while the autocompleted '/' is displayed, it turns a normal colour (instead of having autocompletion highlighting), an autocompleted 'i' appears, and the open file dialogue closes, having selected 'i' to open. If there is also a file '/tmp/hi', then the '/' is not autocompleted, and pressing enter will just open the folder and display the letter 'i'. If, instead, there is a folder /tmp/h/uuu/ and a file /tmp/h/, and the folder uuu contains another folder u/ and a file , typing '/tmp/h/u' will cause an autocompleting 'uu' to be displayed (no '/' at the end), and pressing enter will just display the folder. If the file /tmp/h/ is removed or renamed to be shorter than uuu/, then instead of 'uu', 'uu/' will be autocompleted, and pressing enter will cause the folder /tmp/h/uuu/u/ to be opened, which is empty. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: gedit 3.10.4-0ubuntu6 ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3 Uname: Linux 3.16.0-30-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8.3 Architecture: amd64 CurrentDesktop: Unity Date: Thu Apr 16 01:32:26 2015 SourcePackage: gedit UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: gedit (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug utopic -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gedit in Ubuntu. https://bugs.launchpad.net/bugs/1444881 Title: Autocomplete in 'open file' works wrong with folders To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/1444881/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1444839] [NEW] jpeg-2000 files cause Nautilus to crash
Public bug reported: Diagnosing this bug may be complicated by Bug #1443809. I am currently using a custom thumbnailer for jpeg-2000 files, but before I did so, I had created a number of jpeg-2000 files. While there were some cases where they caused a crash, I think the eventual result was that they all had 'failed thumbnails' created for them. Possibly eog created valid thumbnails for them. (I can't check to see what happened because I deleted my old thumbnails folder after upgrading.) With no custom thumbnailers, nautilus will crash upon encountering a jpeg-2000 file, with file suffix .jp2. As noted in Bug #1444790, it doesn't crash if the jpeg-2000 file has a different suffix; it just produces a 'failed thumbnail' in the thumbnails folder, which for current Ubuntu versions is ~/.cache/thumbnails/fail. If the file was created by copying an existing jpeg-2000 file in nautilus, nautilus still crashes but only after invoking eog to create a thumbnail, so after this is complete, navigating to that folder won't cause a crash. If the thumbnail check was performed because the jpeg-2000 file was renamed from an inappropriate suffix to .jp2, or because it was renamed by some other method while not looking at the directory containing that file (such as the command line, or maybe using the 'undo' function in nautilus though this would require 1) having a normal or failed thumbnail 2) renaming the file 3) deleting the thumbnail 4) nautilus would have to stop using the cached thumbnail, and I don't think it does), nautilus will crash without invoking eog for thumbnail creation, and so will continue to crash whenever that folder is viewed. A jpeg-2000 file can be generated using mogrify from imagemagick with the command 'mogrify -format jp2 image.jpg'. The advantages and disadvantages of jpeg-2000, compared to jpeg, are described here: http://x264dev.multimedia.cx/archives/317 The type of encoding used by jpeg-2000 is better for edges, while that used for jpeg is better for broad areas of smaller, but nonzero amounts of variation. There are definitely cases where jpeg-2000 is a better choice than jpeg for retaining what is viewed as a sufficient level of quality in an image, but users are unlikely to use it more if their applications don't support it very well. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: nautilus 1:3.10.1-0ubuntu15.1 ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3 Uname: Linux 3.16.0-30-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8.3 Architecture: amd64 CurrentDesktop: Unity Date: Wed Apr 15 22:52:39 2015 GsettingsChanges: b'org.gnome.nautilus.list-view' b'default-visible-columns' b['name', 'size', 'date_modified', 'date_accessed', 'type'] b'org.gnome.nautilus.list-view' b'default-column-order' b['name', 'size', 'date_modified', 'date_accessed', 'type', 'group', 'where', 'mime_type', 'owner', 'permissions'] SourcePackage: nautilus UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: nautilus (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug utopic -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1444839 Title: jpeg-2000 files cause Nautilus to crash To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1444839/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1444790] Re: crash if thumbnailer fails to produce output
After removing custom thumbnailers, copying a jp2 file using ctrl-C ctrl-V causes nautilus to crash about one time. gnome-thumbnailer tries to create a thumbnail, but it can take several seconds, and if nautilus is reopened and navigated to that folder again, it will crash again. However, after this has been completed, nautilus won't crash. (In fact, top reveals that it's eog that creates the new thumbnail if you use ctrl-C ctrl-V in nautilus.) If the new file name is obtained a different way, like using 'mv' on the command line, navigating to that folder in nautilus will cause a crash without attempting to generate a new thumbnail. So even if you wait several seconds, no thumbnail will exist for the file and nautilus will crash every time you navigate to that folder until you delete the file or rename it to a path for which it will have a valid thumbnail (meaning the file's mtime is correct). So this might only affect jpeg-2000 files, and not all files for which there is no valid output. Maybe with other files, the default thumbnail options (the ones not recorded in /usr/share/thumbnailers) consistently create at least a failed thumbnail, while this doesn't happen with jpeg-2000 files. But since nautilus is crashing before eog finishes creating a thumbnail (if using ctrl-C ctrl-V to copy), nautilus might be relying on a separate process from what it depends on for, say, obtaining a 'failed thumbnail' result for incomplete mp4 files, which don't cause a crash. One difference is that while gnome-thumbnailer has code for handling image formats as a fallback method, it isn't for video formats. I'm not sure if it's nautilus or gnome that's calling eog to create a thumbnail when ctrl-C ctrl-V is used. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1444790 Title: crash if thumbnailer fails to produce output To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1444790/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1318327] Re: Can't open .webp files
The bug for libwebp seems to be Bug #1407644. Should one of these bugs be marked as a duplicate and the other project added to the list of affected projects? I notice that ffmpeg (possibly with the right compile options) can open .webp files, and ffmpeg uses the GNU General Public License version 2+ though that particular decoder might not. eog also seems to use the GNU General Public License version 2+. The other bug report says that using a gdk-pixbuf loader is the right way to extend support, but in the meantime, could eog just use code from ffmpeg, or even ffmpeg directly? (Imagemagick, for example, uses ffmpeg to open video files.) It seems that having a poor solution may be better than having no solution, if there is currently no motivation to implement the 'correct' solution. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1318327 Title: Can't open .webp files To manage notifications about this bug go to: https://bugs.launchpad.net/eog/+bug/1318327/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1444790] [NEW] crash if thumbnailer fails to produce output
Public bug reported: Step 1: Use a custom thumbnailer which doesn't always produce output. I'm personally using this one, since the default size (256x256) often produces a png thumbnail which takes more space than the original jpg image, and imagemagick's convert seems to have a bug for palette-png to grayscale conversion: [Thumbnailer Entry] TryExec=ffmpeg Exec=ffmpeg -i %i -vf scale='min(iw,128):min(ih,128):force_original_aspect_ratio=decrease',format=rgba|rgb24 -frames 1 -y -f image2 -c:v png %o MimeType=image/gif;image/jpeg;image/png;image/jp2;image/x-webp Step 2: navigate to a folder that the thumbnailer can't handle. For me, that was balloon.jp2 from http://opf-labs.org/format-corpus/jp2k- formats/ My version of ffmpeg says on the command line that Progression order RPCL is not implemented. [...] Output file is empty, nothing was encoded. Not having any file from the thumbnailer, or maybe having an empty, 0-byte file (ffmpeg does not produce a 0-byte output file from the command line), causes nautilus to freeze and crash. This happened multiple times. However, just now I checked and it didn't crash, and a thumbnail exists for the jp2 image, /sigh. But creating a copy of the jp2 image does lead to crashes. Ok, the reason is that eog creates a thumbnail when one doesn't exist and the system's default thumbnailers fail. Opening the image gallery in eog causes thumbnails to be created for all visible images. That is, when running eog from a terminal, opening the image gallery caused ffmpeg's output (with the error message) to be displayed in that terminal. But the thumbnail is still created, and eog must have done it. It's also possible nautilus crashes when the fallback gnome-thumbnailer fails to create a file, which I think is what happens when it tries to open a jpeg-2000 file. A few months ago I noted this bug: Another bug, crashes when trying to generate thumbnail for jpeg-2000 (jp2). Avoided if thumbnail is already created, maybe in some other cases too. Possibly just when thumbnail isn't created quickly enough (thumbnailer fails or something). ...but apparently I fixed it somehow, not sure. So it's totally fine that no thumbnail is created when the existing thumbnailer entries aren't sufficient. But nautilus shouldn't crash. When running nautilus from the command line, it says there was a segmentation fault, core dumped, with a crash file being generated in /var/crash (which I'm deleting). ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: nautilus 1:3.10.1-0ubuntu15.1 ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3 Uname: Linux 3.16.0-30-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8.3 Architecture: amd64 CurrentDesktop: Unity Date: Wed Apr 15 20:48:20 2015 GsettingsChanges: b'org.gnome.nautilus.list-view' b'default-visible-columns' b['name', 'size', 'date_modified', 'date_accessed', 'type'] b'org.gnome.nautilus.list-view' b'default-column-order' b['name', 'size', 'date_modified', 'date_accessed', 'type', 'group', 'where', 'mime_type', 'owner', 'permissions'] SourcePackage: nautilus UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: nautilus (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug utopic -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1444790 Title: crash if thumbnailer fails to produce output To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1444790/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1444807] [NEW] jpeg-2000 images appear in a window of the wrong size
Public bug reported: jpeg-2000 images appear in a small window, the smallest allowed by eog, instead of at the size of the image (or some other large size if the image is larger than the screen). This happens for both jp2 images output from imagemagick's convert and mogrify, and from a reference image at http://opf-labs.org/format-corpus /jp2k-formats/ . Note that due to Bug #1444790, the reference .jp2 image on that site may cause nautilus to crash when viewing a directory it's saved in, but eog can display the image fine (and creates a thumbnail so viewing the directory won't cause another crash). eog can correctly display these images, and their image size shows up in exiftool or imagemagic's 'identify', so this information should also be available to eog when opening them. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: eog 3.12.2-0ubuntu2 ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3 Uname: Linux 3.16.0-30-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8.3 Architecture: amd64 CurrentDesktop: Unity Date: Wed Apr 15 20:00:46 2015 SourcePackage: eog UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: eog (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug utopic -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1444807 Title: jpeg-2000 images appear in a window of the wrong size To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1444807/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1444790] Re: crash if thumbnailer fails to produce output
If you rename a jp2 file to jpg, it doesn't cause nautilus to crash. It just shows the 'generic image' icon that's also used if an image is larger than the limit set for previewing, and eog is unable to open it. If a jp2 file is renamed to have a non-image suffix, nautilus will be busy (100% cpu) for a second or two and then the image will use the 'generic icon', without nautilus crashing. With image suffixes, this doesn't occur. I also managed to replicate a bug that I avoided reporting earlier because I couldn't replicate it again. A png image has a 'corrupted' thumbnail, what is obviously the result of the file being read in an unfinished state. That is, gnome-thumbnailer or nautilus, or whatever is creating thumbnails, should be waiting until a file's modification time is 3 seconds in the past before trying to create a thumbnail for it, based on the code I looked at. This seems to work for video files, but not for images. When this happened before I verified that the difference between the modification time for the thumbnail (now in ~/.cache/thumbnails in Ubuntu, previously in ~/.thumbnails), and the time for the file as recorded in the thumbnail's PNG data and the same as for the actual file, was less than three seconds, being around 1 second. Maybe nautilus is not using this code though. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1444790 Title: crash if thumbnailer fails to produce output To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1444790/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1443794] [NEW] Folders with large names cause icons to disappear
Public bug reported: if displayed path is too long, window expands. Might be related to font, if number of characters before inserting ellipsis is decided before font is rendered. the tools to the right of the path are pushed right, even if this pushes them off the rendered window. minimum is apparently 675 pixels, before borders from window manager. icons also expand into the new space, so the rightmost rows can end up off-screen. reset by using a path that avoids folders with names that are too long, either before or after the current folder. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: nautilus 1:3.10.1-0ubuntu15.1 ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3 Uname: Linux 3.16.0-30-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8.2 Architecture: amd64 CurrentDesktop: Unity Date: Tue Apr 14 00:34:47 2015 GsettingsChanges: b'org.gnome.nautilus.list-view' b'default-visible-columns' b['name', 'size', 'date_modified', 'date_accessed', 'type'] b'org.gnome.nautilus.list-view' b'default-column-order' b['name', 'size', 'date_modified', 'date_accessed', 'type', 'group', 'where', 'mime_type', 'owner', 'permissions'] SourcePackage: nautilus UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: nautilus (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug utopic ** Attachment added: Screenshot from 2015-04-14 00:37:17.png https://bugs.launchpad.net/bugs/1443794/+attachment/4374731/+files/Screenshot%20from%202015-04-14%2000%3A37%3A17.png -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1443794 Title: Folders with large names cause icons to disappear To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1443794/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 797485] Re: Status Bar Covers File Name at Bottom
I don't feel like commenting on the Bugzilla bug report, which states that . . . blockquoteWe will remove the floating bar after releasing 3.16, so probably this won't be need at all./blockquote . . . but this could be fixed by increasing the vertical scrollable size of the window when the last row is selected. The vertical size already increases based on the length of file names in the last row, this would just be an extension of that. The comment on Bugzilla also does not say what they are replacing the floating bar with. Being able to see the size of a file, without having file size always enabled at default zoom level, using just a single click is useful and it shouldn't go away. Alt-enter is not a replacement because it takes longer, and not everyone has a fast computer. The lag it takes to open the properties window also seems to scale with the number of items in the folder. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/797485 Title: Status Bar Covers File Name at Bottom To manage notifications about this bug go to: https://bugs.launchpad.net/nautilus/+bug/797485/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 952108] Re: [Precise] Nautilus: memory leak
I don't know if there are multiple memory leaks, but I am reporting on this one. The Bugzilla report is not relevant to my particular version as one comment on Bugzilla says this: Obviously also related to wcslen so correctly closed as NOTABUG in Nautilus because it is not a bug in Nautilus. wcslen is described as Get wide string length. Returns the length of the C wide string wcs. This is the number of wide characters between ... So while the Bugzilla report as marked as RESOLVED DUPLICATE, I am reporting a new issue. Steps to replicate: 1) Open a folder with many image files. 2) Change to list view. 3) zoom to maximum size, it's faster this way but still happens at normal size. 4) Scroll up and down. Result, nautilus will use more memory. The fact that it leaks memory faster at a higher zoom level indicates that it isn't related to the length of strings, but rather has to do with images somehow. This doesn't happen in icon view. What does happen in icon view, if you zoom to maximum size, is that nautilus temporary uses more memory while it caches higher-resolution thumbnails it generates, possibly only if the existing thumbnails aren't large enough. But most or all of this memory is freed when you reload the folder or navigate away. This doesn't happen with the memory from this leak. Memory usage does go down slightly, like for me it just went from ~830 MiB or something to 780 when I went from list view to icon view, but when I did this after zooming in icon view, it went from ~230 to ~60 MiB. When I was testing this before, it seemed like the memory didn't leak until you had scrolled far enough; just scrolling a bit, like half a page on normal zoom, didn't seem to cause a leak even when repeated. But using a high zoom makes it easy enough to replicate that details like that shouldn't matter. In fact, simply increasing the zoom level could cause a memory leak. I just did that, without scrolling, and watched memory usage go from ~780, where I was before, up to 975 MiB. After returning to normal zoom and refreshing, memory went down to ~914. After repeating the process, over 1 GiB. At normal size, in list view, scrolling down to the bottom of 342 images and then back up to the top causes Nautilus to use about 20 MiB more memory, each time you do it. In icon view, doing this has no noticeable effect. However, changing to list view, and then changing back to icon view, with no other actions taken, does cause memory to increase by about 6 MiB each time I do it. New thumbnail creation is probably happening because there is high CPU use; it's possible it's not caching thumbnails in list view., or caching a limited amount or number and not freeing memory after it decides a thumbnail is no longer cached. At largest zoom, each image was adding 1.3 MiB of memory to Nautilus when I pressed down once; same thing if I pressed 'home' and 'end' repeatedly. I'm using Nautilus 3.10.1, with Ubuntu 14.10. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/952108 Title: [Precise] Nautilus: memory leak To manage notifications about this bug go to: https://bugs.launchpad.net/nautilus/+bug/952108/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1443809] Re: Failed thumbnail check not working properly
I may have misfiled this, but not quite sure which project is
responsible. I also note that when adding gnome-desktop to the list of
affected projects, it said gnome-desktop does not use Launchpad to
track bugs. Nobody will be notified about this issue.
Added a screenshot of an image not being thumbnailed.
The relevant function seems to be
gnome_desktop_thumbnail_factory_has_valid_failed_thumbnail ()
https://developer.gnome.org/gnome-desktop/stable/GnomeDesktopThumbnailFactory.html#gnome-desktop-thumbnail-factory-has-valid-failed-thumbnail
This is old code because I don't know how to reference the latest code:
http://sourcecodebrowser.com/gnome-desktop/2.32.0/gnome-desktop-thumbnail_8h.html#ab9946e6856418572e55147637a1493ab
It includes this:
pixbuf = gdk_pixbuf_new_from_file (path, NULL);
g_free (path);
if (pixbuf)
{
res = gnome_desktop_thumbnail_is_valid (pixbuf, uri, mtime);
g_object_unref (pixbuf);
}
g_checksum_free (checksum);
It mentions mtime, yet evidently that is not being checked if the
process described in this report can cause a new thumbnail to fail to be
generated.
As implied in the original report, if there is a valid thumbnail and
also a failed thumbnail for the same path to a file, if the valid
thumbnail doesn't match the mtime of the actual file, a new thumbnail
will be generated. So it seems to work unless no 'normal' thumbnail
(whether normal or large-sized) already exists.
** Attachment added: Screenshot from 2015-04-14 01:15:35.png
https://bugs.launchpad.net/gnome-desktop/+bug/1443809/+attachment/4374819/+files/Screenshot%20from%202015-04-14%2001%3A15%3A35.png
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/1443809
Title:
Failed thumbnail check not working properly
To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-desktop/+bug/1443809/+subscriptions
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1443849] [NEW] Copying a line with full-width character at end adds a space
Public bug reported: If a full-width character, such as a Chinese character, starts at the last column of a line, it is moved to the start of the next line. The last column is then displayed as being empty. However, if that line is selected using the mouse and copied using shift-ctrl-C, or simply using middle-click paste, a space is added to the line at that location. A common place where this can occur is in filenames. I assume this is a bug in gnome-terminal, and not bash, but I'm not entirely sure. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: gnome-terminal 3.6.2-0ubuntu1 ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3 Uname: Linux 3.16.0-30-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8.2 Architecture: amd64 CurrentDesktop: Unity Date: Tue Apr 14 02:36:30 2015 SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: gnome-terminal (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug utopic -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1443849 Title: Copying a line with full-width character at end adds a space To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1443849/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1443809] [NEW] Failed thumbnail check not working properly
Public bug reported: This is related to the gnome-thumbnailer code which is part of Nautilus. However, I don't know enough about programming to fix it myself. If a failed thumbnail exists for a file, or specifically a universal resource identifier, Nautilus will not try to create a valid thumbnail for it, unless a non-failed thumbnail also exists for that URI/path. Steps to replicate: 1) Create a new, blank document named image.jpg 2) make sure the failed thumbnail has been created, such as by restarting nautilus with 'nautilus --quit' 3) navigate back to that folder, rename or delete the blank file, and rename another image to image.jpg. Result: no thumbnail will be created for the image. When I was checking the thumbnail code for an unrelated issue (256x256 thumbnails take up too much space as PNG, sometimes larger than original file), I also saw enough to be able to investigate this issue a little. In the code for Nautilus, or gnome-thumbnailer, that I looked at, it appeared that the code was doing a check to see if the failed thumbnail was valid. That is, if the modification time of the file as recorded in the PNG Chunk data does not match, it probably shouldn't count as a match for the file. But either it is incorrectly matching, or something else is wrong. While testing for an unrelated issue that seemed like it might no longer exist, I found that as Firefox saves an item by creating a placeholder and then saving the actual file using a .part suffix (unless changed in options probably), it leads to this bug. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: nautilus 1:3.10.1-0ubuntu15.1 ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3 Uname: Linux 3.16.0-30-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8.2 Architecture: amd64 CurrentDesktop: Unity Date: Tue Apr 14 00:40:58 2015 GsettingsChanges: b'org.gnome.nautilus.list-view' b'default-visible-columns' b['name', 'size', 'date_modified', 'date_accessed', 'type'] b'org.gnome.nautilus.list-view' b'default-column-order' b['name', 'size', 'date_modified', 'date_accessed', 'type', 'group', 'where', 'mime_type', 'owner', 'permissions'] SourcePackage: nautilus UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: nautilus (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug utopic -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1443809 Title: Failed thumbnail check not working properly To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1443809/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1443809] Re: Failed thumbnail check not working properly
** Also affects: gnome-desktop Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1443809 Title: Failed thumbnail check not working properly To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-desktop/+bug/1443809/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1443852] [NEW] Display bug for editing lines with full-width characters
Public bug reported: I'm not entirely sure this isn't a bug with bash, instead of gnome- terminal. Full-width character, followed by at least one full word with a space after it. Example: あa a With trailing space. Typing before the full-width character causes the 'あ' to be pushed to next line, with a blank space on previous line though if selected and copied it will actually produce a space. The 'あ' occupies two columns on the new line, but characters after the first a are only moved one column to the right. The first a, or the first character after the 'あ' including a space, is pushed two columns to the right, covering the second character after the 'あ'. A similar bug occurs when deleting characters before the 'あ', except no trailing space is required. A character is duplicated but might be first letter of first word on second line, or last letter of next word. Duplicating one letter as soon as 'あ' goes to previous line is easy to replicate; duplicating other letters as further characters before 'あ' are deleted might only happen after resetting the line using up arrow then down arrow, but actually just because of forward bug because displayed characters change after pressing up then down. Second word on line only seems to be affected if no other words after it. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: gnome-terminal 3.6.2-0ubuntu1 ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3 Uname: Linux 3.16.0-30-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8.2 Architecture: amd64 CurrentDesktop: Unity Date: Tue Apr 14 02:37:03 2015 SourcePackage: gnome-terminal UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: gnome-terminal (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug utopic -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1443852 Title: Display bug for editing lines with full-width characters To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1443852/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1443852] Re: Display bug for editing lines with full-width characters
The trailing space doesn't show up as excess whitespace is removed on launchpad, however it was necessary to replicate the bug. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1443852 Title: Display bug for editing lines with full-width characters To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1443852/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1443879] [NEW] Find from typing selects hidden files
Public bug reported: I think this changed when I upgraded from Ubuntu 12.04 to 14.10. When searching by typing, which only searches in the current directory, hidden files are now selected. This would maybe be fine except that there's no feedback that a hidden file has been selected. Normally, if a file exists it's selected and nautilus will scroll to its location. If it's hidden, it seems like it doesn't scroll to its location. So if you want a file that does exist, but there's also a hidden file that begins the same way, there's no feedback that any file named what you want exists in that folder. As a practical example, gedit automatically saves the previous version of a file to name~ when one is saved, which is a hidden file. When sorted by modification date, that older file will come first, and automatically typing will not indicate that the desired, non-hidden file exists, although it can still be selected by scrolling after typing. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: nautilus 1:3.10.1-0ubuntu15.1 ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3 Uname: Linux 3.16.0-30-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8.2 Architecture: amd64 CurrentDesktop: Unity Date: Tue Apr 14 03:29:12 2015 GsettingsChanges: b'org.gnome.nautilus.list-view' b'default-visible-columns' b['name', 'size', 'date_modified', 'date_accessed', 'type'] b'org.gnome.nautilus.list-view' b'default-column-order' b['name', 'size', 'date_modified', 'date_accessed', 'type', 'group', 'where', 'mime_type', 'owner', 'permissions'] SourcePackage: nautilus UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: nautilus (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug utopic -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1443879 Title: Find from typing selects hidden files To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1443879/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 495880] Re: File Roller cannot handle archive that doesn't encode filenames in UTF-8
The undocumented -O/-I option~ So unzip can handle different encodings, at least when I tested it. But it doesn't handle them automatically. p7zip doesn't work because, as noted in Bug #269482, it only handles UTF-8 and ASCII (or maybe ISO-8859). When I uninstalled p7zip and p7zip-full and looked at archives, some had the pattern of mojibake that I'm used to, and some had a new type. None of them were correct. So it's possible there is some automatic correction and this is why Bug #580961 for unzip has been marked as fixed. Automatic detection can probably usually be correct, but it could also sometimes be wrong. Either file-roller or unzip could probably improve their automatic detection, and in case certainty is low communicate this to users so they know there might be a problem. Two other bugs, #592109 and #1199239, refer to non-ASCII filenames encoded in UTF-8, which is likely to be the output from Unix-like systems. So non-UTF-8 encodings are probably from computers running Windows (?). Some open-source programs that do automatic detection of encodings include Firefox and, I think, gedit. Also maybe a bit similar to magic numbers used to determine file types..? This might be how those programs already do this, but I think the way to detect the proper encoding is to interpret the filenames as a certain type, and then look for characters, or character combinations, that are unlikely to appear in a normal filename, or that can't even be output on the file system type. For example, the character '', U+0082 control BREAK PERMITTED HERE, often appears in some languages when common encodings are interpreted as iso8859(-number?). Either file-roller or unzip could test various combinations to see what looks valid. This is worse than an archive file saying what encoding it uses, but basically it seems like some regions (like Japan) don't feel like using UTF-8. The zip format, which is probably worse than other formats in handling filenames, is probably still used because it encodes the contents of files separately, which means it's faster but gives worse compression than other archive formats. Maybe there are other reasons it's faster too. Having a unique file suffix for a certain set of compression options or quality means that people don't have to worry about which options to choose, and can't argue about which ones other people should use for that suffix. There is probably also a sort of stigma attached to having a poor compression ratio for many types of files, compared to other formats. (For example, some non-zip archive formats can compress a windows bmp file so that it's smaller than a png of the same image, especially if the image has repeating portions.) So either people can agree on a 'low-quality' archive suffix to use in cases where actual compression isn't important, that's also operating- system independent, or we will continue to encounter zips from different languages that don't tell you how to decode the file names. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. https://bugs.launchpad.net/bugs/495880 Title: File Roller cannot handle archive that doesn't encode filenames in UTF-8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/495880/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1444210] [NEW] Previewed files are not deleted
Public bug reported: It seems like this could be related to Bug #137308, where a user complained that previewed files were being deleted. file-roller, also known as Archive Manager, doesn't delete files that are previewed without extracting them to a known location first. These previews are stored in ~/.cache/.fr-random string. I believe the /tmp directory is cleared each time the system is restarted, but maybe the preview files aren't stored there for security reasons. eog seems to not store references to a file maybe by design; sometimes when you change a file on disk, eog will reload the file, but it doesn't always do so. So maybe can't rely on other applications that have the file 'open' to actually have a reference to the index node or whatever, and users will expect the preview not to be deleted immediately. Currently, it seems like some, and maybe all preview files are retained indefinitely, unless manually deleted. If a file is previewed more than once, multiple copies are created. Over time this can add up to a considerable amount of disk space. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: file-roller 3.10.2.1-0ubuntu5 ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3 Uname: Linux 3.16.0-30-generic x86_64 NonfreeKernelModules: nvidia ApportVersion: 2.14.7-0ubuntu8.2 Architecture: amd64 CurrentDesktop: Unity Date: Tue Apr 14 17:05:57 2015 SourcePackage: file-roller UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: file-roller (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug utopic -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to file-roller in Ubuntu. https://bugs.launchpad.net/bugs/1444210 Title: Previewed files are not deleted To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/1444210/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 495880] Re: File Roller cannot handle archive that doesn't encode filenames in UTF-8
Along with the command-line version of unzip with the -O option, you can also use the convmv command to change filenames of previously extracted files. This works on an ext3 filesystem, but NTFS may give an error because filenames are invalid. ext3 says the encoding is invalid but still lets them be renamed to that. So for anyone who encounters this bug report and is concerned specifically with extracting filenames from shift-jis encoded archives, these are the commands you can use: (navigate to directory, and...) unzip -O shift-jis filename or convmv * -f utf8 -t iso8859-1 -r convmv * -f utf8 -t iso8859-1 --notest -r ; convmv -f shift-jis -t utf8 * --notest -r One of the other bug reports links to this, which lists solutions and problems: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483290 One consideration might be if files in the same archive use different encoding types. It seems reasonable that they appeared that way to the archive's creator, and thus they shouldn't be interpreted separately, but it could lead to the wrong conversion method being selected. The patch linked in that bug report describes the options -O and -I, which aren't documented in unzip's manual pages, so it's possible that patch is already applied. But it still didn't detect 'proper' encodings for me when I tested file-roller, using unzip, on several archives after uninstalling p7zip. The patch also talks the current locale charset. Making assumptions about the encoding used on files could be correct for many people, most of the time, but will be incorrect for other people, and so is at best only a partial solution. I don't know what the patch does after that though. Just for reference, these are other Debian bugs mentioned in that report: Bug#197427: unzip: chinese filenames unwrapped on unix wrongly Bug#197428: unzip: zipinfo (and unzip) can't deal with chinese filenames like miniunzip can Bug#339021: unzip: incorrectly converts cyrillic file names from Windows-created ZIPs ** Bug watch added: Debian Bug tracker #483290 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483290 -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. https://bugs.launchpad.net/bugs/495880 Title: File Roller cannot handle archive that doesn't encode filenames in UTF-8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/495880/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1436595] Re: Images too bright
While it isn't completely clear what the correct way to display images is, if eog is in fact currently displaying them correctly it would help to have an option to display them 'literally'. It doesn't seem like there is any way to do this. Exact comparisons are helpful to diagnose problems in other programs, or even for things like just understanding whether the rgb to yuv conversion is linear or follows some other equation, for someone who has encountered that situation without much knowledge about it. For example, suppose you want to compare whether Youtube's video player is displaying a video the same as your local player does. You could press F every time you switch to Youtube to cause it to go fullscreen, then switch to the other player while staring at the same spot. Or you could screenshot Youtube's display and compare to the screenshot. But if eog is the default image viewer and it displays it differently from how it originally appeared, you might make the wrong diagnosis and waste time. ** Attachment added: geq-255.png https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+attachment/4366261/+files/geq-255.png -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1436595 Title: Images too bright To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1436595] Re: Images too bright
** Attachment added: geq-200.png.jpg https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+attachment/4366254/+files/geq-200.png.jpg -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1436595 Title: Images too bright To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1436595] Re: Images too bright
** Attachment added: geq.jpg https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+attachment/4366250/+files/geq.jpg -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1436595 Title: Images too bright To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1436595] Re: Images too bright
** Attachment added: geq-128.png https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+attachment/4366253/+files/geq-128.png -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1436595 Title: Images too bright To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1436595] Re: Images too bright
** Attachment added: geq-200-convert.png https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+attachment/4366256/+files/geq-200-convert.png -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1436595 Title: Images too bright To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1436595] Re: Images too bright
** Attachment added: geq-200.png https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+attachment/4366251/+files/geq-200.png -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1436595 Title: Images too bright To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1436595] Re: Images too bright
** Attachment added: eog-firefox diff-threshold.png https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+attachment/4366257/+files/eog-firefox%20diff-threshold.png -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1436595 Title: Images too bright To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1436595] Re: Images too bright
Some examples of how eog displays colours compared to imagemagick's display. These files were generated as follows, using ffmpeg: ffmpeg -filter_complex color=black:256x256,geq=X:240:128 -hide_banner -frames 1 geq.png ffmpeg -filter_complex color=black:256x256,geq=X:240:128 -hide_banner -frames 1 geq.jpg ffmpeg -filter_complex color=black:256x256,geq=X:200:128 -hide_banner -frames 1 geq-200.png ffmpeg -filter_complex color=black:256x256,geq=X:200:128 -hide_banner -frames 1 geq-200.jpg ffmpeg -filter_complex color=black:256x256,geq=X:128:128 -hide_banner -frames 1 geq-128.png convert geq-200.png -quality 100 geq-200.png.jpg convert geq-200.png geq-200-convert.png So these are images with a y (or is it y'?) value that ranges from 0 to 255, while the u value is at the mpeg range maximum for u of 240. The jpg and png images are different because the jpg images clip the y range when expanding it from 16~235 to 0~255, while the png images when converted to rgb allow the y values outside the normal range to affect the output colour. So the jpg output from convert is visually identical to the png it comes from, but on the edges u and v both have a gradient to produce those colours. Then I took a screenshot of how eog displays geq-200.png, as well as a screenshot of how imagemagick (display) displays png, and combined them in GIMP. The jpgs are displayed roughly the same in both programs, other than the differences due to clipping when expanding to jpeg range. Firefox displays the images output from ffmpeg the same way as imagemagick, but displays the png output from imagemagick's convert almost the same as eog does. This similarity is much higher than for the images I tested for the original bug report. I took a screenshot of Firefox's display of geq-200-convert.png, cropped it and placed it on top of a screenshot of eog's output of geq-200.png (which is displayed exactly the same as geq-200-convert.png by eog), used the difference filter and flattened the image. (flattening an image might be used incorrectly here, but it's what the option is called.) Then I used the threshold operation, from 1 to 255, so the vertical lines are where they differed. All but one of the lines disappear at threshold 2, the last disappears at threshold 5. ** Attachment added: geq.png https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+attachment/4366249/+files/geq.png -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1436595 Title: Images too bright To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1436595] Re: Images too bright
** Attachment added: geq-200.jpg https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+attachment/4366252/+files/geq-200.jpg -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1436595 Title: Images too bright To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1436595] Re: Images too bright
** Attachment added: comparison.png https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+attachment/4366255/+files/comparison.png -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1436595 Title: Images too bright To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1436595/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 1436595] [NEW] Images too bright
Public bug reported: Most images have their values shifted upwards when displayed in eog, and I don't think it is intentional. Reporting this as a bug is complicated because I am not sure if some programs, such as eog, change their display of an image based on screen settings for colorspace or gamma. I am not an expert on graphics, but something does seem to be wrong. So at least for my computer, eog seems to stretch out the range just above a 0 value. A very dark area will have a clear contrast between the totally black pixels, with a value of zero, and the ones just above it. In one image I tested, eog did not display any pixels with a value in the range of 1 to 5, as in the histogram of a screenshot of eog's display of the image. In comparison, a screenshot of Firefox's display of the same image had numerous pixels in the 1~5 range. The GIMP image editor displayed this image the same as Firefox, with the histogram showing that the pixels were being displayed without any adjustment. Basically, if a lot of different programs display things differently and inconsistently, some of them have to be wrong, and it seems likely that eog is. Due to inconsistencies, I'm not actually sure what is the correct, or the best way to display images, which might be different from the correct way. Programs used to test, convert, and display images: imagemagick ffmpeg (for conversion) and avplay (for display, since ffplay isn't provided on my distribution) eog Firefox vlc GIMP I thought Firefox was displaying non-stripped pngs the same as eog does, but it's actually slightly different. While gray areas are about the same as eog, red areas are slightly darker in Firefox. A description of how various programs display images: vlc seems to be the same as avplay, and both are different from either Firefox or eog. Dark red is a bit more like brown or orange, while contrast for luminosity or luminance (?) seems to be higher; I am just noting that it is different. This is for a png image. I thought eog was displaying all images the same way, until I encountered a png that worked differently. I thought eog was displaying this png without any adjustments, as it's slightly darker than how eog displays other pngs, but it's actually slightly darker with more intense colours than how other programs display the same image. But for all other images, eog seems to make them slightly brighter. Firefox displays jpgs without any adjustment, but most pngs are slightly brighter. As described, this is slightly different than how eog makes images brighter. If an image is converted with -strip action in imagemagick, Firefox shows the png without adjustments. A png output from ffmpeg is also displayed without adjustments. It seems to be related to the 'png:sRGB : intent=value' property but that would be a Firefox bug. It's relevant because it seems to adjust the display of images in a way that's similar to eog, though still different. If a stripped png is converted again without applying the -strip action again, Firefox will display it as adjusted; that is, brighter. This is also part of the evidence that the adjustment in Firefox, and therefore in eog, is a bug. GIMP displays images without an adjustment, so darker than eog for most images. The 'display' utility from imagemagick displays images the same as GIMP, without any apparent adjustments. So GIMP, display from imagemagick, and Firefox all display jpgs as slightly darker than eog, without mostly skipping over the range of values just above 0. GIMP and 'display' show most pngs as darker than eog, while Firefox displays some pngs as darker than eog while others are displayed similar but with slightly darker reds it seems. I think all the images I've looked at had 'colorspace: sRGB' in their properties when I looked at them with 'identify' from imagemagick or exiftool., so if that's somehow related it doesn't seem like programs should display images differently. They probably all had 'gamma: 0.45' in 'identify' (though this shows up as gamma: 2.2 in exiftool I think), so I don't think that should affect image display either. For the unusual png that eog displays differently, none of the ways I used to convert it caused the output to be displayed in eog the same as the original. These methods included 'convert' from imagemagick with and without the -strip action; convert with jpg output; ffmpeg with png output; and GIMP exporting as png with background color and gamma tested (so four GIMP outputs total). The reason for testing background color was that 'png:bKGD' is part of the output from 'identify' when the -strip action isn't used with 'convert', and non-stripped pngs are treated differently in Firefox so they could potentially also be treated differently in eog, but as it turned out they weren't treated differently in eog. In 'identify's output, the original png does have very slightly different numbers under Chromaticity, with five of eight numbers different by
