Basically, this is finishing the program described in http://www.youtube.com/watch?v=H7PM22bA96Q (which is a copy of http://river-valley.tv/better-and-faster-image-resizing-and-resampling). The actual talk started 4 minutes 8 seconds into the video. Putting Jacobian-adaptivity and Lohalo (called Nohalo in the video) into GEGL is done. Adding EWA LanczosSharp (and other things) is what's proposed.

P.S. See Nicolas Robidoux's proposal to improve the GEGL samplers for GIMP below for details.

(Still learning how to use freedomsponsors and the like. I'm new at this so bear with me.)
You may want to have a look at http://www.thepowerbase.com/2012/11/gimp-seeks-crowd-funding-model-for-gegl-components/ and the comments by Alexandre Prokoudine and yours truly.
I will put together a more explicit proposal ASAP so you know exactly what you're buying into.
The goal, in a nutshell, as mentioned in the Gnome Bugzilla entry associated with this kickstarter, is to immediately have GIMP inherit the three cousins of the already built in Lohalo sampler (which is what you get when you select the Lanczos filter with older GEGLized GIMP, and shows up in the tool menu of GIMP 2.9 when you use any operation that changes the geometry of the image like scale, rotate, shear, perspective etc). So, there would be a set of four samplers with the descriptive names LoBlur, LoJaggy, LoHalo and NoHalo, which cleanly handle all operations from upsampling (enlarging) to downsampling (reducing) and everything in between, including perspective.
By and large, the added three are already in ImageMagick. A good amount of programming is needed because GEGL and ImageMagick are structurally extremely different. In addition, I'll take the time to improve the formulas used to compute the filters (even the upsampling part of LoBlur, which will be classical tensor Lanczos 3, currently missing from GEGL) using state of the art research on fast function computation that relies on the Boost C++ library's minimax program.
I'm not interested in forking, and this will be released as soon as ready, like the other improvements I've made to the GEGL library: http://git.gnome.org/browse/gegl/log/?qt=author&q=Nicolas+Robidoux.

Hi @Nicolas

(Still learning how to use freedomsponsors and the like. I'm new at this so bear with me.)

I'm Tony, creator of FreedomSponsors.
Just wanted to let you know that the use you're making of FS is very “correct”.
At least it very much conforms with what I had in mind when I added the “kickstart issue” feature.

That said, it would probably be a good idea to add a comment on the original issue pointing to this page!

I'm very excited about this issue - it broke the record in number of sponsors :-)
This might validate the FreedomSponsors funding model and will also provide feedback that I can use to improve it, specially regarding UX/UI.

Backers: thank you for supporting Free Software and for believing in FreedomSponsors.
If you have any feedback to improve FS, please let me know.

Nicolas Robidoux's proposal to improve the GEGL samplers for GIMP

SUMMARY

Once I (and possibly others) have completed the steps outlined below,
the new high bit depth GIMP will have three additional all purpose
samplers, and operations like resize, rotate and perspective will give
higher quality results and will run faster.

INTRODUCTION

I (Nicolas Robidoux) put out a call for programming work sponsorship
at freedomsponsors, titled “Add other samplers that properly reduce,
downsample and warp images” linked to a Gnome Bugzilla entry

https://bugzilla.gnome.org/show_bug.cgi?id=688892

Below, I justify this call for sponsorship and itemize the
deliverables.

Warning: Even though this is about improving GIMP (the GNU
Image Manipulation Program), the discussion is often quite technical
because it concerns what's under the hood (the GEGL library).

MOTIVATION

GEGL (GEneric Graphics Library) is the new high bit depth compute
engine of GIMP. It will completely replace the classic 8-bit engine in
GIMP 2.10 (the next official release).

GEGL, and consequently bleeding edge GIMP, only has one sampler that
correctly downsamples as well as upsamples: the LoHalo filter. I
created and programmed LoHalo with the help of several students and
collaborators. Unless LoHalo is used, GIMP 2.9's Image and Layer Scale
operations do not do a good job at making images smaller, and the
Perspective tool does not render distant regions properly. (GIMP 2.9
is the current “development” (not for mission critical use) version.)

LoHalo is a high quality sampler. However, as its name suggests, it
focuses on minimizing haloing artifacts. In fact, LoHalo does such a
good job at suppressing haloing that I want to change its name to
NoHalo, the actual name of its key component method (and the name
under which it is found in the VIPS library). However, many users
demand samplers with different properties. For example, it is not a
good substitute for good ol' GIMP Lanczos. Hence the need for
additional GEGL samplers.

(If you have no idea what I'm talking about when I mention “halo” and
other resampling artifacts,

http://www.cambridgeincolour.com/tutorials/image-interpolation.htm
http://www.cambridgeincolour.com/tutorials/image-resize-for-web.htm
http://www.cambridgeincolour.com/tutorials/digital-photo-enlargement.htm

are good introductions to the subject.)

OVERALL DELIVERABLES

My proposal is to add three all-purpose samplers to GEGL and fix
related odds and ends related to GIMP resampling. As a result, four
all-purpose samplers will appear in GIMP menus since the LoHalo
sampler is already there, plus “None” a.k.a. nearest neighbour, which
is terrible but useful and fast:

“NoHalo”, called “LoHalo” in GIMP 2.8 and 2.9, which can be
described as an enhanced (bi)linear resampler. It is discussed 16
minutes and 54 seconds into the YouTube video

http://www.youtube.com/watch?v=H7PM22bA96Q

of a talk I presented at LGM (Libre Graphics Meeting) 2011. The video
is also found at

http://river-valley.tv/better-and-faster-image-resizing-and-resampling

The new “LoHalo”, which can be described as an enhanced
Mitchell-Netravali bicubic resampler.

“LoJaggy”, a rather unique filter described by users of the madVR
video renderer as giving a nice “analog” look to resampling
results. “LoJaggy”, under the name EWA Lanczos, is discussed starting
4 minutes 8 seconds into the LGM 2011 video. EWA LanczosSharp is
without question the best all around resampling filter I've ever
programmed.

“LoBlur”, which can be described as an enhanced Lanczos (3-lobe).

All these new samplers use a mathematical technique called “Jacobian
adaptivity”. Jacobian adaptivity is discussed 20 minutes 23 seconds
into the LGM 2011 video. This technique allows a filter to “adapt” to
diverse geometrical image transformations, to the extent that
different locations within a warped image get their own individualized
handling. The GIMP LoHalo sampler uses Jacobian adaptivity.

As it turns out, general resampling in GEGL, and consequently in GIMP,
could do with more than a bit of love: The code is not as fast as it
should be; scaling, rotating and like transformations are resource
hungry; GIMP could use the GEGL samplers more effectively; and there
probably are bugs (quite a few were fixed recently). So, I will do my
best to fix bugs and enhance tools that use resampling in GEGL and
GIMP as I go along. I actually expect this to be more time consuming
than adding samplers, because it involves tweaking code along the
toolchain that stretches all the way from the GIMP interface to GEGL
buffer management, and requires consultation and coordination with the
other GIMP and GEGL developers.

I omit the technical details of the construction of the new samplers,
except to say that they will be built using pieces discussed in

http://www.imagemagick.org/Usage/filter/nicolas

(document in need of an update). The Gnome Bugzilla entry

https://bugzilla.gnome.org/show_bug.cgi?id=688892

provides ImageMagick commands that you can use to see for yourself
what closely related methods do when resizing images (if you are OK
with using a command line program). If requested, I'll put together
ImageMagick Forum galleries, which will appear in

http://www.wizards-toolkit.org/discourse-server/search.php?search_id=egosearch&sid=4337af8a0f83b9b4fd2a8c642a83c37b

Loosely speaking, one could say that what I'll be doing is port select
resampling methods from ImageMagick to GIMP.

Note that the new samplers will incorporate the results of recent
research by my students and collaborators, and that actually some of
the time I will devote to this project will be used to program and run
long numerical computations that lead to code that will make these
methods run faster and more frugally. The current GIMP LoHalo came out
of such research. (If somebody wants technical details, let me know
and I'll put together a quick overview. I'd rather spend time
programming, however.)

ITEMIZED DELIVERABLES WITH COST AND TIME TO DELIVERY

Most likely, I am not the most competent person to execute Step 6) and
Step 7). I am also quite certain that I am not the only person who
could do Step 1) and Step 2). If somebody else gets these done, I'll
do my best to ensure that they get the loot.

