Re: [Gegl-developer] Proposition : GeglInterpolator
Nope, the point is that interpolation is wrong when scaling down you as will happen when scaling down using an affine transform or a perspective transform. By transforming the corners of a pixel, one would get an idea about the size needed for the resampling kernel. If you scale a image to 10% of the original size using cubic, you have a situation where the data for each destination pixel is taken from a region of 4x4pixel, whilst it should at least be taken from a region of 10x10pixels, 84% of the image data is thrown away. OK, the handling of scaling down is not yet in the proposition Could we not just add the scale factor to the API ? ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Proposition : GeglInterpolator
On 10/17/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: If you scale a image to 10% of the original size using cubic, you have a situation where the data for each destination pixel is taken from a region of 4x4pixel, whilst it should at least be taken from a region of 10x10pixels, 84% of the image data is thrown away. OK, the handling of scaling down is not yet in the proposition Could we not just add the scale factor to the API ? The scale factor is not enough, if we scale it to 10% horizontally and 70% vertically (or add some kind of rotation as well). A fixed scale factor would no longer be correct. Doing a reverse transform of the corners of the destination pixel would give us all the information we need, and work for perspective transforms as well, hence the method I suggested. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
Re: [Gegl-developer] Re: DAGs make users' eyes cross
On Tue, 2006-10-17 at 17:31 +, Ken Bateman wrote: However, I argue that the spreadsheet model is mentally accessible to a much larger user base, and it does not reduce or limit the sophistication of the underlying image core DAG. Spreadsheets provide an easy learning curve and an obvious data model. I have met many people who lack technical sophistication that can still create and use spreadsheets. Please provide specific examples as to how one would represent image processing operations in a spreadsheet model. Not something abstract, but something concrete. Posit a workflow and represent that workflow as a spreadsheet. It doesn't have to be code (though that would be nice) but it does have to be clear and unambiguous. Also please explain the statement that image processing operations naturally fit into arrays. I'd also point out that LabView (another product that uses a graphical DAG to do operations) is so easy to use that Lego thinks 10 year old can do it (check out Lego Mindstorms NXT). Last I checked no one is adopting the speadsheet model to make things easier for people. -- Daniel ___ Gegl-developer mailing list Gegl-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
