Closed Bug 423756 Opened 16 years ago Closed 15 years ago

Request: Switch for authors to turn on/off bilinear filtering when enlarging images

Categories

(Core :: Graphics, enhancement)

Product:
Core
Component:
Graphics
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: scottbert85, Assigned: longsonr)

References

(
URL
)

Details

(Keywords: dev-doc-complete)

Attachments

(2 files, 2 obsolete files)

address review comments
35.07 KB, patch
roc
: superreview+
Details | Diff | Splinter Review
reftest
2.52 KB, patch
roc
: review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4

I think that bilinear filtering on enlarged images should be optional, controlled by a switch in about:config if nowhere else. While it works well on some things, it doesn't work well on things like, say, videogame sprites used for forum avatars that are then enlarged. They just look blurry.

http://home.att.net/~miller.daniel.r/making3.htm shows that there seems to be something wrong with the bilinear filtering that adds stray pixels in an animated image (lines appear to extend from the character's hair and boot in that image, and I've seen it happen elsewhere on that site -- Haven't checked it with other sites, though).

Reproducible: Always

Steps to Reproduce:
Look at any place where an image, particularly a pixel art image, is resized.
The Kid Radd webcomic, as an example, is full of these.
Actual Results:  
The image becomes blurry.

Expected Results:  
An option allows me to change things so that the image remains sharp when enlarged.
Also see <http://forums.mozillazine.org/viewtopic.php?t=664257>

I think it makes some sense to disable the smoothing if the scaling factor is an integer...
Component: General → GFX: Thebes
Product: Firefox → Core
QA Contact: general → thebes
Version: unspecified → Trunk
Status: UNCONFIRMED → NEW
Ever confirmed: true
I think the best way to solve this would be to smooth JPEG images only. Since nobody uses JPEG images for pixel art, it wouldn't cause any problems. Leave GIF, PNG & BMP as nearest neighbor filtering.
See also: http://support.mozilla.com/tiki-view_forum_thread.php?comments_parentId=29934&forumId=1

I also agree with the notion that filtering should only be applied to inherently lossy image formats like JPEG whose purpose is not for sharpness or fine detail.  The inability to turn this off is a nightmare for designers.
There's also a performance consideration.  Bilinear filtering can dramatically reduce animation framerates if the animation involves scaled bitmaps, and the performance penalty increases with the scaling factor.  We're having this problem at work right now; we use browser scaling to pixellate sensitive imagery because it's so much more efficient than storing equivalent scaled renditions.  But when those images are dragged, FF takes a performance hit that we don't see in other browsers.

An agent-specific CSS property (ala -moz-disableFiltering) would afford authors the correct amount of control over filtering while eliminating "best-guess" heuristics that constrain design decisions.  Remember, JPEG can be made lossless.  And lossless photographs (PNG and BMP) look better under bilinear filtering than nearest-neighbor, while lossless line art (diagrams, etc.) tends to look better under nearest-neighbor.
Might as well mark bug 456183 as a duplicate which I filed earlier before finding this one. 