Step 1)

Add more mipmap levels to LoHalo (to be renamed NoHalo) and tweak
their use to make resampling more accurate for very large downsampling
ratios, and make the computation faster for moderate ratios. This
machinery will be reused with the new samplers. Lohalo currently uses
two mipmap (a.k.a. pyramid) levels:

http://git.gnome.org/browse/gegl/tree/gegl/buffer/gegl-sampler-lohalo.c

At least three, and ideally four, mipmap levels are needed to produce
high quality thumbnails from large images.

Cost: 900USD. Approximate time to delivery (once started): two weeks.

Step 2)

Modify GEGL's geometrical transformation code so that resampling is
done, as much as possible, from top to bottom and left to right, in
order to better use GEGL's buffering system and speed up computation.

Cost: 150USD. Time to delivery: a few days.

Step 3)

Program the new GEGL LoHalo and link it to GIMP.

Cost: 550USD. Time to delivery: one and a half weeks.

Step 4)

Program the new GEGL LoJaggy and link it to GIMP.

Cost: 900USD. Time to delivery: three and a half weeks (to give the
needed formula computations time to run).

Step 5)

Program the new GEGL LoBlur and link it to GIMP.

Cost: 900USD. Time to delivery: three and a half weeks.

Step 6)

Enhance GIMP and GEGL so that the Image Scale and Layer Scale
operations use the “CLAMP” (nearest neighbour) abyss policy and the
tools that use samplers use the “NONE” (fade to transparency) abyss
policy. This will remove the border artifacts from the former
operations without introducing “radiating extensions” to the latter.

