1. Useful datums:

A. Why don't the old tools and the new library produce identical chunking?

This is because of an obscure block grouping difference that would have
been too obnoxious to replicate in the new code.

In the old code, each range is broken down into 128K max (uncompressed)
blocks which is the size of its read buffer. It then performs a check to
see if that up-to 128K block would fit in the space remaining in the current
chunk (subblockleft-1024). If not it further reduces the size of this block
to what remains.

The new code does not start checking for a "chunk fit" til it has broken
down the data into 64K max hash blocks. It then uses the same criteria
for fitting, but because it doesn't have that 128K division point that
old imagezip does, the chunking can be slightly different.


2. Useful testing tools:

A. compare a signature with its image (note that you will need a version
   of imagehash with HANDLE_SPLIT_HASH defined):

   imagehash -SX foo.ndz

   If that fails, you can dump the signature file (note that you will
   need a version of imagehash with TERSE_DUMP_OUTPUT defined):

   imagehash -R -o foo.ndz.sig > /tmp/1

   and dump signature info from the image:

   imagehash -R -X foo.ndz > /tmp/2

   and diff them. It could be a case where the HANDLE_SPLIT_HASH hack
   doesn't work.

B. compare two signature files that should be identical:

   imagehash -CR -o foo.ndz.sig > /tmp/1
   imagehash -CR -o Nfoo.ndz.sig > /tmp/2
   diff /tmp/[12]

   Need the -C option so it won't output chunk numbers. The new routines
   and old tools don't chunk data precisely the same.

C. checking the data content of two images that should be identical
   (make sure you have lots of disk space!):

   imageunzip -I foo.ndz - > /tmp/1
   imageunzip -I Nfoo.ndz - > /tmp/2
   cmp /tmp/[12]


