BrianP has asked for the wisdom of the Perl Monks concerning the following question:

What is the best way to hash the number of unique colors in a 219MB, uint48, raw RGB file?

DON'T!

What is the single most significant number characterizing the quality of a camera RAW image?
The number (or percentage) of unique colors contained in the image has to be THEE NUMBER!

At each step in the processing, quickly checking unique color count can tell you if
whatever you just did damaged your image. This number is indispensable for comparing
different color spaces or different raw processors or before and after optimizations.

Hashing in a domain with 281,474,976,710,656 possible combinations is Quixotic and
catastrophically inefficient. About 24 seconds was the best time with hashes.

Sometimes, there is no better solution than brute force.
Here is the Monster Truck Counting Solution:

&sysread_uint48($RGB, \@rgbz); # Store RGB in uint64, RGBZ array &RADIX_SORT(\@rgbz); # Sort by digits! $std=$rgbz[0]; # Make first uint64 the STanDard $unique=1; # First one is Always Unique! for($ii=1; $ii < $num_pix; $ii++) { next if($rgbz[$ii] == $std); # Same Old value as last time! $unique++; # New value, Increment Unique $std=$rgbz[$ii]; # Make new THIS the STD } printf("%d distinct values\n", $unique);
I:\exp\raw>cdrc pf-2015.0531-249465.pprgb.7360x4912.raw CDRC: 27645898 distinct RGBs = 76.471% in 0.946 sec I:\exp\raw>cdrc pf-2015.0531-249465.pprgb.7360x4912.raw -d CDRC: Read 216.913920MB, 36.2MP in 73 msec->2964 MB/s, CPU@3.421GHz CDRC: 36.152320M MemCpy in 67 msec RS: R_Sort-> 775 ms, C_Unique-> 32 ms, total-> 808 ms CDRC: 27645898 distinct RGBs = 76.471% in 0.950 sec

Let the Radix Sort do all of the heavy lifting.

Here is the hash way implemented by PerlMagick:

Running C:\bin\bb2.pl Sun Dec 13 16:30:19 2015 Unique colors=27.645898M = 76.471% <<< EXACT! SE: Sum of Event Times = 6.789 min, now-init = 6.78937 min ETime=239.024 ms = 0.059%, 1 Hits, Event 'PerlMagic Read Raw File' ETime= 6.785 min = 99.941%, 1 Hits, Event 'Quantize' 99.94% -> Quantize 0.06% -> PerlMagic Read Raw File Elapsed C:\bin\bb2.pl time = 6.789 min # Here is the hash way implemented by ImageMagick Bone-Nary[*]: Running C:\bin\bb.pl Sun Dec 13 15:19:29 2015; Conv convert.exe -size 7360x4912 -depth 16 \ RGB:i:/exp/raw/pf-2015.0531-249465.pprgb.7360x4912.raw \ -unique-colors \ i:/exp/raw/pf-2015.0531-249465.pprgb.7360x4912.raw.tif -> size=165875652 Elapsed C:\bin\bb.pl time = 6.936 min I:\exp\raw>mult 165875652 /27645898 6.0000 << Very close agreement on Unique Count I:\exp\raw>mult 6.936 60 /0.946 439.915433
946 MilliSeconds makes this analysis affordable.
# ============================================================= sub unique_colors_perl() { use Image::Magick; # my($debug, $raw, $xres, $yres, $xysize, $unique, $xysize, %e2at); $debug=0; %e2at = (); $raw='i:/exp/raw/pf-2015.0531-249465.pprgb.7360x4912.raw'; &time_event('init', \%e2at, $debug*0); # Initialize timing &time_event('PerlMagic Read Raw File', \%e2at, $debug*0); ($xres, $yres)=&fname_to_xyres($raw, $debug); $xysize=$xres . "x$yres"; # 7360x4912 # Create a new rgb48 with just the right size $im=Image::Magick->new(size=>"$xysize", type=>'TrueColor',\ depth=>16); $err=$im->Read(filename=>"RGB:$raw"); warn $err if $err; &time_event('Quantize', \%e2at, $debug*0); ($unique) = $im->Get('colors'); printf("Unique colors=%.6fM = %6.3f%%\n", $unique/1E6, $unique/(7360*4912)); &time_event('term', \%e2at, $debug*0); # Finalize timing &show_event(\%e2at, $debug*0); # Event timing } # End Unique_Colors_Perl(). NOTE: Bone-Nary: Special build for BoneHeads who can't \ make their own! :)

B

Replies are listed 'Best First'.
Re: What is the Best Way to find Unique UINT48 RGB Colors?
by oiskuu (Hermit) on Jan 06, 2016 at 22:49 UTC

    Presumably, this is a continuation of the older thread.

    I had an _epi32 mergesort implemented from earlier time (*), and so repurposed it for the given task. No doubt a parallel version would scale rather nicely, too, though this I haven't tried. The 7360x4912 pixels of sciurine menace obtained via dcraw.

    $ perf stat perl rgb48.pl squirrl.dat 
    [1452115604.189627] sort_and_uniq:
    [         0.294368] first binning
    [         0.250713] second binning
    [         0.352289] merge and count
    squirrl.dat == 35556508
    
     Performance counter stats for 'perl rgb48.pl squirrl.dat':
    
            937.769123 task-clock                #    1.000 CPUs utilized          
                    13 context-switches          #    0.014 K/sec                  
                     0 cpu-migrations            #    0.000 K/sec                  
                 55529 page-faults               #    0.059 M/sec                  
            2775248733 cycles                    #    2.959 GHz                    
            1375100650 stalled-cycles-frontend   #   49.55% frontend cycles idle   
             588508119 stalled-cycles-backend    #   21.21% backend  cycles idle   
            3397637328 instructions              #    1.22  insns per cycle        
                                                 #    0.40  stalled cycles per insn
             310595954 branches                  #  331.207 M/sec                  
               9170806 branch-misses             #    2.95% of all branches        
    
           0.937321108 seconds time elapsed
    
    Note, this is Lynnfield CPU without avx. Same test in a timethis loop:
    timethis 10:  8 wallclock secs ( 8.33 usr +  0.00 sys =  8.33 CPU) @  1.20/s (n=10)
    

    There are other optimized sort implementations out there. Intel IPP (Integrated Performance Primitives) has the following routines, among myriad others

    IppStatus IppsSortAscend_32s_I(Ipp32s* pSrcDst, int len);
    IppStatus IppsSortAscend_64f_I(Ipp64f* pSrcDst, int len);
    IppStatus IppsSortRadixAscend_32u_I(Ipp32u* pSrcDst, Ipp32u* pTmp, Ipp32s len);
    ...
    
    I'd expect these to provide a well-optimized solution for any Intel platform.