Cost: 650USD. Time to delivery: two weeks.

Step 7)

It has become clear that the shortest path to better performance with
sampler(s) that give quality results upsampling and downsampling is to
split the pure operations that keep the axes perfectly vertical and
horizontal (like resizing and reflecting left-right, up-down or
through the origin, alone or combined with a translation) from other
transform operations. The main reason is that buffer tiles do not
need “elbow room” at the left and top when resizing, but they need a
lot of elbow room for transformations with a strong rotational
component which is not a pure reflection. In addition, when resizing,
reflecting and translating, the partial SVD (Singular Value
Decomposition) and attendant geometrical computations are a waste:
Everything is “trivially rectangular”. So, I'm adding this “split” and
plugging it into GIMP as another Step. This will require producing two
versions of each sampler, each with its own buffer creation and
access.

Cost: 1000USD. Time to delivery: three weeks.

Step 8)

It has been pointed out by other GEGL developers that I should
document the performance improvements with benchmarks. I don't want to
spend too much time on this (“I sponsored additional functionality and
all I got is this lousy benchmark.”) so I'll keep this simple, but I'm
adding it to the total. (Will split the loot if I get help on this.)

Cost: 500USD. Time to delivery: Two weeks. (I upped the amount because
it's tedious unless you automate, and I don't have time for that. It's also
way up on the unglamourous meter, so if you don't want to pay for that, I
understand.)

Step 9)

It turns out that the current downsampler built into Lohalo (by the
time I get to Step 9, it will have been renamed Nohalo), namely EWA
(Elliptical Weighted Averaging) with the teepee (cone) filter kernel,
has rather weak antialiasing. So, it was within my long term plans to
replace the downsampling part of the method with a slightly smoother
filter, which would be identical to filtering with the bilinear filter
kernel (appropriately “stretched”, as it is in ImageMagick) when
resizing. The issue then becomes: What's to be done when it's not a
resize? I have the answer, something that's never, TTBOMK, been
programmed before: Use parallelograms instead of ellipses, “clamping”
them using the same SVD decomposition that's used in ImageMagick with
the EWA methods. In any case, I decided to add this to the list when
Alexandre Prokoudine was sufficiently displeased with the current
results when reducing text-like stuff just a little bit that he
thought it was a bug. The only long part to doing this is swapping out
ellipses and replacing them with parallelograms, which will also
involved some pen to paper geometry. Everything else is
straightforward. Another nice side effect is that when this is a
resize, the downsampler will be separable, which means that a fast
path downsizer with decent quality can be added, without it
introducing artifacts when warps “go through a local resize or
reflexion”.

Cost: 1450USD. Time to delivery: three weeks.

Grand total: 7000USD.

Total time: Assuming the money keeps flowing, six months after I

get started, since the individual times to delivery are fairly
conservative and long numerical computations can run while I program
something else.

HOW PROGRESS WILL BE DOCUMENTED

Since most of the work involves the GEGL library, you can monitor
progress by visiting

http://git.gnome.org/browse/gegl/log/?qt=author&q=Nicolas+Robidoux

When the GIMP code changes as a result of the new programming
efforts, I'll provide links to the GIMP repo as well.

I'll indicate in a comment at the associated freedomsponsors issue
(right here at

http://www.freedomsponsors.org/core/issue/78/add-other-samplers-that-properly-reduce-downsample-and-warp-images

) when I (or somebody else) gets started on one or other of the
Steps. (I'll get going with Step 1 when enough money has been
pledged.)

When a Step is done, I'll also indicate this with a comment in the
issue tracker, pointing to evidence.

People who hang around the GIMP IRC channel

irc://irc.gimp.org/#gimp

are likely to know something about whether I'm making progress.

Thank you for giving such a detailed explanation.

I opened a ticket on FreedomSponsors issue tracker that might have an impact on this issue:
Make unfinished issues payable

Backers: can I get some opinions about it?

Re: paying already at the first step - no problem with me.

Tony: The following comment is not about my GIMP/GEGL proposal, it's really about freedomsponsors:
If you allow sponsors to pay whenever they want (provided the workers are willing to receive money), freedomsponsors becomes something which can be used like kickstarter.com, but also like flattr.com: The payments can come before, during and even after the work is done, and would-be sponsors are in control.
This is the great advantage of an “honor system”: Without enforcement barriers, comes flexibility.
(Workers need to have a way of indicating whether they are accepting payments for a particular issue. I won't until I'm committed to finishing a step within the given time frame.)

Progress report

Since the pledges appear to have hit a ceiling, I decided to get started on Step 2) because it's cheap.

Summary: Step 2) is half done: Except for triple checking, I'm done with implementing the “scan from left to right and top to bottom in input space” for the affine transform. The perspective transform tweaking is still to be done (as well as putting in code comments that explain the logic of the code changes).

Step 2) is based on the following rule of thumb: In a demand-driven system, the code should be structured based on data-driven considerations. (This rule of thumb is probably wrong half the time, but programming is a lot like baseball: Hitting the ball half the time is good enough because we get three swings.)

Since it is a performance improvement and some of the GEGL devs like benchmarks, here are some.

Stop reading if you don't care about boring technical stuff. What follows is mostly for the benefit of other GEGL and GIMP developers.

The benchmarks compare:

From: Commit fa80fb559b66ab80f5e6f63edb621e642f006862 which is the last GEGL commit before I jumped back into the fray: http://git.gnome.org/browse/gegl/commit/?id=fa80fb559b66ab80f5e6f63edb621e642f006862

To: Commit a4582dac5594fbfac7ba42449edfd547397f8603 which is the last one I've done: http://git.gnome.org/browse/gegl/commit/?id=a4582dac5594fbfac7ba42449edfd547397f8603

Fine print: GEGL's functionality has changed since Massimo Valentini made me aware that there were alignment issues to be dealt with. Now, GEGL resampling “plays nice” with GIMP. I also took out the “fast path” reflect code because it gave incorrect answers and appeared to need an awful lot of love given the (small, IMHO) likely benefit. This is quick and dirty benchmarking: No time to produce something comprehensive and fully conclusive. However, I did my best to do them “fairly”: I'm using the same delegate libraries for both versions of GEGL, and of course I'm doing them in identical runtime conditions. The code was not only improved by yours truly between the two commits. Massimo, in particular, provided some good stuff. This being said, most of the changes to transform-core and the sampler code between the two commits were either done by me or reviewed by me.

First, tests done with relevant drivers distributed in gegl/tests/composition. They are run with time gegl -i {name of the xml file} -o junk.png. I report total (real) time. Consequently, the reported times includes loading images and converting the final result to png, as well as other operations my contributions have nothing to do with, including hard drive I/O. This being said, the following tests from the GEGL library's self-test collection are the ones that “pass through” the changes I've made. (This is most of them.)

P.S. In parenthesized italics, I added the timings as of a later commit, namely http://git.gnome.org/browse/gegl/commit/?id=64b3969e420568e58b233f7f3df75376b7e3726b.

• affine-with-negative.xml: from 3.4s to .70s (to .69s)
• clones.xml: from 3.3s to 3.3s (to 3.1s)
• composite-transform.xml: from 1.2s to 1.2s (to .92s)
• reflect.xml: from .25s to .46s (to .39s)
• reflect2.xml: from .39s to .46s (to .39s)
• rgbe-save.xml: from 1.3s to 1.3s (to 1.2s)
• rgb-params.xml: from .20s to .20s (to .20s)
• rotate.xml: from .68s to .70s (to .70s)
• simple-scale.xml: from .32s to .35s (to .32s)
• transform.xml: from 1.1s to 1.1s (to .95s)

The big picture is that there is no significant change unless the xml file involves a geometrical transformation that “flips” things. (If you get the drift of what this “left to right and top to bottom in input space” is about, this should not surprise you.) The affine-with-negative.xml test is much much faster (it only takes 21% of the time it used to take); affine-with-negative.xml flips things twice. On the other hand, reflect.xml takes 84% more time; this is because the reflect fast paths were removed… because they gave incorrect results in some circumstances. I am quite pleased to report that reflect2.xml “only” takes 18% more time than with the old fast (but sometimes incorrect) path.

Except for affine-with-negative.xml, the above code does not deal with large images (because the tests are distributed with the library, they can't be “big”). So, let's add two such tests. The xml driver code is at the end of this post.

For both tests, I'll use the “famous” (among a certain crowd of resampling connoisseurs) Wikipedia “fly” image by JJ Harrison: http://upload.wikimedia.org/wikipedia/commons/8/85/Calliphora_sp_Portrait.jpg, a.k.a. the moire fly trap.

Large image rotation test Rotate by -138 degrees:

• from 260s to 69s (to 77s)

Large image downsampling test (with the current LoHalo) Reduce to 13% of the size in both directions:

• from 10s to 12s (to 10s)

Again, when the transformation does not “flip”, the runtime doesn't change much (although 20% more time to downsample is something I'll have to keep an eye on even if it's justified by the functionality change). But when there is a “flip”, the old GEGL flops: rotating the large image a lot used to take almost 4 times longer.

(Additional fine print: Apparently, there is something going on with the way gegl calls the babl library (in charge of colorspace conversions) right now. Timings may go down a lot when it's fixed. Also, png is a pretty slow format to save to and load from; the reason I'm mentioning this is that if the total time needed to load, rotate and save is divided by four, the time needed for the rotation itself is probably reduced by significantly more.)

Here is the xml code for the “large image” operations:

Rotation

<?xml version='1.0' encoding='UTF-8'?>
<gegl>
<node operation='gegl:rotate' degrees='-138.0'> </node>
<node operation='gegl:load'>
<params>
<param name='path'>Calliphora_sp_Portrait.jpg</param>
</params>
</node>
</gegl>

Downscaling

<?xml version='1.0' encoding='UTF-8'?>
<gegl>
<node operation='gegl:scale'>
<params>
<param name='filter'>lohalo</param>
<param name='x'>.13</param>
<param name='y'>.13</param>
</params>
</node>
<node operation='gegl:load'>
<params>
<param name='path'>Calliphora_sp_Portrait.jpg</param>
</params>
</node>
</gegl>

P.S I had stupidly increased the almost never needed elbow room in a key function (gegl-sampler.c), instead of reducing it. After doing what I intended, timings are basically never worse with the new code, except when fast path reflects used to matter, and they are sometimes much better.

Of course, this round of benchmarking revealed a bug I did not know about: The downscaling test shows that one of the corners is not handled correctly by exactly one pixel. The corner at which there is a “glitch” changes betwen the GEGL version that comes before my recent fixes, and the one that comes after: it moves from bottom left to bottom right!
I suspect floating point disaster: http://ta.twi.tudelft.nl/users/vuik/wi211/disasters.html.

P.S. My most recent “Step 2)” improvements fixed the bug.

There's a new blog post about this. Nice :-)
http://libregraphicsworld.org/blog/entry/advanced-samplers-for-gegl-to-be-crowdfunded

(just donated)

I believe the layout of this site is terribly hard to read - going to the linked bug tells me to come back here to see the list of deliverables, buried half way down amongst comments.

On a reasonably widescreen monitor most comments don't run full width and just waste space. Reading giant lists of comments to extract key information about deliverables is kinda crazy too.

How about a 2 column layout for the top half of the page, followed by comments beneath. You should also highlight comments by the issue creator/programmer more clearly.

[ dontate / totals    ]
| desc.    | sponsors |
|---------------------|
|                     |
| comments            |
|_____________________|

(oh, and the markdown/text editor is not using a monospace font, so drawing the above ascii art was rage-inducing)

Great feedback John, thanks!
You're right, this page needs some serious UX/UI improvements.
Just opened a new issue - https://github.com/freedomsponsors/www.freedomsponsors.org/issues/95
I'm not a great webdesigner (obviously :-)), so any help with it is highly appreciated :-)

All right!

• 1 - comments textarea uses a monospaced font
• 2 - There's a preview area that lets you see what it will look like after markdown.
• 3 - Layout is still “terribly hard to read” :-) Note: If anyone wants to give me a hand with 3 - don't even need to make a pull request, just send me a prettier modified html file and I'll plug it in!

Will deliver Step 1) and 2) ASAP.

… and Step 3).
Sincere thanks, to all of you, for your pledges.

Unless bugs are found, Step 2) is finished. Now I need to go back and finish Step 1) before moving on to Step 3).

Nicolas,
You can now start to accept payments for this issue.
The accept payments flag will be available when you begin working on this issue.
Since you are already working on it, you'll need to click the abort work button and then click on Work on this issue again.

Learn more: http://blog.freedomsponsors.org/new-rule-now-you-can-pay-for-unfinished-issues/

Aborting as instructed by Tony so that I can use the brand new freedomsponsors feature that allows money to flow in before the work is completed. Will immediately “resume work”.

Step 2) is finished, Step 1) is moving, there are enough pledges to make it to Step 3), so it's time to accept money.

Pressed “Pay” button -> yes ->confirm, then see “internal server error” on this address http://www.freedomsponsors.org/core/offer/pay/submit

Got the error log. Sorry about that. fixing right away.

Tony: Do I need to push Resolve Issue to enter my PayPal account number?
User XVilka is trying to pay and hitting a wall.

Nicolas: all you have to do to receive payments is to have your paypal email set accordingly in the your user profile.

Okay, I had introduced a silly bug when writing the new feature. It should be okay now.
XVilka, can you please try again?

Tony: I just want to make sure: With your new system, I do not need to press Resolve issue to start receiving money. Correct? (Really, it's not resolved, it's “In progress”.)

Thank you all for your patience: You are helping stuff get off the ground at multiple levels!

Nicolas,

With your new system, I do not need to press Resolve issue to start receiving money. Correct? (Really, it's not resolved, it's “In progress”.)

CORRECT. No need to push “resolve”!

XVilka scores!
Thank you.

Few notes about payment process:
1) Please, use English interface for PayPal login (while we're all on mostly English site)
2) Please, mention proper amount of fee at start, when you press 'Sponsor this issue'

I'm already received a payment confirmation email, so I think this settles it.
It's working, now all sponsors can start paying, if desired (phew!).
Everyone, sorry again about this hiccup!

XVilka,

1) Please, use English interface for PayPal login (while we're all on mostly English site)

What language did paypal login was shown to you?

2) Please, mention proper amount of fee at start, when you press 'Sponsor this issue'

Will do, thanks!

Once in a while I write research papers. In these, I normally thank all the funding agencies that supported the work. I don't see why people's own hard earned cash (as if tax dollars is not) should not be acknowledged as well.
If you would like to be thus acknowledged, let me know somehow, for example by emailing me your first initial and last name, or attaching it to pledge comments. “I would like to be acknowledged as J. Doe.” is enough for me to get the drift. (I will only acknowledge real names.)

TonyLampada,

What language did paypal login was shown to you?

Spanish probably, as did I

TonyLampada: it was shown in Portuguese, don't know why.

Galaxy, XVilka,

Thanks, I'll investigate that.

Paid! Good Luck Nicolas Robidoux!

About freedomsponsors site, is very bad.
Does not show a clear design value ​​(amount already paid, the total project, as yet to collect…)

Could appear in the page title.
I hope this is fixed very quickly.

Mystique, thank you for your feedback.
You're absolutely right, there's a lot of room for improvement!
Rest assured: we're working on it!
Cheers

Nicolas, you can credit me as P. Horger.

I would like to pay, but Paypal seems to be in portuguese. Could you please fix this, so it's in english? I don't use Paypal near enough to want to navigate it in a language I don't understand.

Sincerely
Trine Løcke

I have just paid my part :-)

The PayPal GUI is still in portuguese (please, fix it as soon as possible in order to have it in English)…

Luckilly, I know a bit of Spanish (and Portuguese). Therefore, I have tried to use this skill to type everything correctly on PayPal :-)

GOOD LUCK to Nicolas Robidoux for his project!
Judging by his commits on GEGL (http://git.gnome.org/browse/gegl/log/) it really looks like he is doing a wonderful job ;-)

Best regards,

Silvio Grosso

I see not only that, but you raised your offer from US$ 400 to US$ 560 before paying.
You just broke a new record on FreedomSponsors :o !

Luckilly, I know a bit of Spanish (and Portuguese). Therefore, I have tried to use this skill to type everything correctly on PayPal :-)

Sorry about that, I'm still figuring out how to fix it!

Progress report:
Steps 1) and 2) are done.
Step 3) will have to wait: So far, most of my time has been spent fixing bugs in the GIMP systems that my deliverables plug into, and a doozie was pointed out to me by Mitch Natterer (GIMP's lead dev) yesterday, so it looks like I'll be in bug fix mode (as opposed to development, as if there is a difference) for a while.
No point plugging shiny new things into something broken.

Hi Nicolas,

Nicolas Robidoux wrote:

so it looks like I'll be in bug fix mode (as opposed to development, as if there is a difference) for a while.
No point plugging shiny new things into something broken.

THANKS a lot indeed for this last report :-)

Unfortunately, as you know, the Gimp(and Gegl) team has always been understaffed (compared to the many features to work with).

Thanks to your project on Gegl, I am confident it will be possible to fix many bugs.

Keep your chin up :-)

Best regards,

Silvio Grosso

Silvio:
You are welcome.
And you are thanked.

Quick update regarding paypal in portuguese. I'm still having a hard time with it. I'm afraid it's a bug in paypal.
If anyone wants to follow up on it, please see:
https://groups.google.com/forum/?hl=en&fromgroups=#!topic/freedomsponsors/H2jWipymh40

Tony:
It's OK, only the login screen is in Portuguese and none of my safety Firefox add-ons warned me from the connection, so it's just a minor thing I believe :)

The doozie is now fixed. (Turns out it was self-inflicted.)
Step 3) is next.

The issue with Paypal's login page in portuguese is now fixed.

Please note that payment experience has changed a little bit. Instead of opening paypal inside an iframe, the user is redirected to Paypal's website ( in english ) and then back to FreedomSponsors after payment is complete.

Another bout of optimizing for speed.
Samplers now use rectangular tiles instead of square ones. This makes GIMP usage more bearable, and also downsampling much faster: The downsampling of the large image benchmarked above takes less than half the time now.

@Thomboy, you have registered yourself as a worker for this issue (I believe you did it by mistake, right?).
To fix this, just click the red “Abort work” button in the top of this page.

BTW: So far, I've spent about 4 hours fixing bugs and tweaking performance and interaction with GIMP for every hour I spent on Steps 1-3. This is partly why Step 3) is not moving fast: I want a solid platform before I add new stuff.

Thanks for all the work you have been doing on the issue Nicolas,

So far the work looks very promising, and I am looking forward to trying it out when I get my build environment for GIMP set up. I feel that my money is well used, even if you use it towards time fixing bugs.

-Sonic

@Tony, the one thing that has been bugging me while I have been following this issue, is the comments are so wide. I think it would improve the readability of the comments if you were to reduce it by about a third or slightly less. Currently they rarely take up the whole width of the page, which means there is significantly more horizontal space per single line than is needed. Having less horizontal travel for the eye while reading makes reading more efficient, faster, and can be less stressful.

-Sonic

Thank you Sonic.
GIMP transform and scale tools running bleeding edge GEGL give a completely different user experience, and they are now suitable for production work, which IMHO was not the case two months, or even one week, ago.

@Sonic, thanks for the feedback. The whole layout of this page is being re-thinked by an actual webdesigner (which obviously I'm not) - so you'll only have to bear with this lame design for a little longer.

Tony:
Another suggestion about freedomsponsors, that takes into account that there is no enforcement mechanism: It's based on trust.
Some users are not comfortable making a pledge in USD when their own currency is different (and is not Brazilian Reals either), given that the combined fee + conversion rate system provided by PayPal is not as transparently obvious as one would wish. Let alone that their currency can crash.
What I would suggest is that you make clear that pledges in USD are understood as being approximate, and that no one will get mad if the amount actually paid is significantly different as a result of fluctuating exchange rates and/or inaccurately ballparked fees.
Ideally, a user should be able to pledge in whatever currency, and freedomsponsors would take care of showing an estimated payment, grabbing exchange rates from some public database and guestimating fees. But I realize this is more than a bit of work at your end. For this reason, I suggest a posted statement to the effect that the gentleman/gentlewoman agreement is that the eventual payment correspond approximately to the pledge, as stated in USD, but that “approximately” will be understood by all to be somewhat loose.

The spirit of my last comment:
Life is too short to worry about exchange rates and fees, and I would hope that anyone accepting money for FLOSS work through freedomsponsors is not there to count pennies or centimes or …

There may be one additional advantage to allowing people to pledge in the currency of their choice, indicating an approximated value in USD, besides that this way makes it easier for sponsors to know what they are putting themselves on the hook for:

Right now, I would guess that PayPal's apparently somewhat unfriendly exchange rates are applied twice if both the sponsor and the worker do not live in USD (and none of them does “business” in USD).

By allowing pledges to be made in whatever currency, the exchange would be performed by PayPal at most once (at the receiving end). As a result, sponsors from outside the US would pay less fees, with the consequence that the same amount of money received by the worker (and freedomsponsors) would cost less to a sponsor.

An unarguably good thing.

Another thing RE: the site's layout: On the main freedomsponsors.org, you show both the total for the paid pledges (in green), and the unpaid ones (in orange). It would be nice if you showed this information on this page as well.

(Not about freedomsponsors.)
After some attempts at getting something significantly better, and careful comparisons with reasonable substitutes, I've decided that the upsampler part of the new Lohalo (Step 3) will be sigmoidized tensor Mitchell-Netravali, not sigmoidized EWA Robidoux (or another method). Linear light EWA Robidoux is still “on” as downsampler.
Should run faster too.

I will be putting funding acknowledgements not only in eventual academic articles (if any), but also in source code comments. If you have informed me that you'd like to be acknowledged in articles, I'll assume you'd like to be acknowledged in source code comments as well. Again: A short note by email (nicolas.robidoux@gmail.com) or right here, informing me of your real first initial and last name (I won't acknowledge aliases) and wish for public acknowledgement (see the note on this topic above) is all that's needed.
Note: If a publisher/code reviewer gets in my way on this, I won't fight them. But I don't expect that.

Except for triple checking, Step 3) is done: There are now two filters that downsample well in the GIMP menus: Lohalo and Nohalo. (Nohalo is the old Lohalo, Lohalo is something new.)

Tony: Another bug: When an offer is paid, it can still expire.

The new GIMP samplers NoHalo and the completely redone LoHalo (and the upcoming LoBlur and LoJaggy) are discussed here: http://www.gimpusers.com/tutorials/whats-new-in-gimp-2-10

I haven't figured the PayPal stuff on my side yet, but I made a blog post about the campaign: http://shnatsel.blogspot.ru/2013/01/gimp-is-crowdsourcing-advanced-math.html

Please correct me if I got anything wrong.

My blog is not much of a popular place, but the post might be useful as an up-to-date overview of the campaign, so it might be a good idea to link to it when convincing someone to chip in :)

Thank you Sergey: Nice write up.

Tony: Another bug: When an offer is paid, it can still expire.

Fixed.
Thanks Nicolas!

About freedomsponsors site, is very bad.
Does not show a clear design value ​​(amount already paid, the total project, as yet to collect…)

Hi everyone, I made a few changes in the website design.
I hope it's a little more bearable now.
It will be much better when I have some help from a real webdesigner (working on it)

Please keep sending feedback.

@TonyLampada I like the new look, but now sending payments is broken for me, and I'm wondering if that's cause/effect relationship.

I get as far as being able to hit the “confirm” button which should take me to Paypal, but instead it says “internal server error.” I've got someone waiting for payment right now, so pardon me if I'm being spammy about this problem.

Trying to pay $20.62 on the following issue so that FS's fee doesn't cut into payment:

http://www.freedomsponsors.org/core/issue/165/fix-broken-builds-in-python-25-31-and-33

I'm incrementally preparing the FS to support Bitcoin offers, so the problem you experienced was a buggy side effect of it.

Sorry about that, problem is solved now.

Hey Tony, Just thought I should point out that the +1 button for G+ is either overlapping with the Facebook button, or is set without the counter or any margin to one side of it.

Busy with other things (including pushing a Masters student through). Back to the saddle soon. Stay tuned.

Because I expect to start full time work within two months or so, Steps 4) and 5) are very likely to be the last of my contributions. At this point, I am not 100% sure I'll get them done.

Maybe I should not be, but I'm not hot on bitcoin.
Tony:
Ideally, I think that “workers” should have some way of indicating which currency(ies) they accept (besides messages like this).

@NicolasRobidoux I'm very hot on bitcoin, but don't feel it's properly useful on FS yet, because it's too separate. You can't pledge $100 worth of bitcoins, or any other currency lock, which becomes very important when dealing with a currency that's still highly variable in price. It's also not at all seamless to convert between currencies, so both people have to deal in bitcoin for the transaction to work (honestly, Paypal has the exact same problem, it's just less obnoxious in practice because more people already have Paypal).

A proposed solution

People can pledge in whatever currency they want. Dollars, euros, whatever - including bitcoins. The workers set what currency they want to be paid in. FS should display the total pledges in the worker's choice of currency, based on exchange rates, with a more detailed breakdown on the issue page.

When a pledger pays for the ticket, they should be able to pay via any currency they want. For example, pledging $20 should not lock me down in how I pay it. I'm promising $20 worth of something. It's at payment time that I can decide to pay with bitcoins, or euros, but it'll be dollars by default since that's how I pledged it. It's all being converted to the worker's currency of choice anyways (where necessary, dollar-to-dollar exchanges need no conversion, etc.).

It's a bit more work, but also makes a bit more sense. I'd love to be able to pay all my tickets with bitcoins, without having to wait on workers to adopt it, or worrying about the current rapid inflation of BTC. It also makes things saner and less special-case-y for state-sponsored currencies like the Yen, as well.

http://www.businessweek.com/articles/2013-03-28/bitcoin-may-be-the-global-economys-last-safe-haven

I'd still rather pass on bitcoins.