After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 512905 - Thumbnails for small pictures are blurry and have frames
Thumbnails for small pictures are blurry and have frames
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: [obsolete] GIO
2.23.x
Other Linux
: Normal normal
: 2.24.x
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 517953 529887 537561 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-01-29 21:17 UTC by Baptiste Mille-Mathias
Modified: 2008-06-30 13:28 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22


Attachments
a screenshot (182.95 KB, image/png)
2008-01-29 21:40 UTC, Baptiste Mille-Mathias
Details
A screenshot in normal icon view (219.25 KB, image/png)
2008-03-18 00:44 UTC, Alexander “weej” Jones
Details
Blurry icons with proposed solution (20.04 KB, image/jpeg)
2008-06-30 00:03 UTC, Jonathan
Details

Description Baptiste Mille-Mathias 2008-01-29 21:17:13 UTC
Ther is a regression in latest nautilus

In GIO based nautilus, the picture are not well scaled:
- small pictures are zoomed and blurry
- all pictures have a outside border 

I don't know what is the guideline to draw picture previews, but I think 
- Small pictures should be displayed at their normal size; 
- No border for small picture or/and with transparent background
Comment 1 Baptiste Mille-Mathias 2008-01-29 21:40:28 UTC
Created attachment 103984 [details]
a screenshot

the red points show images zoomed in
Comment 2 Cosimo Cecchi 2008-01-29 23:33:34 UTC
Confirming, I see this here too.
IMHO the tiny white border is fine in most cases, but zoommed thumbs for small pictures look definitely bad.
Comment 3 Cosimo Cecchi 2008-02-24 23:06:16 UTC
*** Bug 517953 has been marked as a duplicate of this bug. ***
Comment 4 Jaap A. Haitsma 2008-02-25 05:49:37 UTC
In the old nautilus the rule was if there is a transparency channel we don't show a border
Comment 5 Alexander “weej” Jones 2008-03-17 22:45:07 UTC
Please DO show a border, always. I don't want to be confused between a file of type OpenDocument Text vs. the actual PNG of the icon. It's annoying.
Comment 6 Baptiste Mille-Mathias 2008-03-17 22:53:27 UTC
Alexander, the point here is not to have a border or not but restore the previous behavior; mixing request and bug in the same bugs makes hard to track the bug.

Please open another bug for your request; personnaly, I don't think putting a border is that great; perhaps another metophor should be used for thumbnails; anyway, as said; this is not the aim of the bug.
Comment 7 Alexander “weej” Jones 2008-03-17 23:01:02 UTC
Point taken, borders != blurry thumbnails.
Comment 8 Cosimo Cecchi 2008-03-17 23:01:10 UTC
As I said, I like the new behaviour (always add a border), so I would leave it as it is now.
I don't like the blurry icons, and that's the real regression IMHO.
Comment 9 Alexander “weej” Jones 2008-03-18 00:39:45 UTC
Having re-read this bug, I would like to cast my vote for leaving it how this is on both counts and closing this as WONTFIX. Scaling images indiscriminately is much saner than letting a 4×4 pixel image create a tiny, unclickable icon.
Comment 10 Alexander “weej” Jones 2008-03-18 00:44:31 UTC
Created attachment 107501 [details]
A screenshot in normal icon view

This looks much better -- the icons are consistently sized and it is clear that they are representing images. The only suggestion I can make is to employ the same kind of algorithm that GIMP uses for scaling the view arbitrarily, rather than the sinc/whatever filter going on here, so that you get crisp pixels rather than blurriness.
Comment 11 David Prieto 2008-03-25 22:35:54 UTC
"Point taken, borders != blurry thumbnails".

Regarding that issue, I just filed a bug: http://bugzilla.gnome.org/show_bug.cgi?id=524392
Comment 12 xryancat 2008-03-30 00:06:36 UTC
Wouldn't a more efficient method be to keep the images at their regular resolution, but add a 96x96px whitespace and border around the image. For example, if you have a 24x24px image, the image will be rendered in its original resolution (24x24px) but have approx. 36px of whitespace around all sides (equaling in the end a 96x96px image) with a border around the final image.

The result is non-blurry pictures that are easy to click.

Personally the current implementation is very hard on the eyes. When viewing directories with lots of small images they are almost indistinguishable from each other.
Comment 13 Alexander “weej” Jones 2008-03-30 01:09:00 UTC
Then it would give the illusion that the image actually had that much whitespace. For that reason I disapprove, sorry!

Dropping the bilinear interpolation could be an improvement. I really think we should copy what GIMP does, as it looks good and is faithful.

http://library.gnome.org/devel/gdk-pixbuf/unstable/gdk-pixbuf-scaling.html#GdkInterpType

I've a feeling TILES will be best when scaling up, but BILINEAR will be best when scaling down. Assuming it's not a massive performance hit, we should try it. I'll butcher something up tomorrow to test the appearance.
Comment 14 Alexander “weej” Jones 2008-03-30 01:11:21 UTC
I should add, we don't want to use nearest neighbour when scaling up, as some rows/columns will be different heights/widths to others in that case, and the result will be nasty.
Comment 15 Kass 2008-04-06 18:50:19 UTC
Before committing borders and scaling of all images as default, un-changeable behaviour in this version, I'd like to point out that this new behaviour can be both, a deterrent and a detriment, to people that work with images, including icon and web developers.  Let me explain.

