Re: How do I get the offset result from "-trim"?

Hi, Bob.

I have found the "-trim -fuzz ..." discrepancy between ImageMagick and
GraphicsMagick.

I suspect that this was a change that someone put into ImageMagic, and
I recommend you follow this one.  In particular, in color.c, in
FuzzyColorMatch(), I recommend that you multiply fuzz_squared by 3.0,
which ImageMagick does.  Basically, fuzz is supposed to be a value
between 0 and 1 (0% and 100% on the command line), but, if you imagine
pixel intensities being between 0.0 and 1.0, the distance between rgb
pixel (0,0,0) and (1,1,1) is not 1; it is the square root of the 3.
At some point, someone put the equivalent change into ImageMagick, in
its file MagickCore/pixel.c in IsFuzzyEquivalencePixelInfo() at line
6118.  "git blame" indicates that that line was added on July 1, 2011,
but it is older, because that commit appears to have just moved that
code to its current location (among many other changes).

If you would prefer I generate a proposed patch and email it to you
(or submit it my whatever other mechanism you prefer, such a merge
request, etc.), please just let me know.  I am happy to do so.

If you do not want to make this change (considering that it does
change functionality), I can work around it by multiplying the fuzz
values that I pass to GraphicsMagick by the square root of 3.

I determined this with debug messages and experimentally trying my
proposed change in GraphicsMagick and trying a couple of files.  I
expect to try it out more much later today and generate a patch then,
at least if you tell me that that would help you evaluate or integrate
this change.  However, I probably will not be able to work on this
further or respond much until tonight (that is, around 19 hours from
now).

Thanks for all of your guidance on this and pointers to other relevant
resources in this and other email threads, and, of course, as always,
thanks for maintaining GraphicsMagick.

Adam

On Mon, Aug 24, 2020 at 6:55 AM Bob Friesenhahn
<[email protected]> wrote:
>
> On Sun, 23 Aug 2020, Adam Richter wrote:
> >
> > GraphicsMagic's FuzzyColorMatch() appears to correspond to ImageMagick's
> > IsFuzzyEquivalencePixelInfo() in pixel.c.  Both variants appear to compute
> > the sum of the squares of the differences of the pixel color channels
> > and compare
> > that difference to the "fuzz" factor squared.
>
> It is a distance vector computation.
>
> > By the way, looking at the comparisons done for trim, it does make me think
> > about whether the code could be changed a bit to make "gcc -ftree-vectorize"
> > more able to optimize it, perhaps without many source code changes.  For
> > example, even though FuzzyColorMatch is in a separate .c file, I am
> > wondering if the .so file can be build with link time optimization, and if
> > that might suffice to gcc to try to inline it and then have "-free-vectorize"
> > optimize it.  I suspect that the short-circuit optimizations in FuzzyColorMatch
> > (and IsFuzzyEquivalancePixelInfo in ImageMagick) might interfere.
> > Also, I wonder if there might be an opportunity for parallelization in trimming
> > the top and bottom borders and then likewise for left and right.  Anyhow, i just
> > figure I might as well mention the idea.  I might experiment with that after
> > I track down this "-trim" discrepancy.
>
> Achieving automatic vectorization often seems difficult.  I usually
> see program size benefits from link time optimization, and less in the
> way of performance improvement.  It seems that GCC 10 needs -O3 to
> achieve some optimizations which were standard with -O2 with earlier
> releases.
>
> > Anyhow, as always, thanks for making and maintaining ImageMagick.  I don't
> > know why it is so much faster that ImageMagick for some operations that I
> > use, but I certainly appreciate whatever you did to make it that way.
>
> Much of the speed-up is due to de-obfusticating the algorithms so the
> compiler can make sense of them.
>
> I am sure that quite a lot more speed-up of some algorithms is
> possible.
>
> Bob
> --
> Bob Friesenhahn
> [email protected], http://www.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
> Public Key,     http://www.simplesystems.org/users/bfriesen/public-key.txt
>
>
> _______________________________________________
> Graphicsmagick-help mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/graphicsmagick-help