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

On Fri, Aug 14, 2020 at 6:19 AM Bob Friesenhahn
<[email protected]> wrote:
>
> On Fri, 14 Aug 2020, Adam Richter wrote:
[...]
> > By the way, ImageMagick and GraphicsMagic gave me different bounding
> > boxes when I used "-fuzz 30%":
> >
> > $ magick convert -fuzz 30% -format "%@\n" 001_bordered.pnm info:-
> > 2409x2837+119+133
> > $ gm convert -fuzz 30% -format "%@" 001_bordered.pnm info:-
> > 2572x3199+22+2
> >
> > I don't know if that matters or if one is right and the other is
> > wrong.  I am guessing that this is some different between
> > GraphicsMagick's
> > FuzzyColorMatch() and ImageMagick.  Anyhow, it is not a problem for
> > me, but I figure I ought to pass along this additional observation
> > in case it is of any interest.
>
> The algorithm for finding the bounding box has likely changed in
> modern ImageMagick.  After 18 years of separation, some differences
> may be expected.  What the ImageMagick project does does not define
> what the GraphicsMagick project does, although we do try to be
> responsive to user demands and do pay attention.  A visual inspection
> of the image is likely required to see what the most correct answer
> likely is.

Hi, Bob.

I am sorry to have taken so long to respond to your previous comments.

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.

Breaking apart my "convert" command into separate steps (border, blur, trim) and
saving the results of each step indicates that although GraphicsMagick
and ImageMagick
produce different results with "-blur", switching those results did
not change the
resulting output geometry from "-trim" for the particular image I was testing.
GraphicsMagic and ImageMagick produced different trim dimensions even when
used on the same input files for the results of "-border" and "-blur".

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.

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.

Adam



>
> > Although the issue is no longer causing me a problem, please feel free
> > to let me know if I can be of assistance in any way if you decide to
> > dig into this issue further now or in the future.
>
> Well, you do appear to be a quite clueful user and given that at the
> moment I appear to be the only significant contributor to
> GraphicsMagick, any feedback or even source patches from you are
> valuable.  This applies to anybody who is able to contribute to the
> project in a way which helps more than it hurts.
>
> 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