In the previous behaviour of nautilus, a person could tell with a glance that an icon or web-icon was the correct size, transparency, and not blurry.  In this new version, however, that same person would no longer be able to obtain this information simply by looking in a directory -- they would actually need to open the image file in an editor or viewer.  Thus, for anyone in these types of situations, they have actually lost a great deal of information about their image files.

When I looked in some image directories today after upgrading, I found that I could no longer use Nautilus as a previewing and informational tool.  I didn't even know what some of the 12x12 pixel images were of as I was scrolling through the directory.  The frames caused me to actually need to open each image in an editor to find out what the size, transparency, and content of each image actually was.  I find that I cannot use this new version of Nautilus as a file management/browsing tool.

If this is to be the default behaviour, I ask that you please allow an option for those of us that use Nautilus for more image information than simply "this is an image and not an application document" to change the behaviour back to the 2.20-style.

Thank you for your time.
Comment 16 Alexander “weej” Jones 2008-04-06 20:48:42 UTC
As a non-icon developer, I can say that the current behaviour is definitely favourable, as I an now easily distinguish between what is a thumbnail preview of an image and what is actually just another type icon.

I think that all that this bug highlights is that we have a gap in the "market" for an icon set tool, and closing that gap with a proper purpose built application would be right right thing to do here, rather than clogging up the idea of "file management" with use cases from icon artists.

Would you agree?
Comment 17 G. von Nessi 2008-04-07 03:39:19 UTC
I don't see how this answers the question in comment #15. Why not simply put in an option to not scale the previews and to render them without borders? Yes, you have a gap in the market, why not cater to both of them with a non-default option? We have plenty of preferences to choose from regarding how nautilus displays information; why isn't this one of them? We can change the nautilus default background, but we can't stop images from being scaled? This doesn't make sense to me. 

The fact is, small icons are drawn in a way so that they look good when scaled to a certain size. I.e. when they are scaled to 64x64 they will look blurry/bad REGARDLESS of the scaling algorithms used. I am not an icon-developer; but I find this behaviour to be a total eye-sore and a visual distraction when trying to now use nautilus. If someone could just add the option to go back to the old preview behaviour it would be much appreciated to other markets outside of graphic designers.
Comment 18 Kass 2008-04-07 03:42:34 UTC
Sadly, no, I have to completely disagree with your comments.  I showed an
example use case to highlight the fact that Nautilus as a file management /
browsing tool has lost information in this latest version, not to describe the
need for a brand new tool for that single use case.  (Nor do I believe that a
new application is warranted when the current definition of Nautilus as a file
browser / management tool existed to fill that niche already, e.g. content
previewing.)

While there is already an option available to turn off content previewing, so
that anyone that wishes to see the kind of information that you have described
as preferable (which file is an image, which file is not), there is no option
to return to the previous behaviour.  In essence, there is now no option to
correctly preview images, only options to see less information and lesser
information about the file in question.

All I am asking for is that if this truly does become the default behaviour,
that an option is granted to allow those of us that used Nautilus to see more
information about image files, to return to that level of information.
Comment 19 Cosimo Cecchi 2008-06-03 22:43:13 UTC
*** Bug 529887 has been marked as a duplicate of this bug. ***
Comment 20 Cosimo Cecchi 2008-06-03 22:44:03 UTC
Setting target 2.24 for duplicates.
Comment 21 Baptiste Mille-Mathias 2008-06-10 11:41:10 UTC
*** Bug 537561 has been marked as a duplicate of this bug. ***
Comment 22 Baptiste Mille-Mathias 2008-06-10 11:42:22 UTC
From Bug 537561
> Nautilus is scaling up small bitmaps, drawing a thumbnail frame around them
> now. It used to render 48x48px bitmaps 1:1 without this. Scaling up small
> pixmaps ends up in blurry mess in every case.
> 
> I'm not sure why this would be useful, but for an icon designer it's extremely
> annoying. The Thunar file manager does this correctly in my opinion.
> 
Comment 23 Lapo Calamandrei 2008-06-10 15:27:05 UTC
Alex, this is clearly a regression, if you are not an icon developer you shouldn't have the problem of mixed icons pngs with mimetypes.
As an icon developer this new behaviour is a big pain, thunar does things right though.
Comment 24 Jonathan 2008-06-30 00:00:41 UTC
I created a bugzilla account just so I could join in on this conversation: This particular regression is causing me no end of grief.

I am a web developer. I rely on many small images in the course of my work and I have no way of telling anymore what I'm looking at without going through the tedious process of creating a contact sheet in Gimp.

Typical thought process since this bug was introduced: Is it blurry because it's actually blurry or because Nautilus is stretching it? Which is the 16x16 version of the image and which is 24x24? 

I just pray that someone that doesn't actually have to work with small images on a daily basis doesn't decide that this is a feature, not a bug.

My personal preference would be to use the image itself as the preview with a bounding box and a border.

I will attempt to attached an image showing the problem and with the above proposed solution.
Comment 25 Jonathan 2008-06-30 00:03:27 UTC
Created attachment 113656 [details]
Blurry icons with proposed solution

The two non-blurry images were created in the Gimp by increasing the canvas size to 96x96.
Comment 26 Christian Neumair 2008-06-30 13:28:03 UTC
I finally fixed this issue in trunk and in the GNOME 2.22 branch.