FLTK logo

STR #3062

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

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:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size  
 
#1 rokan2
16:15 Mar 02, 2014
resize_image.cxx
17k
 
 
#2 chris
00:54 Mar 04, 2014
test_resize_image.cxx
2k
 
 
#3 chris
00:54 Mar 04, 2014
downscaled.png
56k
 
 
#4 chris
00:55 Mar 04, 2014
upscaled.png
73k
 
     

Trouble Report Comments:


Name/Time/Date Text  
 
#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 ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.