| [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3062
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: | Bilinear interpolation of images |
Version: | 1.3-feature |
Created By: | rokan2 |
Assigned To: | cand |
Fix Version: | 1.3-current (SVN: v10268) |
Update Notification: | |
Trouble Report Files:
Trouble Report Comments:
|
#1 | rokan2 16:15 Mar 02, 2014 |
| Attached you will find code for image resizing which gives more pleasant visual results than recent "nearest neighbor" but it is still reasonably fast.
As an implementation example there is a function
Fl_Image * fl_copy_image(Fl_Image * im, int w2, int h2);
so that the code can be used without patching FLTK. However to allow existing fltk widgets (especially those using Fl_Shared_Image) to take full advantage, it would be good to modify the fltk method Fl_RGB_Image::copy() and add a new static method like Fl_RGB_Image::copy_type(...) which would take as argument enumerations
FL_NEAREST_NEIGHBOR FL_BILINEAR
and maybe in the future other (bicubic, ...) to indicate what algorithm should be used during copy() (eg users can put it at the beginning of the program). I would keep nearest neighbor as default. Please fill free to use the code in whatever way you wish.
Roman | |
|
#2 | ianmacarthur 04:57 Mar 03, 2014 |
| This looks like a Good Thing, as our current nearest-neighbour scheme can look a bit rough at times.
I imagine that adding it as a helper function, as you show in the STR, is feasible without breaking the ABI?
I'd guess that changes to the API to add the ability to choose which resize method to use might be trickier though, from an ABI perspective?
Thoughts, anyone? | |
|
#3 | rokan2 05:39 Mar 03, 2014 |
| Actually it will not break the ABI as you do not add/modify any fields in the class by just adding a static function (just to keep it in the Fl_RGB_Image namespace context - otherwise it is the same as a global one).
The copy function can be then modified:
static int copy_method = 0; void Fl_RGB_Image::copy_method(int type){ copy_method = type; }
Fl_RGB_Image::copy(int w, int h){ if(copy_method==FL_BILINEAR){ ... // perform and return bilinear resampled image }else{ ... // perform old nearest-neighbor resampling } }
} | |
|
#4 | chris 00:54 Mar 04, 2014 |
| Scaling quality looks very good for me.
I am so free to attach a short test program and two sample screenshots of upscaling and downscaling results.
Cheers chris | |
|
#5 | cand 04:05 Sep 03, 2014 |
| Fixed in Subversion repository.
Bilinear scaling support is now available, as discussed on coredev. | |
[ Return to Bugs & Features ]
|
| |