Hello Bill:

At some point it may a good idea to move this discussion off the list,
but at this point I'll hope that those without interest in these
issues are just skipping this email.

----------------------------------------------------------------------

jungle writes:
 > 
 > Nicolas Robidoux wrote:
 > > 
 > > 
 > > There are already two fast nonlinear resamplers implemented in GEGL:
 > > 
 > > YAFR (gegl-sampler-yafr.c)
 > > 
 > > and
 > > 
 > > Nohalo-sharp (gegl-sampler-sharp.c). 
 > > 
 > > 
 > 
 > I'm not familiar with those two resamplers.  Of course, that's not saying
 > much, because it's not my area of expertise.  I should mention, however,
 > that I consider NEDI and ICBI interpolators of a different kind than most.  
 > 
 > First of all, they are very slow compared to bicubic.  Speed is not the
 > goal.
 > 
 > Secondly, they don't provide a value for any point in between given pixels. 
 > Rather, their purpose is to enlarge the image in question by a factor of 2
 > (roughly.  Actually it's   size*2-1).  After scaling, the image can be
 > resampled to any size desired using other methods.  Both algorithms copy
 > known (given) pixel values into a 2x enlarged grid and then fill in the gaps
 > between pixels using certain assumptions about the statistical values of the
 > pixels.  
 > 
 > The main benefit of both algorithms is the performance around edges.  ICBI
 > is an improvement on NEDI.  Edges are much smoother and more natural than
 > bicubic.  
 > 

This is how nohalo works too, The current (low quality, but highly
optimized) gegl-sampler-sharp.c only subdivides once and uses bilinear
as "finishing scheme."

Consquently, the gegl-sampler-sharp.c code may provide a good basis
for an implementation of "single subdivision" NEDI or ICBI, "one level
implementations" which should give good results for resamplings which
only involve moderate enlargement/stretching ratios (for nohalo, it's
up to about 3-6).

 > I explain all this to try to decide if the goal of ICBI is
 > different than nohalo, and if there would be a reason to try to
 > code it.  Is there a paper I can read on nohalo?  Or examples of
 > results that I could compare to ICBI?

Nohalo-sharp and nohalo-smooth are brand new schemes (we hope: maybe
we'll find that they actually are "old"; I have to confess that I
don't know as much about them as I should). We are currently writing
the first paper about them. But there should be two comparison web
sites coming up "soon."

You can also install the current gegl svn trunk and do the testing
yourself. I'll include a sample .xml file at the end of this email
(adapted from something Øyvind Kolås passed on).

My hunch is that, given the same subdivision level, nohalo will not
"straighten" as much as NEDI/ICBI, but will show less "fine scale
artifacts" and will run faster---even if programmed with the same
programming skill.

This being said, if you would contribute toward the programming effort
involved in implementing the "higher level nohalos" (I would guess the
main programming issues are basically the same as with implementing
the higher subdivisions for NEDI and ICBI) I'd be happy to count you
among the co-authors of the appropriate paper(s).

If you just end up programming NEDI/ICBI---but don't touch
nohalo---I'd be happy to use your code for our image resizing
comparison suite (which should be on the web fairly soon).

Nicolas Robidoux
Universite Laurentienne/Laurentian University
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Reply via email to