| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #2869
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Image Support |
|---|
| Summary: | Better scaling algorithm |
|---|
| Version: | 1.3-feature |
|---|
| Created By: | sanel.z |
|---|
| Assigned To: | cand |
|---|
| Fix Version: | 1.3-current (SVN: v10268) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | sanel.z
01:23 Sep 06, 2012 |
| FLTK for scaling images uses nearest-neighbour algorithm. This algorithm is quite fast, but yields jagged images, especially if image is scaled to smaller size.
EDE uses a lot of small images, either from icon themes or icons provided by applications. Standard sizes (16x16, 32x32, ...) doesn't have to be present, so EDE has to scale them, rendering icons often hard to notice or distinguish (I attached the screenshot).
This can be solved by providing alternative algorithm like bilinear or bicubic interpolation; they are slower buy yields much better scales. The implementation can add additional parameter to copy() where user can choose what to use, e.g.
image->copy(16, 16, FL_SCALE_BICUBIC); | |
| |
| #2 | spitzak
10:01 Sep 20, 2012 |
| FLTK should *ALWAYS* use filtering when scaling images. If it is using nearest-neighbor it is a bug. There should NOT be a control to turn filtering on/off because some backends do not support no filtering.
In addition "bilinear" is hardly sufficient. It is technically wrong for any scale < 1, and has noticable artifacts for any scale < .5. Correct filtering MUST use more than 2 pixels to contribute to an output pixel in each direction. There is NO WAY AROUND THIS, even though you will find lots of people deluded into believing that if they just "bilinear better" it will fix things.
Cairo has this problem, so does OpenGL (as long as you don't use mipmaps). My recommendation is for FLTK to use a box filter to scale down by an integer near the final scale, and use the system bilinear filtering from there.
OS/X does correct filtering when scaling images. Cairo, Xrender, OpenGL, and Windows are all broken. | |
| |
| #3 | cand
06:17 Jul 24, 2014 |
| Attaching patch for 1.3 to use bilinear filtering instead of nearest-neighbour. Bicubic or better would be much more complicated, and would be best to borrow from an image lib.
The test app and before/after images display the original 32x32, minified 16x16 and enlarged 128x128. | |
| |
| #4 | cand
04:04 Sep 03, 2014 |
| Fixed in Subversion repository.
Bilinear scaling support is now available, as discussed on coredev. | |
[ Return to Bugs & Features ]
|
| |
