Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!nntp.club.cc.cmu.edu!micro-heart-of-gold.mit.edu!bloom-beacon.mit.edu!panix!not-for-mail
From: john hevelin <bwotte@panix.com>
Newsgroups: comp.sys.mac.system
Subject: Re: Any quick, easy way to compare two images?
Date: Tue, 28 Jan 2014 02:26:56 +0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Lines: 47
Message-ID: <lc74hg$ft6$1@reader1.panix.com>
References: <lbrnpr$q5o$1@dont-email.me> <xwlhy6jn6u.fsf@ethel.the.log> <2ridndio-M0kOnzPnZ2dnUVZ8kmdnZ2d@giganews.com> <2fd2jijlbb.fsf@ethel.the.log> <Lcudnbvj4oa5JXzPnZ2dnUVZ8oOdnZ2d@giganews.com> <161tzyjibp.fsf@ethel.the.log> <5cKdnS2-vfr0cX_PnZ2dnUVZ_oSdnZ2d@giganews.com> <ecfvocdh8s.fsf@ethel.the.log> <r_WdnVO3yP2VQn7PnZ2dnUVZ_uydnZ2d@giganews.com> <6jy523synp.fsf@ethel.the.log> <250120141345247892%nospam@nospam.invalid> <vey523eopt.fsf@ethel.the.log> <250120141630000472%nospam@nospam.invalid> <yxmwijeogq.fsf@ethel.the.log> <2014012515592033890-savageduck1@REMOVESPAMmecom> <lc1opr$h1d$2@dont-email.me> <2014012517510124273-savageduck1@REMOVESPAMmecom> <lc2hj5$loj$2@dont-email.me> <bkkopbFccv0U3@mid.individual.net> <lc3ka4$ft8$1@dont-email.me> <2014012613303278552-savageduck1@REMOVESPAMmecom> <lc44d1$v66$1@dont-email.me> <lc4c75$joi$1@reader1.panix.com> <lc4g82$c2o$2@dont-email.me>
NNTP-Posting-Host: panix1.panix.com
X-Trace: reader1.panix.com 1390876016 16294 166.84.1.1 (28 Jan 2014 02:26:56 GMT)
X-Complaints-To: abuse@panix.com
NNTP-Posting-Date: Tue, 28 Jan 2014 02:26:56 +0000 (UTC)
User-Agent: tin/2.0.0-20110823 ("Ardenistiel") (UNIX) (NetBSD/6.1.2 (i386))
Xref: csiph.com comp.sys.mac.system:55499

Don Bruder <dakidd@sonic.net> wrote:
> In article <lc4c75$joi$1@reader1.panix.com>,
>  john hevelin <bwotte@panix.com> wrote:

> > Don Bruder <dakidd@sonic.net> wrote:
> > 
> > 
> > > For anyone who might give a damn, I've coded a workaround that seems to 
> > > be doing the job just fine. I'll let it keep dumping debug reports for 
> > > another half a day or so, and if it continues to show no problems, call 
> > > it "good enough".
> > 
> > I'm interested in efficient ways to compare files.  I'd be interested
> > in seeing what you've worked up when you're satisfied with it.

> Pretty simple, really - Especially considering the insanity that this 
> thread has spawned. 

> In my "try to grab a new image" routine, I grab the image as "current", 
> then just loop through the first hundred bytes of the last image (saved 
> as "previous" for this purpose) that was considered "new", XORing them 
> against the same bytes in "current". If any of the XORs produce a 
> non-zero, I break out of the loop, replace "previous" with "current" for 
> next time around, and hand "current" back to the caller. If the XORs all 
> come up zero, I drop "current" on the floor, and return nil to the 
> caller to signal "no new image this time around - try again later".

Ok.  You understand this approach will generate false duplicates
and that you will miss frames that you would otherwise have included.

> *VERY* simplistic, obviously won't catch differences beyond the first 
> hundred bytes, and probably has other technically "unforgivable" 
> problems, but so far, hasn't shown me a wrong choice, runs quick, and 
> didn't take much "brain-sweat" to code.

Since your method will erroneously detect false duplicates, your
QA process is failing to detect the errors.  Do you have an
alternative method for verifying your code?  Right now it was quick
to develop, runs fast, and produces the wrong answers.  If the
errors are within the tolerances of your project, that's your call.

I'm curious as to why you seem reluctant to use existing utilities
such as cmp(1) that are readily available under Mac OS X, which
have a development time of zero, produce correct answers, and run
blindingly fast.  I just used cmp(1) to compare two equal 25M files
on my iMac running Tiger:  wall clock time was 0.12 seconds