Re: [Gimp-developer] improving bicubic interpolation
Von: Sven Neumann <[EMAIL PROTECTED]> > On Sun, 2007-01-28 at 22:04 +0100, [EMAIL PROTECTED] wrote: > > http://bugzilla.gnome.org/show_bug.cgi?id=363775 > > Sorry, but I am unable to follow your way of handling bug reports. If > there's now a new bug that deals with remaining issues in bug #167956, > why is the former not closed then? And why is the new bug not on the 2.4 > milestone? ... and what is the state of the patch(es) attached to bug #167956? Michael -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] improving bicubic interpolation
Hi, On Sun, 2007-01-28 at 22:04 +0100, [EMAIL PROTECTED] wrote: > In fact that's exactly what I am working on. > > If you look at my last post to the bug you linked above you will see I > started a new bug since this one was getting too long, confused and mixing > a number of issues. > http://bugzilla.gnome.org/show_bug.cgi?id=363775 Sorry, but I am unable to follow your way of handling bug reports. If there's now a new bug that deals with remaining issues in bug #167956, why is the former not closed then? And why is the new bug not on the 2.4 milestone? > 2) scale_region_no_resample() calculates offset tables effectively using > (x + 0.5) . This would seem to be aimed at using the midpoint to scale > down but has no meaning to scaling up. It's a nop. Using guint instead of > gint for this data would also be more efficient. Sorry, but guint is never any more efficient than gint and it is likely to introduce bugs that are very hard to find. Please avoid the use of guint by all means. It should only be used when bit-fiddling is involved. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] improving bicubic interpolation
On Sun, 28 Jan 2007 21:05:28 +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > Hi, > > before you start attacking the bicubic interpolation routines, could you > please have a look at the outstanding bug report for Lanczos: > > http://bugzilla.gnome.org/show_bug.cgi?id=167956 > > Would be nice to get this one closed finally. And we can't release 2.4 > as long as it is still open. > > > Sven > > > In fact that's exactly what I am working on. If you look at my last post to the bug you linked above you will see I started a new bug since this one was getting too long, confused and mixing a number of issues. http://bugzilla.gnome.org/show_bug.cgi?id=363775 my last comment in the new bug was that there remains a number of small drifts on linear cubic and lanczos. I see this as all part of the same problem which I am currently trying to track. Even NONE is bahaving badly if you take a close look at it. NONE is the only one not to have -0.5 and it seems to have the largest drift. This has probably gone largely unnoticed since using NONE usually looks crap and no-one took a closer look. I am particularly intrigued by the need for -0.5 fiddle factors on lanczos. My only justifications were: a) it was needed to prevent drift b) it appeared in linear and cubic already , so the problem was not in the lanczos code c) it seemed better to have a fudge factor than an offset in the image until someone can explain why they are there. I am currently climbing the tree trying to see what is happening. There seems to be a number of points to review here and some inconsistencies in the code. Probably mostly very old, well established, small scale errors. Accumulative rounding errors, different origins, and I suspect some small bug that is affecting all these methods. Any comments on the following points from those close to the code may save some time. 1) gimp_item_scale_by_factors() uses new_offset_x = ROUND ... , gimp_item_scale_by_origin() uses straight integer arithmatic ie truncates the offsets. Any reason not to use ROUND all round ? 2) scale_region_no_resample() calculates offset tables effectively using (x + 0.5) . This would seem to be aimed at using the midpoint to scale down but has no meaning to scaling up. It's a nop. Using guint instead of gint for this data would also be more efficient. 3) maybe NONE needs the same mysterious -0.5 as the others until the reason becomes clear. I agree the cubic spline vs cubic kernel issue can take second place to tidying up this lot. gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] improving bicubic interpolation
Hi, before you start attacking the bicubic interpolation routines, could you please have a look at the outstanding bug report for Lanczos: http://bugzilla.gnome.org/show_bug.cgi?id=167956 Would be nice to get this one closed finally. And we can't release 2.4 as long as it is still open. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] improving bicubic interpolation
Many thanks for the offer. Finally Simon was able to come up with a copy of Keys' paper for me but I will keep your offer in mind since I came accross several references to pdfs on IEEE that may also be useful. Thanks to all for the many positive and helpful replies, and especially to Simon for coming up with the goods. Now to see what effect it will have in practice. regards, gg. On Thu, 25 Jan 2007 18:13:57 +0100, Mukund <[EMAIL PROTECTED]> wrote: > Hi Sven and gg, > > Sven Neumann wrote: >> Hi, >> >> On Mon, 2007-01-22 at 10:13 +0100, [EMAIL PROTECTED] wrote: >> >>> All references to Keys' work seem to lead to papers published by IEEE >>> and >>> available on a per article subscription. I assume the charge for one or >>> two articles would be fairly nominal. Would this be a good use of some >>> of >>> the gimp projects donations fund? >> >> That sounds like very reasonable use of the money. Please try to find >> out which papers would be important for your work and how much is being >> charged for them. >> > > I am a member of IEEE Computer Society and will be glad to get and share > the full text PDF of these articles for GIMP development use. Same with > ACM papers. > > > Kind regards, > > Mukund > > ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] improving bicubic interpolation
Hi Sven and gg, Sven Neumann wrote: > Hi, > > On Mon, 2007-01-22 at 10:13 +0100, [EMAIL PROTECTED] wrote: > >> All references to Keys' work seem to lead to papers published by IEEE and >> available on a per article subscription. I assume the charge for one or >> two articles would be fairly nominal. Would this be a good use of some of >> the gimp projects donations fund? > > That sounds like very reasonable use of the money. Please try to find > out which papers would be important for your work and how much is being > charged for them. > I am a member of IEEE Computer Society and will be glad to get and share the full text PDF of these articles for GIMP development use. Same with ACM papers. Kind regards, Mukund -- Banu -- Free software for science, media and graphics http://www.banu.com/ signature.asc Description: OpenPGP digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] improving bicubic interpolation
Gg, Google Scholar only finds one paper by RG Keys on this topic: Cubic Convolution Interpolation for Digital Image Processing RG KEYS IEEE TRANSACTIONS ON ACOUSTICS, SPEECH, AND SIGNAL PROCESSING, VOL. ASSP-29, NO. 6, DECEMBER 1981 I was able to download a pdf of that paper using my institutional access, and I don't think it would be a violation of anything if I send you a personal copy. Would that solve the problem? -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] improving bicubic interpolation
In the USA the papers are almost universal available thought interlibrary loan. The cost of the service is born by the libraries that lend the material. The service is available at least to some degree world wide though I don't know to what extent and if there are charges. Al1 most all deliveries are handled electronically and are usually in your hands in a matter of hours if they aren't delivered to you via email. Gordon S1ven Neumann wrote: > Hi, > > On Mon, 2007-01-22 at 10:13 +0100, [EMAIL PROTECTED] wrote: > > >> All references to Keys' work seem to lead to papers published by IEEE and >> available on a per article subscription. I assume the charge for one or >> two articles would be fairly nominal. Would this be a good use of some of >> the gimp projects donations fund? >> > > That sounds like very reasonable use of the money. Please try to find > out which papers would be important for your work and how much is being > charged for them. > > > Sven > > > ___ > Gimp-developer mailing list > Gimp-developer@lists.XCF.Berkeley.EDU > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > > ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] improving bicubic interpolation
Hi, On Mon, 2007-01-22 at 10:13 +0100, [EMAIL PROTECTED] wrote: > All references to Keys' work seem to lead to papers published by IEEE and > available on a per article subscription. I assume the charge for one or > two articles would be fairly nominal. Would this be a good use of some of > the gimp projects donations fund? That sounds like very reasonable use of the money. Please try to find out which papers would be important for your work and how much is being charged for them. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] improving bicubic interpolation
In my on-going research to reduce the filter artifacts noted in http://bugzilla.gnome.org/show_bug.cgi?id=166130 , I found many references to a promising improvement on the cubic convolution kernel approach I have been using. As noted in the bug report using a convolution kernel entirely removes the somewhat obvious staircasing produced by the current interpolation at the expence of a slight softening of the image. In all the research I have done I have come up constantly to references to work done by R.G. Keys where he uses 6 point spline fitting instead of the usual four, but despite extensive efforts I have not been able to find any reference to the actual piecewise polynomials he derives. Since the way this technique fits into the code is virtually identical to the lanczos implementation a six-point approach would envolve exactly the same calculation effort as lanczos and the larger window and the increased order of convergence would almost certainly improve the quality and precision of the filter. It would seem reasonable to assume this would bring us close to a best of both worlds situation, a clean interpolaton without the softening. http://64.233.183.104/search?q=cache:pcUIULp7cboJ:ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19870013008_1987013008.pdf+fourth-order+convergence+catmull-rom&hl=en&ct=clnk&cd=3&client=opera >> Keys’ cubic is a local, six-point inter- polant whose interpolation function is again given by piecewise cubic polynomials. However, in contrast to PCC, there are no free parameters. The algorithm is fourth order convergent (ref. 8) which is the highest order which can be achieved with cubic polynomials; >> All references to Keys' work seem to lead to papers published by IEEE and available on a per article subscription. I assume the charge for one or two articles would be fairly nominal. Would this be a good use of some of the gimp projects donations fund? If the idea is acceptable I'll look into the details. /gg. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