But I think this should be disabled by default or at least for images under a certain size regardless of format. While I like Jeffs' agent-specific CSS property, it would be better if the option was only to enable it for those who want it as it adds some unwanted and unnecessary markup. This prevents users from being surprised by something only Firefox is doing to their images while other browsers aren't.
(In reply to comment #6)
> This prevents users from being surprised by something only Firefox
> is doing to their images while other browsers aren't.

Firefox 3, Safari, and IE8 (IE7 as well, I think) all apply bilinear filtering to all imeages when upscaling.  Opera might as well, haven't checked.
Anyone using image up-scaling *on purpose* is going to find that bilinear filtering completely ruins the look they're going for.

Examples:
pixel art, including animated gifs and forum avatars
graphics programming diagrams & examples
technical photography articles & forums

Basically, any website that concerns itself with *pixels* may be rendered incorrectly because of this bilinear filtering. Not just incorrectly, either, but also unpleasantly; for any end user with text antialiasing disabled, a website showing a mix of sharp text & blurry images (including logos etc.) will look pretty bad when zoomed.

The Image Zoom addon now renders images unpleasantly blurry, too (since Firefox 3.0.3), making an excellent addon almost entirely useless. It can no longer be used for getting a closer look at an image, because with filtering it shows *less detail*, completely defeating the user's intention.


An option to disable filtering at scales >100% (regardless of image format) is, in my opinion, absolutely necessary.

To put it another way: if you woke up one day and found your monitor was applying a "smoothing" filter to everything it displayed, and you couldn't switch it off, how many stories would it fall when you threw it out the window?
@comment #9
That doesn't apply to us that use sited that use Pixel graphics that are upscaled automaticly.

like the GaiaOnline Customize Avatar feature.
for Example.
Here is the Image

http://i9.photobucket.com/albums/a85/ElderKain/Random%20Pics/AvatarNorm.png
GaiaOnline Automaticly Stretches that that on the site which with this darn blur filter think, it makes it look like this
http://i9.photobucket.com/albums/a85/ElderKain/Random%20Pics/AvatarBlurred.jpg
See how blury it is because of the filter.

We can't just change that ourselves becasue that's embeded into the site.

That has nothing to do with the zoom feature, tha'ts just resized image which gets blured.
It's a PNG graphic which having the bilinear filter on a PNG is completly useless as it is...
Another site which displays resized pixel art (GIFs) which is now blurred - 
http://www.smspower.org/
Resized images for the purposes of allowing the user to 'zoom in' and see extra detail are used all over the Internet.

Since making an image larger than its original dimensions yields no further detail, bilinear filtering is only useful when the image is *reduced* in size, to reveal lines of pixels that would otherwise be dropped completely.

I suggest applying the filtering only when the image is displayed with smaller dimensions than its actual size.  This allows people to continue to zoom images as normal, while making other images smooth as intended.

Or, of course, make it an option in about:config at least.
(In reply to comment #11)
> Another site which displays resized pixel art (GIFs) which is now blurred - 
> http://www.smspower.org/
Actually if you have Javascript turned on we go to some effort to redraw the image with squares in a <canvas>, so it's not a great example.

An about:config setting is a bad idea, custom CSS ideal.
Confirmed, I added smspower.org to my Javascript whitelist and the images display properly now. But I still say that something should be done about this as it breaks other sites which use upscaled pixel art.
(In reply to comment #13)

Why would an about:config setting be a bad idea?  Anyway, I agree that it should be a last resort only.

Adding another non-standard CSS attribute to Firefox's repertoire doesn't sound like a great idea to me.
It makes more sense for particular sites to be able to control the rendering of individual images, than for a single (hard-to-access) browser setting to globally control the rendering of all images on all sites.

For almost all downscaling, and non-integer upscaling of photographic images (which may be paletted), filtering is good. For integer upscaling of pixel art (which may be 24bpp), filtering is bad. Switching behaviour on the transition from 1.99 to 2.00 is bad. So algorithmic approaches are a bad idea.

Of course a new CSS attribute is ugly, especially since it hasn't really got any application to elements other than images, but how else can page designers control this?
SVG has the image-rendering property -- http://www.w3.org/TR/SVG/painting.html#ImageRenderingProperty -- which could be uplifted to HTML for this purpose.  I think that SVG's is somewhat misguided though; optimizeQuality vs optimizeSpeed does not make a clear distinction between filtered or non-filtered.  I'd suggest a new image-filtering property which just sets whether images should be filtered or not when scaled.
Is nothing being done with this? I know most users probably don't even notice the bilinear "feature" in firefox, but when you need to see an unfiltered image (which I for one often have to) I am forced to use another browser... I'm now using Opera to do this, which is annoying. By its nature upscaling is a destructive process.

It should be the decision of the content creator to optimise images (choosing their own non-lossy format)properly. This "feature" being on by default means that sites are being rendered with unwanted filtering which is against the ethos of a "standards compliant" browser and should be an optional element.

This "feature" of firefox should be disabled or optional in the next release. Until then, I will be using Opera.
This stupid feature just kills FF3 for me. Im still using FF2 but now its at the end of life and im forced to migrate to Opera. Im sad but thats the life...
Same here. I'm still using Firefox 2 and switch sometimes between this and Opera, which has a great handling of image scaling. You should really kill off this function. I run a website about retrogaming and under FF3 it looks disfigured, obviously many other sites with the same theme are affected too. On the other hand, I can't think of a single instance where this feature has been useful.
This forced antialias is a big no-go!

As someone else already mentioned, resized "pixelart" images now look really ugly. More websites where this "feature" is terribly annoying are HOL and Lemonamiga, two examples:

http://hol.abime.net/2754/screenshot (click on a thumbnail, then on "2x" above the screenshot to resize it)
http://www.lemonamiga.com/?game_id=2709 (click on a thumbnail in the list, then click the big screenshot to resize it)

I think this "feature" should be dropped, no matter what image format. If at all, make it an opt-in function in the options window, NOT somewhere hidden in about:config (which most Firefox users don't know because they aren't nerds and don't care).

What where the FF3 coders thinking about implementing a "feature" (and a few more) that nobody wants?
So this hasn't been addressed yet?  I still have to use IE6 to view pixel art properly.
In the interests of balance, here's some arguments the other way:

http://www.joelonsoftware.com/items/2008/12/22.html
http://code.flickr.com/blog/2008/11/12/on-ui-quality-the-little-things-client-side-image-resizing/

Since other browsers are moving towards filtered scaling, it may be a fait accompli, but not making it configurable is a real pain.

I may as well pimp our solution: http://www.smspower.org/scalefix.js which redraws the image as squares on a canvas, but it's not universal (canvas support being rather messy between browsers) and designed for 1-bit alpha.
Guys, it's great that you're enthusiastic about seeing this get resolved, but spamming the bug is not the proper way to do that. All it does is send a LOT of mail to a LOT of people (many of whom aren't developers) and bury any comments useful for fixing this bug under all the other ones, making it harder for someone to pick up and work on. Please read the etiquette guidelines before posting more comments. If you want to discuss this further, please take it to the mozilla.dev.platform newsgroup.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
>controlled by a switch in about:config if nowhere else

If we add a pref, I think it should only be in about:config.  The vast majority of users won't be able to make an informed decision.
As a web designer myself, there are a few web-tricks I do with *.gif images that consist of resizing a 2px image and stretching it for various purposes. In some testing I've noticed that this aliasing shows up. I really believe that aliasing should only be applied for lossy formats (jpeg, etc) or vector formats. I'm a tad frustrated that it isn't even an option... but now the majority of browsers have made the decision to alias formats that shouldn't be aliased. Where was this discussion?
Ok, here's a patch that adds a hidden pref ("gfx.images.smooth_scale") that can be set to disable smooth scaling of images.  Patch is a bit bigger than you'd think since I reused the existing pref observer and just renamed it some in gfxPlatform.

We really need a CSS attribute to control this; SVG unfortunately has nothing that we can reuse here, because its CSS attributes are focused around making a performance or quality tradeoff, not about explicitly specifying filtering.
Assignee: nobody → vladimir
Attachment #356253 - Flags: review?(joe)
If I understand it right: Joe needs to review this, and if he approves the patch it will be included in the next ff update?

Is there a possibility to use this function before the next update, without messing with the source code?
Comment on attachment 356253 [details] [diff] [review]
add hidden pref for this (gfx.images.smooth_scale)

>-                pattern->SetFilter(0);
>+                pattern->SetFilter(gfxPattern::FILTER_NEAREST);

I presume FILTER_NEAREST is the same as FILTER_FAST, and thus the same as 0?

>+    if (!gfxPlatform::ShouldSmoothScaleImages()) {
>+        pattern->SetExtend(doTile ? gfxPattern::EXTEND_REPEAT : gfxPattern::EXTEND_NONE);
>+        pattern->SetFilter(gfxPattern::FILTER_NEAREST);
>     }

Why is the SetExtend call necessary? 

>-    void SetFilter(int filter);
>-    int Filter() const;
>+    enum GraphicsFilter {
>+        FILTER_FAST,
>+        FILTER_GOOD,
>+        FILTER_BEST,
>+        FILTER_NEAREST,
>+        FILTER_BILINEAR,
>+        FILTER_GAUSSIAN
>+    };

There should probably be a comment here saying that "either this enum must be the same as cairo_filter_t, or SetFilter must be changed."

r+ otherwise.
Attachment #356253 - Flags: review?(joe) → review+
So... When will this thing work?
We really need this CSS enhancement ... it completly ruins our business
I completely second PP's and all the other comments. How could this *ever* go into the release without being thought over?

The *site author* has to be able to control image scaling behaviour, there's a -moz- css attribute for so many other things, so why not for this?

I am following the mozilla project since M5 or so, this is the one issue that has deeply shaken my confidence in the project and the people responsible for making decisions here. Not a good thing in the current rising of Chrome and other browsers to scare away the old-school supporters like this.
Well, except that Chrome does it too. (http://code.google.com/p/chromium/issues/detail?id=1502)

Unfortunately, I think this is going to be the norm in a year or so.
I agree that the site author should to be able to control image scaling behaviour - but also as a USER, I never, ever want to see an image up-scaled with anything but nearest-neighbour filtering, because every alternative is BLURRY and HORRIBLE.

Down-scaling methods are (generally) okay. The problem is that Firefox now BLURS any images that it up-scales, because that's the nature of bilinear filtering, like biting and mauling are the nature of tigers. There is just NO FILTERING METHOD that can up-scale an image in a way that looks as good as the original. NONE AT ALL.

Please, let this be fixed; the web has been unpleasantly blurry for long enough.

Nearest-neighbour filtering for integer up-scale factors (like x2, x3 or x4) would be ideal. Binning for 1/integer down-scale factors (like /2, /3 or /4) would also be ideal. Seriously - how is this not obvious? What is wrong with this idea? How has this bug gone unaddressed for almost a year when the ideal solutions are so obvious?
Yup, and than just everyone who would not like his image pixelly have to resize it 199%, or 299% or 301 or whatever.
It would work, but id prefer a css atribute, AND an option to set it automatic to what you want yourself. As Vladimir coded.

When will that be included in firefox? Vladimirs fix? :?
Is there some 'particular' reason why people are dragging their feet on this fix?  This is something that really should have been a choice from day one, and it's taken a year since it was reported for someone to even look at implementing an on/off setting?  This seriously brings into question the competency of some Firefox developers.
How tricky would it be to write an extension to do this? As a non-programmer I really have no idea.

I really hope this gets fixed soon. Having to switch to Opera every time I want to look at zoomed images on sites like Pixeljoint or Lemonamiga or such is getting extremely annoying.
I recently reinstalled windows (and firefox) so when it auto-updated to FF3, I actually used IE for a brief period.
How dare you mozilla.
So a fix has been available for just adding now for a few updates right? Does anyone know why this is never happening?
Very disappointing that firefox still hasn't included a simple option allowing enabling or disabling of the Great Blur. I just don't understand why there's so much choice in just about every area of firefox, but none here.
I have just mailed Joe, I hope he can provide some more info. If not, I will send an email to vladimir too.
Can this issue be fixed for Firefox 3.1/3.5 (like in IE)?

It is very disappointing that this critical issue has been open for a full year now. Just do a google search, in every discussion about the smooth rescaling feature people complain about this bug.
Dolefully, in linux version of Firefox bilinear filtering is not even implemented.

It seems to me that in compare with users of propietary software linux users are not a priority to Mozilla.

Sad.
(In reply to comment #43)
> Dolefully, in linux version of Firefox bilinear filtering is not even
> implemented.
> 
> It seems to me that in compare with users of propietary software linux users
> are not a priority to Mozilla.

Incorrect. It's because we need to use bilinear sampling with EXTEND_PAD in Xrender and most Linux drivers support that extremely poorly due to bugs. See this cairo thread for details:
http://lists.cairographics.org/archives/cairo/2009-January/016320.html

But there is good news for this bug. Bug 484150 adds support for the SVG "image-rendering" CSS property, with an extension value "-moz-disable-resampling" which does what you want --- but only for SVG images, in that patch. We can and should do a followup patch to let that property apply to HTML <img>s and maybe even CSS background-images. We can easily do that here in this bug after 484150 has landed.

Robert Longson (who is implementing image-rendering for SVG) even proposed that the disable-resampling property value be standardized:
http://lists.w3.org/Archives/Public/www-svg/2009Mar/0179.html
It looks like it may be adopted, with the value named "crispEdges".
Depends on: 484150
I don't mean to be rude, Robert, but rather than address someone asking 'for' bilinear support in the Linux build, why can't you give us an update on the status of making bilinear filtering optional for Windows users?
Stevens, the first paragraph was about supporting bilinear filtering on Linux, sure, but that was only the first of three paragraphs. The second and third paragraphs seem to be an update on the status of making bilinear filtering optional, no?
Robert,

Because the resampling effect is a regression from previous version of Mozilla, this property "disable-resampling" should be enabled by default. This way, no update has to be done to our website.

This is fundamental that this resampling is disabled by default, like that was the case for previous version of Mozilla.
(In reply to comment #47)
> Robert,
> 
> Because the resampling effect is a regression from previous version of Mozilla,
> this property "disable-resampling" should be enabled by default. This way, no
> update has to be done to our website.

That part won't happen; resampling images is a net increase in quality for the majority of users.  When specific use cases make it less desirable, the CSS property will be there to provide that control.  If you wish to disable it on all images on your site, I suggest putting a CSS rule for all img elements somewhere on your site; if you wish to disable it for all sites yourself, you can add it to userContent.css.
Vladimir, how does the average user know how to operate your 'fix'?

I find it difficult to believe this 'feature' increases overall quality for the majority of users. The very concept of resampling or filtering image content means a distortion. With low resolution content this is incredibly destructive.

Your reply suggests that there be yet ANOTHER workaround by designers to compensate for ignorant developers. The job of a browser is to display content as it was created. Why should anybody to have to put in workarounds for zooming content?

What happened to web standards here? Why is it so hard to just implement a button in preferences that switches this 'feature' on/off. My vote is that this should be part of your initial setup process. I vehemently agree that this should be disabled by default and I find it laughable that you think screwing with content is an advantage in a browser. Isn't that a very IE way of thinking?

The user at some point should be asked if they want images to be filtered. I certainly do not buy the reasoning that it's 'better' for a majority of users. On what basis? Did you put this 'feature' out for any public consultation? I certainly haven't seen any - it seems it was simply added to FF3.

Another suggestion is to place a 'unfilter/filter' option on right click (of image).

If a person in windows wants to see an image as a horribly blurry mess - they simply need to view it in explorer - its simple enough to do and should not be dictated by your browser (imho). Is this really that hard to fix?
Are you actually serious or was your last post a joke?
Also I believe for the majority of users it is better to have the images filtered etc.
The right click filter is a great idea in my opinion btw.

Here is what would look perfect to me:

Most images automatically filtered, this is changeable in the config
Indexed PNG and GIF images not automatically filtered, this is changeable in the config
Right click filter/nonfilter enables the user to change things in one specific case
Webmasters should be able to set an attribute that changes their cases too, for example even though auto filter is on, he can still make his 24bit PNG's to be not filtered.


Would there be any use of a filter on Indexed PNG's and Gifs?
If you make it only disable bilinear filtering for any indexed color image, as long as it's an integer scaling factor, and make it the default setting, that should be perfect.
Well, I know quite a few non indexed PNG images that would not need the filter, and quite a few non indexed PNG images that do. Those PNGs might become a problem. Furthermore I agree with you.
(In reply to comment #53)
> Well, I know quite a few non indexed PNG images that would not need the filter,
> and quite a few non indexed PNG images that do. Those PNGs might become a
> problem. Furthermore I agree with you.

You're right, we have lots of 24bits PNG images which should not be filtered.

But those images have ALL an integer scaling factor. I don't see any uses to filter images with integer scaling factors, really. If so, the default behavior for these should be "no filter" imho for retro compatibility.
Switching the default to nearest-neighbour only is not going to happen. If you want to keep talking about it, please file another bug for that.

This bug is about providing author control. If you keep talking about other topics (like a change to the default) on this bug, then you are only decreasing the probability that this bug will be fixed by making it harder for developers to deal with this bug.
Vlad, I'm willing to take a crack at using the SVG CSS property for html images if that's OK with you.
(In reply to comment #56)
> Vlad, I'm willing to take a crack at using the SVG CSS property for html images
> if that's OK with you.

Absolutely; go for it.. I have a patch here somewhere that added the filter types to gfxPattern, instead of passing magic constants around.  I can't find it right now though; I'll put it up if I find it, since that's probably good cleanup as part of this.
Robert already added them to gfxPattern in bug 484150 ... I reviewed it, hope that's OK!
Assignee: vladimir → longsonr
>This bug is about providing author control.

Adjusting summary to make it clear that this is about author control as opposed to end user control (although as vlad mentions end users who are extremely informed can control this setting with userContent.css).
Summary: Request: Switch to turn on/off bilinear filtering when enlarging images → Request: Switch for authors to turn on/off bilinear filtering when enlarging images
I thought this bug report was focused on end user control. It stated this in the original post. All this stuff about creating case-by-case scenarios is going against the original intent to simply have a global control availiable through about:config. Having a filter running by default is more than acceptable as Robert(or whoever it was) made the point nicely that the filter is a very pleasing addition for the majority. I'm fine with that and I'm certain many others are, but I NEED to have the option to determine MY own level of filtering(which is none or nearest neighbour). If the switch was for authors, then thousands of site authors would have to overhaul tens of thousands(best case scenario) of pages of video game and other pixel art and that just isn't going to happen. 

I can't agree with the new direction of this bug report.
You'll be able to add rules to userContent.css to turn off filtering everywhere. If you think a more accessible interface than that is needed, please file a new bug for it.
Sir, yes sir!
Are we in the forces here?

Why didn't you file a new bug instead of changing from "Switch to turn on/off bilinear filtering when enlarging images" to "Switch for authors"?

I support Comment #60! This bug is about end user control as simple as possible for the end user. The bug reporter requestet it in about:config. I gave my vote for control in about:config and NOT for an author switch. These votes are captured by you. YOU should file a new bug, if you want a switch for authors!
Agreed. I want to be able to control things myself instead of having to wait for all my favorite websites to change their settings.
addendum:
With the word "you" I mean Mozilla and not Robert or Alex personally.
Switch for authors is a different bug.
Authors should be the priority. Once we make the changes in our websites it will reach a lot more people than the few end users who know how to modify on their own variables in the config; with a Mozilla CSS Extension updating those "tens of thousands of pages" (comment #60) will be a breeze.
Authors should be the priority? Really?
That sounds like the absolute worst solution to a stupid problem that shouldn't exist in the first place.
At the very least I am never updating to FF3 and I'm probably going back to IE, this whole situation has been nothing but insulting.
(In reply to comment #66)
> Authors should be the priority? Really?

This bugs (requests) title is (now) "Switch for authors…". 

The about:config pref (yes, mentioned in the description - what a contradiction) is NOT the solution for authors. But … you can also be "author: (just to sum up what is proposed): You might be able to update the userContent.css (or use the Stylish addon) with something like

img { -moz-scaling-method: fast } /* nearest | bilinear | gaussian | … */

This is IMHO a bit more comfortable than using about:config (my personal opinion) 
and this also would be useful for web developers ("authors") out there. It would be possible to set this up only for exact domains and selectors in userContent.css, what is IMO not simply possible doing in about:config.

As said, if you insist on the global about:config pref, post another request. My opinion is that it would not spoil anything. But if we had just the switch described above, I would be fully satisfied.

(Apologies for my bad English.)
The problem with making it an author switch only is that some authors may be unaware of the switch and not using/designing for firefox, or someone may be visiting a legacy or abandoned site -- in such cases, the user needs an option to enable this themselves.
I agree 100% with Scott and Gerd.  My vote went for a user-controlled setting, and you have now rather underhandedly changed it to something else.  Why not just void this entire voting process and do whatever the hell you like if the votes count only for content the developers themselves want to address?  Whoever decided to literally change the purpose of this bug report completely invalidated the point of it and the REASON people have been voting for a fix.

Nice work, you've officially ended my interest in Firefox!
In the context of authors, a CSS based solution is useful but could a NAME meta tag in the head of the document serve as another option? Something like:

<META NAME="mozscaling" CONTENT="fast" /> 

This way those concerned about CSS validity won't get hit with warnings or errors and it really doesn't affect the document validity.
I think we need both a CSS attribute (for authors) and a configuration setting (about:config or anything) (for users).

I also think it's pretty awesome to have a tool such as this to let our voices be heard by the devteam, and being an open source developer I trust whatever way they want to handle requests for enhancement. 

I think this request in special is pretty relevant to a large number of people and I wonder why its importance has not been perceived for such a long time; I hope they will fix it soon though.
Are you people not reading?

As both roc and I said, once the CSS attribute support is added, you'll be able to add the attribute to apply globally to all sites/images by putting the rule in your profile's userContent.css.  There is very little chance that this will be exposed in the UI as a preference, and given the presence of the CSS attribute, not much reason to expose it in about:config.
Rob,Vlad, and the others, thank you for the explanation. Sorry, but this CSS stuff is quite beyond my understanding, so I assumed when the title was changed that optional filtering would only be available to site authors with CSS knowledge. If it's as simple as adding a line(that you will provide, pretty please :)) to a file I just edit with a text editor, then that sounds like something I could be guided through without much trouble. 

I think I might just follow one of the above posters suggestion to start a new report to get an option included in about:config. I would've like something in about:config, but any kind of fix allowing personal choice is a welcome step, so I'll leave you guys to your work, and I thank you for the prompt replies and recent activity. 

There's a quite a few of us who've been eagerly waiting for some help on this for a while now, so it's nice to see some action.

Thanks.
There is very little chance that this will
be exposed in the UI as a preference, and given the presence of the CSS
attribute, not much reason to expose it in about:config.

Vlad, could you explain why there isn't much reason to expose it?  Surely, allowing the user to quickly edit this setting inside of Firefox is easier than forcing them to manually edit a CSS file and add 'rules' for it?  Opera has had such a config setting for ages, and no one has complained about it being there or has had cause to complain about filtering or non-filtering, since the option to turn it on or off is readily available.  It just seems like the dev team is really overcomplicating what could be a straightforward solution to satisfy the greatest amount of people -- a solution I daresay should have been offered to us at 3.0's launch.
Stevens, I don't really disagree with your points, but we are going to get a way to disable filtering that should in the meantime be easy enough to guide people through. Once the CSS option is available for us, we can make the case for adding it to about:config. This bug report's been open for over a year so let's take this one step at a time.
I will have to excuse as well, I did not know, and so did not understand the stuff about userContent.css.
I now understand how it works, and yes, it sounds doable, but only for a small amount of people. However, there is also just a small amount of people that will use about:config, while with the css thing webmasters can seem to set the settings as wel. So to me, it looks fine now.
Attached patch patch (obsolete) — — Splinter Review 
Not sure how I'd do CSS Background Images how can I determine what filter to use? Any ideas roc?

This does, however do html <img> elements.

FAQ:
For one img element add style="image-rendering: -moz-crisp-edges;"

For all img elements on a page/website add 

img { image-rendering: -moz-crisp-edges; } 

to the css stylesheet(s) for the pages.

To fix your browser to never filter add

img { image-rendering: -moz-crisp-edges; } 

to userContent.css (see http://www.mozilla.org/unix/customizing.html)

Other values are supported (see http://www.w3.org/TR/SVG11/painting.html#ImageRenderingProperty)

Caveats:
Doesn't work on Linux (see comment 44 for why)
Not tested on Mac, although there is code for that platform.
Attachment #356253 - Attachment is obsolete: true
Attachment #370513 - Flags: superreview?(roc)
Attachment #370513 - Flags: review?(vladimir)
Attachment #370513 - Flags: review+
(In reply to comment #78)
> Not sure how I'd do CSS Background Images how can I determine what filter to
> use? Any ideas roc?

PaintBackgroundLayer has aForFrame, why can't you just use its image-rendering property? Same for DrawBorderImage.

Other than that the patch looks great.
Comment on attachment 370513 [details] [diff] [review]
patch

Yep, what roc said for background images -- this looks fine though, but may as well get the background piece in at the same time.
Attachment #370513 - Flags: review?(vladimir) → review+
I'm not sure what aForFrame is, but it doesn't seem to be the one I need. I tried 

body 
{
background-image: url('animage.jpg');
image-rendering: -moz-crisp-edges;
}

And it had no effect on the background image. aForFrame is an nsBlockFrame and did not have the property.

I suspect we need a -moz-background-image-rendering CSS property, if so I'd rather do it in a follow-up bug and get dbaron or bz to help with it. If not where am I going wrong?
OK, "body" is a special case because the body background propagates to the viewport, so aForFrame is probably the root element's frame or something like that. Try it on a DIV.
You are right. div works fine. 

What should I do about body?
I don't need reviews from any other module owners do I?
Attachment #370513 - Attachment is obsolete: true
Attachment #370597 - Flags: superreview?(roc)
Attachment #370513 - Flags: superreview?(roc)
Comment on attachment 370597 [details] [diff] [review]
address review comments

If you set image-rendering on the root element, does that work for the body background? I expect so, and if so, then I don't think we need to do anything here. Body background propagation is quirky and I don't think we need to bend over backwards to make image-rendering fall in line.

I don't think you need any more reviews. This should be fine.

There are two more places we could use this property: <canvas> (to control the filtering used to scale the canvas when we render it) and <video> (similar).
Attachment #370597 - Flags: superreview?(roc) → superreview+
... but we can do those in a separate patch. Thanks for doing this.

We should have a test here though. Should be easy enough to compare two test images, or an image to a reference made up of positioned DIVs.
html
{
background-image: url('animage.jpg');
image-rendering: -moz-crisp-edges;
}

doesn't work either. Neither does * { ... }

canvas already has a bug for this - bug 436932 

I'll work on some tests.
Attached patch reftest — — Splinter Review 
The images are green squares of different sizes a smaller red square. Zoom the smaller and compare it to the larger.
Attachment #370684 - Flags: review?(roc)
Bug 436932 is actually different. That controls how images are filtered when they're rendered into a canvas. image-rendering on the canvas element would control how the canvas is filtered when it's rendered to the screen.

We probably should do something to fix the root background situation (in a separate patch). nsLayoutUtils::GetGraphicsFilterForFrame should probably do something like nsCSSRendering::FindBackground to find the right style to use.
Yep, we should do the canvas piece as well, but can do it separately from this bug.
Checked in http://hg.mozilla.org/mozilla-central/rev/59a3c8eb8572 and http://hg.mozilla.org/mozilla-central/rev/359e78ff03a6
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Keywords: dev-doc-needed
Flags: in-testsuite+
Blocks: 486933
Blocks: 486934
Blocks: 486935
Blocks: 486936
If i'm not mistaken, this patch is the cause of the build failure i'm now experiencing:

g++ -o nsAlertsIconListener.o -c -I../../../dist/include/system_wrappers -include ../../../config/gcc_hidden.h -DOSTYPE=\"Linux2.6\" -DOSARCH=Linux -I../../../toolkit/components/build/ -I. -I. -I../../../dist/include/xpcom -I../../../dist/include/string -I../../../dist/include/necko -I../../../dist/include/alerts -I../../../dist/include/gfx -I../../../dist/include/imglib2 -I../../../dist/include/intl -I../../../dist/include/widget -I../../../dist/include   -I../../../dist/include/mozgnome -I/build/buildd/xulrunner-1.9.2-1.9.2~a1~hg20090406r26991+nobinonly/build-tree/mozilla/dist/include/nspr   -I/usr/include  -I/build/buildd/xulrunner-1.9.2-1.9.2~a1~hg20090406r26991+nobinonly/build-tree/mozilla/dist/sdk/include    -fPIC   -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -pedantic -g -fno-strict-aliasing -fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions  -DORBIT2=1 -pthread -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -pthread -DORBIT2=1 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gconf/2 -I/usr/include/orbit-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gnome-vfs-module-2.0   -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12      -DMOZILLA_CLIENT -include ../../../mozilla-config.h -Wp,-MD,.deps/nsAlertsIconListener.pp nsAlertsIconListener.cpp
In file included from nsAlertsIconListener.cpp:42:
../../../dist/include/gfx/nsIImage.h:44:24: error: gfxPattern.h: No such file or directory
In file included from nsAlertsIconListener.cpp:42:
../../../dist/include/gfx/nsIImage.h:215: error: 'gfxPattern' has not been declared
../../../dist/include/gfx/nsIImage.h:215: error: expected ',' or '...' before 'aFilter'
../../../dist/include/gfx/nsIImage.h:285: error: 'gfxPattern' has not been declared
make[4]: *** [nsAlertsIconListener.o] Error 1


Full log: https://edge.launchpad.net/%7Eubuntu-mozilla-daily/+archive/ppa/+build/931275/+files/buildlog_ubuntu-jaunty-i386.xulrunner-1.9.2_1.9.2~a1~hg20090405r26939+nobinonly-0ubuntu1~umd1_FAILEDTOBUILD.txt.gz
Are you building xulrunner? The tinderboxes do build that and they seem to manage it so I'm not sure what your issue is.
Depends on: 487160
(In reply to comment #92)
> Are you building xulrunner? The tinderboxes do build that and they seem to
> manage it so I'm not sure what your issue is.

tinderboxes seem not to build all the gnome components that ubuntu currently builds on trunk.

opened bug 487262 for this regression.
There is a fix for that build failure in bug 487160.
So apparently this "feature" has been fixed, but I don't know where I can turn off that hideous antialias in FF3.5.

Someone please tell me. And no, I'm not going to touch about:config.
It seems it's coming with Gecko 1.9.2, which will be implemented in Firefox 3.6; we still need to be a little bit more patient:
https://developer.mozilla.org/En/CSS/Image-rendering
I have been using the alpha version of 3.6 (minefield) for at least over half a year now. And the image rendering works great.

However, today I noticed the beta of 3.6 is out, and there it is not fixed again! What is happening?
I tried just now and it works perfectly fine in my 3.6 on Windows which I've admittedly built from source rather than installed like you have. The fix includes automatically run tests that would fail if any other fix broke it.
I am a person who does not know what half this things are, knows the bare basics of about:config and currently have this in Help!About Mozilla Firefox: "Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3".

This issue really bugs me. I would like to have the option to change this but I don't. 

Would anyone be able to help me?
As annoying as it is, you have to add an option to your chrome folder to turn the filtering off for all images right now.

Follow the instructions on:
http://www.pixeljoint.com/2009/06/14/2854/Bilinear_Filtering_is_over_sorta_%3BP.htm

The post by "jalonso"
To sum it up: 
1) Go to your Firefox profile folder ( http://kb.mozillazine.org/Profile_folder_-_Firefox )
2) Go to the "chrome" subfolder
3) Create "userContent.css" text file (or rename existing example)( http://kb.mozillazine.org/UserContent.css )
4) Finally, add there following line and save.
img { image-rendering: -moz-crisp-edges; }
I would like to suggest that Gecko should always use nearest-neighbor (fast) interpolation when an image's resolution is larger than a certain threshold.

For example, Firefox really, really struggles when reducing the size of a 2000x2000 or larger JPEG image within a web page, and this is even more noticeable if CSS applies other positioning and scaling restrictions to the image or parent elements.

I'm guessing that the interpolating is happening every single time the page is re-rendered?  (I don't claim to know much about this)  If that's the case then maybe instead, Gecko could interpolate once, and cache the image result for the last requested dimensions?
(In reply to comment #102)
> I would like to suggest that Gecko should always use nearest-neighbor (fast)
> interpolation when an image's resolution is larger than a certain threshold.
> 
> For example, Firefox really, really struggles when reducing the size of a
> 2000x2000 or larger JPEG image within a web page, and this is even more
> noticeable if CSS applies other positioning and scaling restrictions to the
> image or parent elements.
> 
> I'm guessing that the interpolating is happening every single time the page is
> re-rendered?  (I don't claim to know much about this)  If that's the case then
> maybe instead, Gecko could interpolate once, and cache the image result for the
> last requested dimensions?

Please file a new bug, this one has been resolved.
Feature trashed in certain cases by this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=598890
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: