Evaluating many mildly diverging images is part of image development, but as much as possible should not need to be part of the workflow for operators of software like GIMP. Providing many toggles, options and references is a way to botch complicate the user interface visually as well burden the cognitive load of the operator with choices.

The code of the lohalo/nohalo samplers needed revisiting recently (due to hangs/slowdowns which now are resolved) - and as part of that process the choice of a crucial parameter LOHALO_OFFSET0 and NOHALO_OFFSET0 in the respective algorithms deserved revisiting. Test renders of siginificant downscaling producing moire for nearest neighbour and bad values for this parameter can be seen at http://pippin.gimp.org/tmp/samplertest/ the current default is 13; higher values lead to slower processing - for marginally better results.

It is probably possible to introduce some level of automation that increases this value as downscaling is made even more aggressive - but values around the current default seem reasonable. Note that for some input images that do not produce moire, results might seem sharper - but there might be lurking surprises in mini-moire patterns and jaggies, for anything but nearest neighbor resampling antialiasing should be expected for scaling of images.

The actual reason for this email is that I think it might be overkill to have both lohalo and nohalo available as choices, they are related and powerful transformation ellipsis aware methods, maybe it is sufficient to have one go-to high quality resampler instead of expecting the user to make a choice between lohalo and nohalo on a case by case or built up as general preference, and in which case I believe of these two related methods, from Nicolas Robidoux & collaborators, we'd be best off keeping the nohalo method - possibly with an adaptive _OFFSET0 to speed resampling that is primarily interpolatory.

/pippin

On Mon, Oct 23, 2017 at 3:51 PM, Elle Stone wrote:

Agreeing with what you say, I've tried lohalo and never saw any reason to use it instead of nohalo. For several years now nohalo is the only downsizing method that I use.

I see in the git log that some changes have been made recently to nohalo. I haven't used the new version of nohalo, and also haven't added these changes to my "CCE" version of GIMP. The reason I mention this is because even though nohalo (the older version of nohalo) is slow, it produces results that are exceptionally good.

The recent GEGL commit 0b0ecbb67198d6318ed163522e5233ecbc18ff25 mentions slightly sharper results for nohalo: "for sigificant downsampling this might result in sharper/aliased results".

This "sharper/aliased results" doesn't sound like a good thing, at least not for my particular workflow. I don't use a lot of sharpening in my workflow, and I prefer to do any required post-downsizing sharpening by hand, using masks and layers, and using either unsharp mask or high pass sharpening, on an image by image basis.

Would there be the possibility of parameters with the revised nohalo that would allow to replicate the old results?

This is what an adaptively increasing the OFFSET0 constant for significant downscaling in the sources might achieve - do note that what is meant by significant downscaling here is when scaling down to below 1% of original size - even in such scenarios nohalo will already be doing a good job. I believe that even without further enhancement we should use nohalo as the default sampler.

/pippin

On Mon, Oct 23, 2017 at 4:37 PM, Elle Stone wrote:

On 10/23/2017 10:03 AM, Øyvind Kolås wrote:

This is what an adaptively increasing the OFFSET0 constant for significant downscaling in the sources might achieve - do note that what is meant by significant downscaling here is when scaling down to below 1% of original size - even in such scenarios nohalo will already be doing a good job.

OK, that sounds less scary than the commit message!

The gallery has been updated - as all the nohalo versions were through a mistake of mine a rendition of lohalo with a high OFFSET0, the difference between lohalo and nohalo is now more apparent - with the nohalo results in general being crisper than lohalo for such downsampling. Seeing the difference I am less inclined to remove lohalo - even if the smoother appearance of downscaling with lohalo can be achieved manually with nohalo by applying a sufficiently large gaussian-blur before scaling down.

/pippin