4 { This file contains 2-pass color quantization (color mapping) routines.
5 These routines provide selection of a custom color map for an image,
6 followed by mapping of the image to that color map, with optional
7 Floyd-Steinberg dithering.
8 It is also possible to use just the second pass to map to an arbitrary
9 externally-given color map.
11 Note: ordered dithering is not supported, since there isn't any fast
12 way to compute intercolor distances; it's unclear that ordered dither's
13 fundamental assumptions even hold with an irregularly spaced color map. }
15 { Original: jquant2.c; Copyright (C) 1991-1996, Thomas G. Lane. }
17 interface
19 {$I imjconfig.inc}
21 uses
22 imjmorecfg,
23 imjdeferr,
24 imjerror,
25 imjutils,
26 imjpeglib;
28 { Module initialization routine for 2-pass color quantization. }
31 {GLOBAL}
34 implementation
36 { This module implements the well-known Heckbert paradigm for color
37 quantization. Most of the ideas used here can be traced back to
38 Heckbert's seminal paper
39 Heckbert, Paul. "Color Image Quantization for Frame Buffer Display",
40 Proc. SIGGRAPH '82, Computer Graphics v.16 #3 (July 1982), pp 297-304.
42 In the first pass over the image, we accumulate a histogram showing the
43 usage count of each possible color. To keep the histogram to a reasonable
44 size, we reduce the precision of the input; typical practice is to retain
45 5 or 6 bits per color, so that 8 or 4 different input values are counted
46 in the same histogram cell.
48 Next, the color-selection step begins with a box representing the whole
49 color space, and repeatedly splits the "largest" remaining box until we
50 have as many boxes as desired colors. Then the mean color in each
51 remaining box becomes one of the possible output colors.
53 The second pass over the image maps each input pixel to the closest output
54 color (optionally after applying a Floyd-Steinberg dithering correction).
55 This mapping is logically trivial, but making it go fast enough requires
56 considerable care.
58 Heckbert-style quantizers vary a good deal in their policies for choosing
59 the "largest" box and deciding where to cut it. The particular policies
60 used here have proved out well in experimental comparisons, but better ones
61 may yet be found.
63 In earlier versions of the IJG code, this module quantized in YCbCr color
64 space, processing the raw upsampled data without a color conversion step.
65 This allowed the color conversion math to be done only once per colormap
66 entry, not once per pixel. However, that optimization precluded other
67 useful optimizations (such as merging color conversion with upsampling)
68 and it also interfered with desired capabilities such as quantizing to an
69 externally-supplied colormap. We have therefore abandoned that approach.
70 The present code works in the post-conversion color space, typically RGB.
72 To improve the visual quality of the results, we actually work in scaled
73 RGB space, giving G distances more weight than R, and R in turn more than
74 B. To do everything in integer math, we must use integer scale factors.
75 The 2/3/1 scale factors used here correspond loosely to the relative
76 weights of the colors in the NTSC grayscale equation.
77 If you want to use this code to quantize a non-RGB color space, you'll
78 probably need to change these scale factors. }
80 const
85 { Relabel R/G/B as components 0/1/2, respecting the RGB ordering defined
86 in jmorecfg.h. As the code stands, it will do the right thing for R,G,B
87 and B,G,R orders. If you define some other weird order in jmorecfg.h,
88 you'll get compile errors until you extend this logic. In that case
89 you'll probably want to tweak the histogram sizes too. }
91 {$ifdef RGB_RED_IS_0}
92 const
96 {$else}
97 const
101 {$endif}
104 { First we have the histogram data structure and routines for creating it.
106 The number of bits of precision can be adjusted by changing these symbols.
107 We recommend keeping 6 bits for G and 5 each for R and B.
108 If you have plenty of memory and cycles, 6 bits all around gives marginally
109 better results; if you are short of memory, 5 bits all around will save
110 some space but degrade the results.
111 To maintain a fully accurate histogram, we'd need to allocate a "long"
112 (preferably unsigned long) for each cell. In practice this is overkill;
113 we can get by with 16 bits per cell. Few of the cell counts will overflow,
114 and clamping those that do overflow to the maximum value will give close-
115 enough results. This reduces the recommended histogram size from 256Kb
116 to 128Kb, which is a useful savings on PC-class machines.
117 (In the second pass the histogram space is re-used for pixel mapping data;
118 in that capacity, each cell must be able to store zero to the number of
119 desired colors. 16 bits/cell is plenty for that too.)
120 Since the JPEG code is intended to run in small memory model on 80x86
121 machines, we can't just allocate the histogram in one chunk. Instead
122 of a true 3-D array, we use a row of pointers to 2-D arrays. Each
123 pointer corresponds to a C0 value (typically 2^5 = 32 pointers) and
124 each 2-D array has 2^6*2^5 = 2048 or 2^6*2^6 = 4096 entries. Note that
125 on 80x86 machines, the pointer row is in near memory but the actual
126 arrays are in far memory (same arrangement as we use for image arrays). }
129 const
132 { These will do the right thing for either R,G,B or B,G,R color order,
133 but you may not like the results for other color orders. }
135 const
140 { Number of elements along histogram axes. }
141 const
146 { These are the amounts to shift an input value to get a histogram index. }
147 const
158 type
161 type
164 type
166 {hist1d_ptr = ^hist1d;}
168 { type for the 2nd-level pointers }
174 { Declarations for Floyd-Steinberg dithering.
176 Errors are accumulated into the array fserrors[], at a resolution of
177 1/16th of a pixel count. The error at a given pixel is propagated
178 to its not-yet-processed neighbors using the standard F-S fractions,
179 ... (here) 7/16
180 3/16 5/16 1/16
181 We work left-to-right on even rows, right-to-left on odd rows.
183 We can get away with a single array (holding one row's worth of errors)
184 by using it to store the current row's errors at pixel columns not yet
185 processed, but the next row's errors at columns already processed. We
186 need only a few extra variables to hold the errors immediately around the
187 current column. (If we are lucky, those variables are in registers, but
188 even if not, they're probably cheaper to access than array elements are.)
190 The fserrors[] array has (#columns + 2) entries; the extra entry at
191 each end saves us from special-casing the first and last pixels.
192 Each entry is three values long, one value for each color component.
194 Note: on a wide image, we might not have enough room in a PC's near data
195 segment to hold the error array; so it is allocated with alloc_large. }
198 {$ifdef BITS_IN_JSAMPLE_IS_8}
199 type
202 {$else}
203 type
206 {$endif}
216 type
221 { pointer to error array (in FAR storage!) }
223 type
225 { table for clamping the applied error }
228 { Private subobject }
229 type
234 { Space for the eventually created colormap is stashed here }
238 { Variables for accumulating image statistics }
243 { Variables for Floyd-Steinberg dithering }
251 { Prescan some rows of pixels.
252 In this module the prescan simply updates the histogram, which has been
253 initialized to zeroes by start_pass.
254 An output_buf parameter is required by the method signature, but no data
255 is actually output (in fact the buffer controller is probably passing a
256 NIL pointer). }
258 {METHODDEF}
263 var
271 begin
277 begin
280 begin
281 { get pixel value and index into the histogram }
285 { increment, check for overflow and undo increment if so. }
294 { Next we have the really interesting routines: selection of a colormap
295 given the completed histogram.
296 These routines work with a list of "boxes", each representing a rectangular
297 subset of the input color space (to histogram precision). }
299 type
301 { The bounds of the box (inclusive); expressed as histogram indexes }
305 { The volume (actually 2-norm) of the box }
307 { The number of nonzero histogram cells within this box }
311 type
317 {LOCAL}
319 { Find the splittable box with the largest color population }
320 { Returns NIL if no splittable boxes remain }
321 var
326 begin
331 begin
333 begin
343 {LOCAL}
345 { Find the splittable box with the largest (scaled) volume }
346 { Returns NULL if no splittable boxes remain }
347 var
352 begin
357 begin
359 begin
369 {LOCAL}
371 label
375 { Shrink the min/max bounds of a box to enclose only nonzero elements, }
376 { and recompute its volume and population }
377 var
385 begin
396 begin
399 begin
401 begin
409 have_c0min:
413 begin
416 begin
418 begin
426 have_c0max:
430 begin
433 begin
435 begin
443 have_c1min:
447 begin
450 begin
452 begin
460 have_c1max:
464 begin
467 begin
469 begin
477 have_c2min:
481 begin
484 begin
486 begin
494 have_c2max:
496 { Update box volume.
497 We use 2-norm rather than real volume here; this biases the method
498 against making long narrow boxes, and it has the side benefit that
499 a box is splittable iff norm > 0.
500 Since the differences are expressed in histogram-cell units,
501 we have to shift back to JSAMPLE units to get consistent distances;
502 after which, we scale according to the selected distance scale factors.}
509 { Now scan remaining volume of box and compute population }
513 begin
516 begin
526 {LOCAL}
529 { Repeatedly select and split the largest box until we have enough boxes }
530 var
534 begin
536 begin
537 { Select box to split.
538 Current algorithm: by population for first half, then by volume. }
542 else
546 break;
548 { Copy the color bounds to the new box. }
551 { Choose which axis to split the box on.
552 Current algorithm: longest scaled axis.
553 See notes in update_box about scaling distances. }
558 { We want to break any ties in favor of green, then red, blue last.
559 This code does the right thing for R,G,B or B,G,R color orders only. }
561 {$ifdef RGB_RED_IS_0}
564 begin
570 {$else}
574 begin
580 {$endif}
581 { Choose split point along selected axis, and update box bounds.
582 Current algorithm: split at halfway point.
583 (Since the box has been shrunk to minimum volume,
584 any split will produce two nonempty subboxes.)
585 Note that lb value is max for lower box, so must be < old max. }
604 { Update stats for boxes }
613 {LOCAL}
616 { Compute representative color for a box, put it in colormap[icolor] }
617 var
618 { Current algorithm: mean weighted by pixels (not colors) }
619 { Note it is important to get the rounding correct! }
630 begin
644 begin
647 begin
651 begin
666 {LOCAL}
668 { Master routine for color selection }
669 var
673 begin
674 { Allocate workspace for box list }
677 { Initialize one box containing whole space }
685 { Shrink it to actually-used volume and set its statistics }
687 { Perform median-cut to produce final box list }
689 { Compute the representative color for each box, fill colormap }
693 {$IFDEF DEBUG}
695 {$ENDIF}
699 { These routines are concerned with the time-critical task of mapping input
700 colors to the nearest color in the selected colormap.
702 We re-use the histogram space as an "inverse color map", essentially a
703 cache for the results of nearest-color searches. All colors within a
704 histogram cell will be mapped to the same colormap entry, namely the one
705 closest to the cell's center. This may not be quite the closest entry to
706 the actual input color, but it's almost as good. A zero in the cache
707 indicates we haven't found the nearest color for that cell yet; the array
708 is cleared to zeroes before starting the mapping pass. When we find the
709 nearest color for a cell, its colormap index plus one is recorded in the
710 cache for future use. The pass2 scanning routines call fill_inverse_cmap
711 when they need to use an unfilled entry in the cache.
713 Our method of efficiently finding nearest colors is based on the "locally
714 sorted search" idea described by Heckbert and on the incremental distance
715 calculation described by Spencer W. Thomas in chapter III.1 of Graphics
716 Gems II (James Arvo, ed. Academic Press, 1991). Thomas points out that
717 the distances from a given colormap entry to each cell of the histogram can
718 be computed quickly using an incremental method: the differences between
719 distances to adjacent cells themselves differ by a constant. This allows a
720 fairly fast implementation of the "brute force" approach of computing the
721 distance from every colormap entry to every histogram cell. Unfortunately,
722 it needs a work array to hold the best-distance-so-far for each histogram
723 cell (because the inner loop has to be over cells, not colormap entries).
724 The work array elements have to be INT32s, so the work array would need
725 256Kb at our recommended precision. This is not feasible in DOS machines.
727 To get around these problems, we apply Thomas' method to compute the
728 nearest colors for only the cells within a small subbox of the histogram.
729 The work array need be only as big as the subbox, so the memory usage
730 problem is solved. Furthermore, we need not fill subboxes that are never
731 referenced in pass2; many images use only part of the color gamut, so a
732 fair amount of work is saved. An additional advantage of this
733 approach is that we can apply Heckbert's locality criterion to quickly
734 eliminate colormap entries that are far away from the subbox; typically
735 three-fourths of the colormap entries are rejected by Heckbert's criterion,
736 and we need not compute their distances to individual cells in the subbox.
737 The speed of this approach is heavily influenced by the subbox size: too
738 small means too much overhead, too big loses because Heckbert's criterion
739 can't eliminate as many colormap entries. Empirically the best subbox
740 size seems to be about 1/512th of the histogram (1/8th in each direction).
742 Thomas' article also describes a refined method which is asymptotically
743 faster than the brute-force method, but it is also far more complex and
744 cannot efficiently be applied to small subboxes. It is therefore not
745 useful for programs intended to be portable to DOS machines. On machines
746 with plenty of memory, filling the whole histogram in one shot with Thomas'
747 refined method might be faster than the present code --- but then again,
748 it might not be any faster, and it's certainly more complicated. }
752 { log2(histogram cells in update box) for each axis; this can be adjusted }
753 const
767 { The next three routines implement inverse colormap filling. They could
768 all be folded into one big routine, but splitting them up this way saves
769 some stack space (the mindist[] and bestdist[] arrays need not coexist)
770 and may allow some compilers to produce better code by registerizing more
771 inner-loop variables. }
773 {LOCAL}
777 { Locate the colormap entries close enough to an update box to be candidates
778 for the nearest entry to some cell(s) in the update box. The update box
779 is specified by the center coordinates of its first cell. The number of
780 candidate colormap entries is returned, and their colormap indexes are
781 placed in colorlist[].
782 This routine uses Heckbert's "locally sorted search" criterion to select
783 the colors that need further consideration. }
785 var
792 { min distance to colormap entry i }
793 begin
796 { Compute true coordinates of update box's upper corner and center.
797 Actually we compute the coordinates of the center of the upper-corner
798 histogram cell, which are the upper bounds of the volume we care about.
799 Note that since ">>" rounds down, the "center" values may be closer to
800 min than to max; hence comparisons to them must be "<=", not "<". }
809 { For each color in colormap, find:
810 1. its minimum squared-distance to any point in the update box
811 (zero if color is within update box);
812 2. its maximum squared-distance to any point in the update box.
813 Both of these can be found by considering only the corners of the box.
814 We save the minimum distance for each color in mindist[];
815 only the smallest maximum distance is of interest. }
820 begin
821 { We compute the squared-c0-distance term, then add in the other two. }
824 begin
829 end
830 else
832 begin
837 end
838 else
839 begin
840 { within cell range so no contribution to min_dist }
843 begin
846 end
847 else
848 begin
856 begin
861 end
862 else
864 begin
869 end
870 else
871 begin
872 { within cell range so no contribution to min_dist }
874 begin
877 end
878 else
879 begin
882 end
887 begin
892 end
893 else
895 begin
900 end
901 else
902 begin
903 { within cell range so no contribution to min_dist }
905 begin
908 end
909 else
910 begin
921 { Now we know that no cell in the update box is more than minmaxdist
922 away from some colormap entry. Therefore, only colors that are
923 within minmaxdist of some part of the box need be considered. }
927 begin
929 begin
938 {LOCAL}
944 { Find the closest colormap entry for each cell in the update box,
945 given the list of candidate colors prepared by find_nearby_colors.
946 Return the indexes of the closest entries in the bestcolor[] array.
947 This routine uses Thomas' incremental distance calculation method to
948 find the distance from a colormap entry to successive cells in the box. }
949 const
950 { Nominal steps between cell centers ("x" in Thomas article) }
954 var
964 { This array holds the distance to the nearest-so-far color for each cell }
966 begin
967 { Initialize best-distance for each cell of the update box }
971 { For each color selected by find_nearby_colors,
972 compute its distance to the center of each cell in the box.
973 If that's less than best-so-far, update best distance and color number. }
978 begin
980 { Compute (square of) distance from minc0/c1/c2 to this color }
987 { Form the initial difference increments }
991 { Now loop over all cells in box, updating distance per Thomas method }
996 begin
1000 begin
1004 begin
1006 begin
1025 {LOCAL}
1028 { Fill the inverse-colormap entries in the update box that contains }
1029 { histogram cell c0/c1/c2. (Only that one cell MUST be filled, but }
1030 { we can fill as many others as we wish.) }
1031 var
1038 { This array lists the candidate colormap indexes. }
1041 { This array holds the actually closest colormap index for each cell. }
1043 begin
1047 { Convert cell coordinates to update box ID }
1052 { Compute true coordinates of update box's origin corner.
1053 Actually we compute the coordinates of the center of the corner
1054 histogram cell, which are the lower bounds of the volume we care about.}
1060 { Determine which colormap entries are close enough to be candidates
1061 for the nearest entry to some cell in the update box. }
1065 { Determine the actually nearest colors. }
1067 bestcolor);
1069 { Save the best color numbers (plus 1) in the main cache array }
1076 begin
1079 begin
1088 { Map some rows of pixels to the output colormapped representation. }
1090 {METHODDEF}
1095 { This version performs no dithering }
1096 var
1106 begin
1112 begin
1116 begin
1117 { get pixel value and index into the cache }
1123 { If we have not seen this color before, find nearest colormap entry }
1124 { and update the cache }
1127 { Now emit the colormap index for this cell }
1135 {METHODDEF}
1140 { This version performs Floyd-Steinberg dithering }
1141 var
1147 prev_errorptr,
1163 begin
1174 begin
1179 begin
1180 { work right to left in this row }
1186 end
1187 else
1188 begin
1189 { work left to right in this row }
1194 { Preset error values: no error propagated to first pixel from left }
1198 { and no error propagated to row below yet }
1207 begin
1211 { curN holds the error propagated from the previous pixel on the
1212 current line. Add the error propagated from the previous line
1213 to form the complete error correction term for this pixel, and
1214 round the error term (which is expressed * 16) to an integer.
1215 RIGHT_SHIFT rounds towards minus infinity, so adding 8 is correct
1216 for either sign of the error value.
1217 Note: prev_errorptr points to *previous* column's array entry. }
1219 { Nomssi Note: Borland Pascal SHR is unsigned }
1223 { Limit the error using transfer function set by init_error_limit.
1224 See comments with init_error_limit for rationale. }
1229 { Form pixel value + error, and range-limit to 0..MAXJSAMPLE.
1230 The maximum error is +- MAXJSAMPLE (or less with error limiting);
1231 this sets the required size of the range_limit array. }
1240 { Index into the cache with adjusted pixel value }
1243 { If we have not seen this color before, find nearest colormap }
1244 { entry and update the cache }
1249 { Now emit the colormap index for this cell }
1254 { Compute representation error for this pixel }
1259 { Compute error fractions to be propagated to adjacent pixels.
1260 Add these into the running sums, and simultaneously shift the
1261 next-line error sums left by 1 column. }
1288 { At this point curN contains the 7/16 error value to be propagated
1289 to the next pixel on the current line, and all the errors for the
1290 next line have been shifted over. We are therefore ready to move on.}
1295 { Post-loop cleanup: we must unload the final error values into the
1296 final fserrors[] entry. Note we need not unload belowerrN because
1297 it is for the dummy column before or after the actual array. }
1306 { Initialize the error-limiting transfer function (lookup table).
1307 The raw F-S error computation can potentially compute error values of up to
1308 +- MAXJSAMPLE. But we want the maximum correction applied to a pixel to be
1309 much less, otherwise obviously wrong pixels will be created. (Typical
1310 effects include weird fringes at color-area boundaries, isolated bright
1311 pixels in a dark area, etc.) The standard advice for avoiding this problem
1312 is to ensure that the "corners" of the color cube are allocated as output
1313 colors; then repeated errors in the same direction cannot cause cascading
1314 error buildup. However, that only prevents the error from getting
1315 completely out of hand; Aaron Giles reports that error limiting improves
1316 the results even with corner colors allocated.
1317 A simple clamping of the error values to about +- MAXJSAMPLE/8 works pretty
1318 well, but the smoother transfer function used below is even better. Thanks
1319 to Aaron Giles for this idea. }
1321 {LOCAL}
1323 const
1325 { Allocate and fill in the error_limiter table }
1326 var
1330 begin
1334 { not needed: Inc(table, MAXJSAMPLE);
1335 so can index -MAXJSAMPLE .. +MAXJSAMPLE }
1337 { Map errors 1:1 up to +- MAXJSAMPLE/16 }
1340 begin
1345 { Map errors 1:2 up to +- 3*MAXJSAMPLE/16 }
1348 begin
1355 { Clamp the rest to final out value (which is (MAXJSAMPLE+1)/8) }
1358 begin
1365 { Finish up at the end of each pass. }
1367 {METHODDEF}
1369 var
1371 begin
1374 { Select the representative colors and fill in cinfo^.colormap }
1377 { Force next pass to zero the color index table }
1382 {METHODDEF}
1384 begin
1385 { no work }
1389 { Initialize for each processing pass. }
1391 {METHODDEF}
1394 var
1398 var
1400 begin
1403 { Only F-S dithering or no dithering is supported. }
1404 { If user asks for ordered dither, give him F-S. }
1409 begin
1410 { Set up method pointers }
1414 end
1415 else
1416 begin
1417 { Set up method pointers }
1420 else
1424 { Make sure color count is acceptable }
1432 begin
1435 { Allocate Floyd-Steinberg workspace if we didn't already. }
1439 { Initialize the propagated errors to zero. }
1441 { Make the error-limit table if we didn't already. }
1448 { Zero the histogram or inverse color map, if necessary }
1450 begin
1452 begin
1461 { Switch to a new external colormap between output passes. }
1463 {METHODDEF}
1465 var
1467 begin
1470 { Reset the inverse color map }
1475 { Module initialization routine for 2-pass color quantization. }
1478 {GLOBAL}
1480 var
1483 var
1485 begin
1495 { Make sure jdmaster didn't give me a case I can't handle }
1499 { Allocate the histogram/inverse colormap storage }
1503 begin
1510 { Allocate storage for the completed colormap, if required.
1511 We do this now since it is FAR storage and may affect
1512 the memory manager's space calculations. }
1515 begin
1516 { Make sure color count is acceptable }
1518 { Lower bound on # of colors ... somewhat arbitrary as long as > 0 }
1521 { Make sure colormap indexes can be represented by JSAMPLEs }
1527 end
1528 else
1531 { Only F-S dithering or no dithering is supported. }
1532 { If user asks for ordered dither, give him F-S. }
1536 { Allocate Floyd-Steinberg workspace if necessary.
1537 This isn't really needed until pass 2, but again it is FAR storage.
1538 Although we will cope with a later change in dither_mode,
1539 we do not promise to honor max_memory_to_use if dither_mode changes. }
1542 begin
1546 { Might as well create the error-limiting table too. }
1550 { QUANT_2PASS_SUPPORTED }