[prev in list] [next in list] [prev in thread] [next in thread] 

List:       graphicsmagick-help
Subject:    Re: [GM-help] How do I get the offset result from "-trim"?
From:       Bob Friesenhahn <bfriesen () simple ! dallas ! tx ! us>
Date:       2020-08-24 13:55:13
Message-ID: alpine.GSO.2.20.2008240847120.9988 () scrappy ! simplesystems ! org
[Download RAW message or body]

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
bfriesen@simple.dallas.tx.us, 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
Graphicsmagick-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/graphicsmagick-help
[prev in list] [next in list] [prev in thread] [next in thread]