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

On Wed, 9 Sep 2020, Adam Richter wrote:

> On Tue, Sep 8, 2020 at 7:03 AM Bob Friesenhahn
> <[email protected]> wrote:
>
>> Interesting.  I have not updated this function [FuzzyColorMatch] significantly since
>> 2008 when an optimization was added.  The function is used in many
>> (22!) places.
>
> I have attached a patch, but the only test I have run with that patch
> so far is just trying
> to trim one file and comparing results with ImageMagick.  With the
> attached patch,
> the resulting geometry is the same.  I am guessing that the other call
> sites should be
> OK, but I have not taken much of a look at them yet.

I see.  The patch appears to make the results more mathematically 
correct but it may cause issues where people manually adjusted the 
fuzz values until they results appeared as intended without any 
consideration of math.  This is going to require some deliberation.

>> Looking closer, it seems that there is ample opportunity for possible
>> speed-up as well.
>
> You also apparently opened bug #345 in 2016 indicating that -trim 
> could produce negative width results, and it is currently marked as 
> open.  Looking at the code, I was wondering if there were cases 
> where that sort of result was intended.  If not, if the region 
> should never have negative width or negative height, then that might 
> open the door to optimizations that would not need to preserve that 
> presumed bug.

There are so many open bug reports now that I lose track of them. 
Someone named "Don" opened this report.  We should never expect 
negative width/height.  Internally I don't think that we even support 
storing negative values, but we might present a huge number instead, 
and it may overflow into a negative value if assigned to a signed 
integer.

>> Unless the user knows what they are doing (unlikely), the results of
>> the distance vector are not likely to be very useful because they are
>> performed in an inadequate color-space.  In many cases the user can
>> not "fix" FuzzyColorMatch() without breaking something else because it
>> is called deep in the bowels of other algorithms.
>
> I don't know about theories of color spaces, but I will pass along 
> what I noticed from looking at ImageMagick's IsFuzzyEquivalcnePixel 
> function (its version of FuzzyColorMatch), in case that is helpful. 
> That function has some "if" branches for doing other color matching 
> criteria and a comment that mentions "arc distance for hue."  My 
> original guess was that the branch with that comment was being 
> taken, as I thought that the problems matching the colors of the 
> platens on my scanner (to find the edge of a piece of paper) were 
> getting more mismatches because perhaps IM's method was more 
> sensitive to differences in color and less in brightness, and that

With three quantum values (e.g. RGB) a distance vector can be 
computed.  However, with common RGB (e.g. Rec.709) the contribution of 
the three colors to Luma (apparent brightness) is not linear.  For 
example this is the equation for Rec.709 Luma:

   intensity=0.2126*red+0.7152*green+0.0722*blue

The documentation for the -colorspace option says:

"Empirical evidence suggests that distances in color spaces such as 
YUV or YIQ correspond to perceptual color differences more closely 
than do distances in RGB space."

So, this would suggest that if the image was converted to one of these 
more linear colorspaces that the distance vector would be a more 
accurate representation based on what a human sees.  I think that 
"LAB" colorspace would be best for this purpose but GM does not yet 
have direct support for it (it relies on LCMS).

Looking at the GetImageBoundingBox() implementation, I see that it 
does not yet have a special-case for where the image is black/white or 
grayscale.  If the image is known to be grayscale, then the 
implementation can be made to execute many times faster.  If the image 
is colormapped (and especialy if it is also grayscale) then it can 
also be made to execute much faster.

I did some testing and verified that calling FuzzyColorMatch() does 
take the majority of the time in GetImageBoundingBox().

It does not seem that FuzzyColorMatch() can be made much faster given 
that it works with three quantums and is currently called for each 
pixel.  It can be called much less often using a smarter algorithm.

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