[Desktop-packages] [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 Desktop Packages, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1436595 Title: Images too bright Status in eog package in Ubuntu: Invalid Bug description: 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=' 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
[Desktop-packages] [Bug 1759300] Re: Gnome Shell: Touchpad right click (bottom right) area does not work
Would it be possible to make 'area' mode the default if the touchpad doesn't support multi-finger input? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gsettings-desktop-schemas in Ubuntu. https://bugs.launchpad.net/bugs/1759300 Title: Gnome Shell: Touchpad right click (bottom right) area does not work Status in gsettings-desktop-schemas package in Ubuntu: Invalid Bug description: The right (second) touchpad click does not work. It ceased to work about three months ago. ubuntu 18,04 aser ex2519 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gsettings-desktop-schemas/+bug/1759300/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1766480] [NEW] Touchpad scroll and middle/right click not working as expected
Public bug reported: This could probably fixed through configuration, but it should work automatically. Testing Ubuntu 18.04 beta, the touchpad has no special regions for scrolling or anything. By default in Xorg-based Ubuntu, top right corner of touchpad is middle- click (mouse button 2), bottom right is right-click (mouse button 3), and right side is vertical scrolling. For a while the bottom edge defaulted to horizontal scrolling, but that changed in 17.10 or something. I'm aware that new touchpad interaction methods have developed, like dragging with two fingers anywhere on the touchpad to scroll or something. But people may not know this, or their touchpad might not support multitouch. (The Xorg-based settings for touchpad remain when switching back to Xorg like with the Metacity Flashback login option.) ** Affects: wayland (Ubuntu) Importance: Undecided Status: New ** Description changed: This could probably fixed through configuration, but it should work automatically. Testing Ubuntu 18.04 beta, the touchpad has no special regions for scrolling or anything. By default in Xorg-based Ubuntu, top right corner of touchpad is middle- click (mouse button 2), bottom right is right-click (mouse button 3), and right side is vertical scrolling. For a while the bottom edge defaulted to horizontal scrolling, but that changed in 17.10 or something. I'm aware that new touchpad interaction methods have developed, like dragging with two fingers anywhere on the touchpad to scroll or something. But people may not know this, or their touchpad might not support multitouch. + + (The Xorg-based settings for touchpad remain when switching back to Xorg + like with the Metacity Flashback login option.) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to wayland in Ubuntu. https://bugs.launchpad.net/bugs/1766480 Title: Touchpad scroll and middle/right click not working as expected Status in wayland package in Ubuntu: New Bug description: This could probably fixed through configuration, but it should work automatically. Testing Ubuntu 18.04 beta, the touchpad has no special regions for scrolling or anything. By default in Xorg-based Ubuntu, top right corner of touchpad is middle-click (mouse button 2), bottom right is right-click (mouse button 3), and right side is vertical scrolling. For a while the bottom edge defaulted to horizontal scrolling, but that changed in 17.10 or something. I'm aware that new touchpad interaction methods have developed, like dragging with two fingers anywhere on the touchpad to scroll or something. But people may not know this, or their touchpad might not support multitouch. (The Xorg-based settings for touchpad remain when switching back to Xorg like with the Metacity Flashback login option.) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wayland/+bug/1766480/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1766479] [NEW] Resizing a window's left border to the right can cause it to scoot right
Public bug reported: Tested with 18.04 beta. Created a small window, ffmpeg or ffplay showing a 2x2 pixel video. When trying to move it, instead selected left border. Dragging right caused the window to scoot away faster than the pointer was moving, vanishing in less than a second. ** Affects: wayland (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to wayland in Ubuntu. https://bugs.launchpad.net/bugs/1766479 Title: Resizing a window's left border to the right can cause it to scoot right Status in wayland package in Ubuntu: New Bug description: Tested with 18.04 beta. Created a small window, ffmpeg or ffplay showing a 2x2 pixel video. When trying to move it, instead selected left border. Dragging right caused the window to scoot away faster than the pointer was moving, vanishing in less than a second. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wayland/+bug/1766479/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [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 Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1444839 Title: jpeg-2000 files cause Nautilus to crash Status in nautilus package in Ubuntu: New Bug description: 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
[Desktop-packages] [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 Desktop Packages, which is subscribed to gedit in Ubuntu. https://bugs.launchpad.net/bugs/1444881 Title: Autocomplete in 'open file' works wrong with folders Status in gedit package in Ubuntu: New Bug description: 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
[Desktop-packages] [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 Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1444790 Title: crash if thumbnailer fails to produce output Status in nautilus package in Ubuntu: New Bug description: 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',
[Desktop-packages] [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 Desktop Packages, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1318327 Title: Can't open .webp files Status in Eye of GNOME: New Status in eog package in Ubuntu: Triaged Bug description: Please, add webp support. To manage notifications about this bug go to: https://bugs.launchpad.net/eog/+bug/1318327/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [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 Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1444790 Title: crash if thumbnailer fails to produce output Status in nautilus package in Ubuntu: New Bug description: 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
[Desktop-packages] [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 Desktop Packages, 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 Status in eog package in Ubuntu: New Bug description: 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) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/eog/+bug/1444807/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1407644] Re: eog doesn't show WebP images
The bug for eog seems to be Bug #1318327. Should one of these bugs be marked as a duplicate and the other project added to the list of affected projects? -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libwebp in Ubuntu. https://bugs.launchpad.net/bugs/1407644 Title: eog doesn't show WebP images Status in WebP Image Library: Unknown Status in libwebp package in Ubuntu: Confirmed Bug description: eog doesn't show WebP images i get this error message while trying to view WebP images Could not load image '2_webp_a.webp'. Unrecognized image file format To manage notifications about this bug go to: https://bugs.launchpad.net/libwebp/+bug/1407644/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [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 Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1444790 Title: crash if thumbnailer fails to produce output Status in nautilus package in Ubuntu: New Bug description: 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) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1444790/+subscriptions --
[Desktop-packages] [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 Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1443794 Title: Folders with large names cause icons to disappear Status in nautilus package in Ubuntu: New Bug description: 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) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1443794/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [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 Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/797485 Title: Status Bar Covers File Name at Bottom Status in Nautilus: Confirmed Status in nautilus package in Ubuntu: Triaged Bug description: Binary package hint: nautilus In Nautilus when you have an even number of files on the bottom row it becomes difficult to rename the last file as the status bar covers the text area. I realize this is likely a rare occurrence, and can be gotten around by adjusting the width of the window, but it is a minor bug. Possible solutions: Move status bar to the left side when working with files in that corner. Do not show status bar while renaming. Best IMHO: Give the file area a bottom margin of the height of the status bar. Ubuntu 11.04, Gnome-Shell (Although it should just be nautilus in general.) nautilus: 1:3.0.2-0ubuntu2~natty1 To manage notifications about this bug go to: https://bugs.launchpad.net/nautilus/+bug/797485/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [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 Desktop
Packages, which is subscribed to nautilus in Ubuntu.
https://bugs.launchpad.net/bugs/1443809
Title:
Failed thumbnail check not working properly
Status in GNOME Desktop Common Files:
New
Status in nautilus package in Ubuntu:
New
Bug description:
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)
To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-desktop/+bug/1443809/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [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 Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/952108 Title: [Precise] Nautilus: memory leak Status in Nautilus: New Status in nautilus package in Ubuntu: Triaged Bug description: Hello, It's just to note that Nautilus has memory leaks with the latest version: with an uptime of 10 hours, Nautilus uses 420Mo. It's maybe interesting to know that: * I'm using a slideshow and not one single image as background. * I opened Nautilus in directories where big files were being downloaded (and Nautilus regularly refreshed their preview) * I made a few actions (like opening directories with a lot of files, moving files, creating directories, extracting tarball, etc.) * I'm using a few plugins like nautilus-dropbox, nautilus-image-converter, etc. * I've bookmarks with special characters like 'Vidéos' and 'Téléchargements'. I hope it will help you to fix this bug ;) ProblemType: Bug DistroRelease: Ubuntu 12.04 Package: nautilus 1:3.3.91-0ubuntu4 ProcVersionSignature: Ubuntu 3.2.0-18.29-generic 3.2.9 Uname: Linux 3.2.0-18-generic x86_64 ApportVersion: 1.94.1-0ubuntu2 Architecture: amd64 Date: Sun Mar 11 10:35:32 2012 GsettingsChanges: org.gnome.nautilus.window-state geometry '800x552+483+87' org.gnome.nautilus.window-state start-with-status-bar true InstallationMedia: Ubuntu 11.10 Oneiric Ocelot - Alpha amd64 (20110803.1) SourcePackage: nautilus UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/nautilus/+bug/952108/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [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 Desktop Packages, 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 Status in gnome-terminal package in Ubuntu: New Bug description: 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) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1443849/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [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 Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1443809 Title: Failed thumbnail check not working properly Status in nautilus package in Ubuntu: New Bug description: 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)
[Desktop-packages] [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 Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1443809 Title: Failed thumbnail check not working properly Status in GNOME Desktop Common Files: New Status in nautilus package in Ubuntu: New Bug description: 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) To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-desktop/+bug/1443809/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1443846] [NEW] 'Advance by one frame' no longer works at beginning of video
Public bug reported: This might be a totem issue, not a gstreamer one; the ubuntu-bug program asked what was happening and I selected video not playing correctly. After I upgraded from Ubuntu 12.04 to Ubuntu 14.10, with whatever gstreamer or totem changes were involved with that, 'advance by one frame' (the '.' key) didn't work as well. It will almost always not work at the very start of a video. Sometimes instead of one frame, it will advance around half a second. Other times, maybe related to seeking in the video after using it without first starting normal playback again, it will not work properly or will send you back to where you were in the video before you seeked to a different time. Occasionally, it will work at the start of a video, but very rarely if ever can you do this by pausing, seeking to the start of a video, and then pressing '.' . You used to be able to do this though. Right now, trying to seek near the start of a video, if it doesn't just send you back to wherever you were, usually skips several frames, like 6 frames or so, then starts normal behaviour of advancing 1 frame at a time. On a related note, the 'one frame back' key (the ',' key) is either broken by design or partly by accident. Pressing it usually either freezes the video, so you have to seek to a different location in order for the video to start playing normally, or it causes the video to seek to a totally separate time, and subsequently pressing '.' causes a frame to be shown which is at a completely separate time than what ',' was returning. When ',' works instead of freezing the video (possibly only before I upgraded to 14.10 several months ago), it seemed to usually seek to near the start of the video before returning frames, though the '.' key would sort of let you reset playback to where it was before. As a quick test, I just tried it on a webm/VP9 video, though I think the same thing happens with other videos: 1) Played for a few seconds, then pressed and held '.' . Result, video advances at the rate of keyboard sending '.' events. 2) Pressed and held ','. Result, video went back maybe a second, but then actually played backwards. 3) Pressed and held '.' again. Result, video played backwards instead of advancing forwards like the key should do. 4) With video paused, seeked forward by 15 sec, and pressed '.' again. Result, progress bar moved back to video start where it was before seeking, and video didn't advance as probably still trying to go backwards. 5) With video paused, seek forward by clicking. Unpause video. Result, it goes back to start and doesn't play. 6) With video on play but not playing, seeked forward again. Result, starts playing from beginning. 7) With video on play and playing, seeked to a different location. Result, video still on play but not playing. 8) Paused and then unpaused, video starts playing again. 9) Pressed and held '.' again, video slowly moves forward. 10) Pressed ',' , totem crashes. (don't remember this happening before) ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: libgstreamer1.0-0 1.4.3-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 02:12:17 2015 SourcePackage: gstreamer1.0 UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: gstreamer1.0 (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug utopic -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gstreamer1.0 in Ubuntu. https://bugs.launchpad.net/bugs/1443846 Title: 'Advance by one frame' no longer works at beginning of video Status in gstreamer1.0 package in Ubuntu: New Bug description: This might be a totem issue, not a gstreamer one; the ubuntu-bug program asked what was happening and I selected video not playing correctly. After I upgraded from Ubuntu 12.04 to Ubuntu 14.10, with whatever gstreamer or totem changes were involved with that, 'advance by one frame' (the '.' key) didn't work as well. It will almost always not work at the very start of a video. Sometimes instead of one frame, it will advance around half a second. Other times, maybe related to seeking in the video after using it without first starting normal playback again, it will not work properly or will send you back to where you were in the video before you seeked to a different time. Occasionally, it will work at the start of a video, but very rarely if ever can you do this by pausing, seeking to the start of a video, and then pressing '.' . You used to be able to do this though. Right now, trying to seek near the start of a video, if it doesn't just send you back to wherever you were, usually skips several frames, like 6 frames or so, then starts normal behaviour of advancing 1 frame at a time. On a
[Desktop-packages] [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 Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1443852 Title: Display bug for editing lines with full-width characters Status in gnome-terminal package in Ubuntu: New Bug description: 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) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1443852/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1443886] Re: Scrollbar disappears in windows like gnome-terminal
gnome-terminal seems to have an additional bug though, maybe related to tabs, that makes the scroll bar not appear even when doing the steps described in this report. It might be as simple as after switching tabs, the scrollbar doesn't appear until you create a new line at the bottom of the terminal. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to compiz in Ubuntu. https://bugs.launchpad.net/bugs/1443886 Title: Scrollbar disappears in windows like gnome-terminal Status in compiz package in Ubuntu: New Bug description: Not sure if this is a Compiz bug, but it's related to windows management. The type of scroll bar used in gnome-terminal was also the same as that in Firefox before I upgraded my system to Ubuntu 14.10 at the same time I upgraded Firefox to version 34 or so (so either Firefox, or some other program changed how scrollbars look). Switching to windows that use 'thin scroll bar', only ~3 pixels wide with no arrows If done quickly, it works fine as long as the mouse cursor is pointing at the window being focused to. If done slowly, by pressing alt-tab and holding alt, the scroll bar will disappear or become faded. Faded scrollbar is when alt is held for a very short period of time, so the application switcher menu only shows up for ~0.1 sec. Using static application switcher in compiz. Window's shadow border also sometimes longer to appear if alt is held, but it doesn't seem consistent or related to scrollbar. The 'invisible' part is an overlay that's the same colour as the background. If scrolling up or down, when the line representing the current location moves past the 'invisible' part, it's erased, so that if the line representing the visible portion is returned to that area, the 'invisible' part is smaller. Nautilus, gedit, and gnome-terminal all seem to be affected by this bug. The line isn't totally invisible, but being able to see it could depend on having an LCD screen that provides high contrast near the white range at that viewing angle. All three of these applications are demonstrating the bug for me right now, but I'm not sure if they always do. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: compiz 1:0.9.12+14.10.20140918-0ubuntu1 ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3 Uname: Linux 3.16.0-30-generic x86_64 NonfreeKernelModules: nvidia .proc.driver.nvidia.gpus.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/0' .proc.driver.nvidia.registry: Binary: .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 331.113 Mon Dec 1 21:08:13 PST 2014 GCC version: gcc version 4.9.1 (Ubuntu 4.9.1-16ubuntu6) .tmp.unity.support.test.0: ApportVersion: 2.14.7-0ubuntu8.2 Architecture: amd64 CompizPlugins: [core,composite,opengl,compiztoolbox,decor,imgpng,regex,gnomecompat,place,move,vpswitch,mousepoll,obs,wall,animation,shift,snap,resize,expo,session,ezoom,workarounds,staticswitcher,fade] CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true CurrentDesktop: Unity Date: Tue Apr 14 03:45:07 2015 DistUpgraded: Fresh install DistroCodename: utopic DistroVariant: ubuntu DkmsStatus: bbswitch, 0.7, 3.16.0-30-generic, x86_64: installed nvidia-331, 331.113, 3.16.0-30-generic, x86_64: installed nvidia-331-uvm, 331.113, 3.16.0-30-generic, x86_64: installed GraphicsCard: NVIDIA Corporation G96M [GeForce 9650M GT] [10de:064c] (rev a1) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device [1043:1912] MachineType: ASUSTeK Computer Inc. N50Vn PackageArchitecture: all ProcKernelCmdLine: root=UUID=b09dc720-93ec-4fdf-a42f-7ea19a9af555 ro quiet splash SourcePackage: compiz UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/05/2009 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 211 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: N50Vn dmi.board.vendor: ASUSTeK Computer Inc. dmi.board.version: 1.0 dmi.chassis.asset.tag: ATN12345678901234567 dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK Computer Inc. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr211:bd03/05/2009:svnASUSTeKComputerInc.:pnN50Vn:pvr1.0:rvnASUSTeKComputerInc.:rnN50Vn:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0: dmi.product.name: N50Vn dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK Computer Inc. version.compiz: compiz 1:0.9.12+14.10.20140918-0ubuntu1 version.ia32-libs: ia32-libs N/A version.libdrm2: libdrm2 2.4.56-1 version.libgl1-mesa-dri: libgl1-mesa-dri 10.3.2-0ubuntu0.1 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 10.3.2-0ubuntu0.1 version.nvidia-graphics-drivers: nvidia-graphics-drivers N/A
[Desktop-packages] [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 Desktop Packages, which is subscribed to gnome-terminal in Ubuntu. https://bugs.launchpad.net/bugs/1443852 Title: Display bug for editing lines with full-width characters Status in gnome-terminal package in Ubuntu: New Bug description: 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) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1443852/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1443886] [NEW] Scrollbar disappears in windows like gnome-terminal
Public bug reported: Not sure if this is a Compiz bug, but it's related to windows management. The type of scroll bar used in gnome-terminal was also the same as that in Firefox before I upgraded my system to Ubuntu 14.10 at the same time I upgraded Firefox to version 34 or so (so either Firefox, or some other program changed how scrollbars look). Switching to windows that use 'thin scroll bar', only ~3 pixels wide with no arrows If done quickly, it works fine as long as the mouse cursor is pointing at the window being focused to. If done slowly, by pressing alt-tab and holding alt, the scroll bar will disappear or become faded. Faded scrollbar is when alt is held for a very short period of time, so the application switcher menu only shows up for ~0.1 sec. Using static application switcher in compiz. Window's shadow border also sometimes longer to appear if alt is held, but it doesn't seem consistent or related to scrollbar. The 'invisible' part is an overlay that's the same colour as the background. If scrolling up or down, when the line representing the current location moves past the 'invisible' part, it's erased, so that if the line representing the visible portion is returned to that area, the 'invisible' part is smaller. Nautilus, gedit, and gnome-terminal all seem to be affected by this bug. The line isn't totally invisible, but being able to see it could depend on having an LCD screen that provides high contrast near the white range at that viewing angle. All three of these applications are demonstrating the bug for me right now, but I'm not sure if they always do. ProblemType: Bug DistroRelease: Ubuntu 14.10 Package: compiz 1:0.9.12+14.10.20140918-0ubuntu1 ProcVersionSignature: Ubuntu 3.16.0-30.40-generic 3.16.7-ckt3 Uname: Linux 3.16.0-30-generic x86_64 NonfreeKernelModules: nvidia .proc.driver.nvidia.gpus.0: Error: [Errno 21] Is a directory: '/proc/driver/nvidia/gpus/0' .proc.driver.nvidia.registry: Binary: .proc.driver.nvidia.version: NVRM version: NVIDIA UNIX x86_64 Kernel Module 331.113 Mon Dec 1 21:08:13 PST 2014 GCC version: gcc version 4.9.1 (Ubuntu 4.9.1-16ubuntu6) .tmp.unity.support.test.0: ApportVersion: 2.14.7-0ubuntu8.2 Architecture: amd64 CompizPlugins: [core,composite,opengl,compiztoolbox,decor,imgpng,regex,gnomecompat,place,move,vpswitch,mousepoll,obs,wall,animation,shift,snap,resize,expo,session,ezoom,workarounds,staticswitcher,fade] CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true CurrentDesktop: Unity Date: Tue Apr 14 03:45:07 2015 DistUpgraded: Fresh install DistroCodename: utopic DistroVariant: ubuntu DkmsStatus: bbswitch, 0.7, 3.16.0-30-generic, x86_64: installed nvidia-331, 331.113, 3.16.0-30-generic, x86_64: installed nvidia-331-uvm, 331.113, 3.16.0-30-generic, x86_64: installed GraphicsCard: NVIDIA Corporation G96M [GeForce 9650M GT] [10de:064c] (rev a1) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device [1043:1912] MachineType: ASUSTeK Computer Inc. N50Vn PackageArchitecture: all ProcKernelCmdLine: root=UUID=b09dc720-93ec-4fdf-a42f-7ea19a9af555 ro quiet splash SourcePackage: compiz UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 03/05/2009 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 211 dmi.board.asset.tag: ATN12345678901234567 dmi.board.name: N50Vn dmi.board.vendor: ASUSTeK Computer Inc. dmi.board.version: 1.0 dmi.chassis.asset.tag: ATN12345678901234567 dmi.chassis.type: 10 dmi.chassis.vendor: ASUSTeK Computer Inc. dmi.chassis.version: 1.0 dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr211:bd03/05/2009:svnASUSTeKComputerInc.:pnN50Vn:pvr1.0:rvnASUSTeKComputerInc.:rnN50Vn:rvr1.0:cvnASUSTeKComputerInc.:ct10:cvr1.0: dmi.product.name: N50Vn dmi.product.version: 1.0 dmi.sys.vendor: ASUSTeK Computer Inc. version.compiz: compiz 1:0.9.12+14.10.20140918-0ubuntu1 version.ia32-libs: ia32-libs N/A version.libdrm2: libdrm2 2.4.56-1 version.libgl1-mesa-dri: libgl1-mesa-dri 10.3.2-0ubuntu0.1 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 10.3.2-0ubuntu0.1 version.nvidia-graphics-drivers: nvidia-graphics-drivers N/A version.xserver-xorg-core: xserver-xorg-core 2:1.16.0-1ubuntu1.3 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.9.0-1ubuntu2 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.4.0-2ubuntu2 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.914-1~exp1ubuntu4.2 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.11-1ubuntu2 xserver.bootTime: Mon Apr 13 00:44:08 2015 xserver.configfile: /etc/X11/xorg.conf xserver.errors: Error loading keymap /var/lib/xkb/server-09D1F3CDBE4F6C8C6E82A68933E164F92A33A272.xkm xserver.logfile: /var/log/Xorg.0.log xserver.outputs: xserver.version: 2:1.16.0-1ubuntu1.3 ** Affects: compiz (Ubuntu) Importance: Undecided Status: New ** Tags: amd64
[Desktop-packages] [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 Desktop Packages, which is subscribed to nautilus in Ubuntu. https://bugs.launchpad.net/bugs/1443879 Title: Find from typing selects hidden files Status in nautilus package in Ubuntu: New Bug description: 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) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1443879/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [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 Desktop Packages, which is subscribed to file-roller in Ubuntu. https://bugs.launchpad.net/bugs/495880 Title: File Roller cannot handle archive that doesn't encode filenames in UTF-8 Status in file-roller package in Ubuntu: Confirmed Bug description: Binary package hint: file-roller I have received a zip containing a file with a german Umlaut in the filename. I cannot extract the file because I get the following error message: caution: filename not matched: Liste Verwaltung und Verk\?ndigung Dezember 2009.xls I have no possibility to change the filename and eliminate the Umlaut in the filename... ProblemType: Bug Architecture: i386 CheckboxSubmission: e27141b8feed9a0134eefdd87f008818 CheckboxSystem: 558fbfb2a1258711a37bb7e23c5d4e6e Date: Sat Dec 12 11:48:49 2009 DistroRelease: Ubuntu 9.10 ExecutablePath: /usr/bin/file-roller NonfreeKernelModules: nvidia Package: file-roller 2.28.1-0ubuntu1 ProcEnviron: LANGUAGE=de_DE.UTF-8 PATH=(custom, no user) LANG=de_DE.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.31-16.53-386 SourcePackage: file-roller Uname: Linux 2.6.31-16-386 i686 XsessionErrors: (gnome-settings-daemon:3121): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed (gnome-settings-daemon:3121): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed (polkit-gnome-authentication-agent-1:3161): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed (nautilus:3155): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/495880/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help
[Desktop-packages] [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 Desktop Packages, which is subscribed to file-roller in Ubuntu. https://bugs.launchpad.net/bugs/1444210 Title: Previewed files are not deleted Status in file-roller package in Ubuntu: New Bug description: 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) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/1444210/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [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 Desktop Packages, which is subscribed to file-roller in Ubuntu. https://bugs.launchpad.net/bugs/495880 Title: File Roller cannot handle archive that doesn't encode filenames in UTF-8 Status in file-roller package in Ubuntu: Confirmed Bug description: Binary package hint: file-roller I have received a zip containing a file with a german Umlaut in the filename. I cannot extract the file because I get the following error message: caution: filename not matched: Liste Verwaltung und Verk\?ndigung Dezember 2009.xls I have no possibility to change the filename and eliminate the Umlaut in the filename... ProblemType: Bug Architecture: i386 CheckboxSubmission: e27141b8feed9a0134eefdd87f008818 CheckboxSystem: 558fbfb2a1258711a37bb7e23c5d4e6e Date: Sat Dec 12 11:48:49 2009 DistroRelease: Ubuntu 9.10 ExecutablePath: /usr/bin/file-roller NonfreeKernelModules: nvidia Package: file-roller 2.28.1-0ubuntu1 ProcEnviron: LANGUAGE=de_DE.UTF-8 PATH=(custom, no user) LANG=de_DE.UTF-8 SHELL=/bin/bash ProcVersionSignature: Ubuntu 2.6.31-16.53-386 SourcePackage: file-roller Uname: Linux 2.6.31-16-386 i686 XsessionErrors: (gnome-settings-daemon:3121): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed (gnome-settings-daemon:3121): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed (polkit-gnome-authentication-agent-1:3161): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed (nautilus:3155): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/495880/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [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 Desktop Packages, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1436595 Title: Images too bright Status in eog package in Ubuntu: New Bug description: 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
[Desktop-packages] [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 Desktop Packages, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1436595 Title: Images too bright Status in eog package in Ubuntu: New Bug description: 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
[Desktop-packages] [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 Desktop Packages, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1436595 Title: Images too bright Status in eog package in Ubuntu: New Bug description: 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
[Desktop-packages] [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 Desktop Packages, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1436595 Title: Images too bright Status in eog package in Ubuntu: New Bug description: 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
[Desktop-packages] [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 Desktop Packages, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1436595 Title: Images too bright Status in eog package in Ubuntu: New Bug description: 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
[Desktop-packages] [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 Desktop Packages, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1436595 Title: Images too bright Status in eog package in Ubuntu: New Bug description: 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
[Desktop-packages] [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 Desktop Packages, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1436595 Title: Images too bright Status in eog package in Ubuntu: New Bug description: 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
[Desktop-packages] [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 Desktop Packages, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1436595 Title: Images too bright Status in eog package in Ubuntu: New Bug description: 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
[Desktop-packages] [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 Desktop Packages, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1436595 Title: Images too bright Status in eog package in Ubuntu: New Bug description: 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
[Desktop-packages] [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 Desktop Packages, which is subscribed to eog in Ubuntu. https://bugs.launchpad.net/bugs/1436595 Title: Images too bright Status in eog package in Ubuntu: New Bug description: 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
[Desktop-packages] [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
