## File: gb_lisa.w

package info (click to toggle)
sgb 1:20030623-3
 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652 % This file is part of the Stanford GraphBase (c) Stanford University 1993 @i boilerplate.w %<< legal stuff: PLEASE READ IT BEFORE MAKING ANY CHANGES! @i gb_types.w \def\title{GB\_\,LISA} \prerequisites{GB\_\,GRAPH}{GB\_\,IO} @* Introduction. This GraphBase module contains the |lisa| subroutine, which creates rectangular matrices of data based on Leonardo da Vinci's @^Vinci, Leonardo da@> {\sl Gioconda\/} (aka Mona Lisa). It also contains the |plane_lisa| subroutine, which constructs undirected planar graphs based on |lisa|, and the |bi_lisa| subroutine, which constructs undirected bipartite graphs. Another example of the use of |lisa| can be found in the demo program {\sc ASSIGN\_LISA}. @d plane_lisa p_lisa /* abbreviation for Procrustean external linkage */ @(gb_lisa.h@>= #define plane_lisa p_lisa extern long* lisa(); extern Graph *plane_lisa(); extern Graph *bi_lisa(); @ The subroutine call |lisa(m,n,d,m0,m1,n0,n1,d0,d1,area)| constructs an $m\times n$ matrix of integers in the range $[0\,.\,.\,d\mskip1mu]$, based on the information in \.{lisa.dat}. Storage space for the matrix is allocated in the memory area called |area|, using the normal GraphBase conventions explained in {\sc GB\_\,GRAPH}. The entries of the matrix can be regarded as pixel data, with 0~representing black and $d$~representing white, and with intermediate values representing shades of gray. The data in \.{lisa.dat} has 360 rows and 250 columns. The rows are numbered 0 to 359 from top to bottom, and the columns are numbered 0 to 249 from left to right. The output of |lisa| is generated from a rectangular section of the picture consisting of |m1-m0| rows and |n1-n0| columns; more precisely, |lisa| uses the data in positions $(k,l)$ for |m0<=k=d1|, and to $\lfloor d(D-|d0|)/(|d1|-|d0|)\rfloor$ if |d0<=D360|, |m1|~is changed to 360; if |n1=0| or |n1>250|, |n1|~is changed to~250. Then if |m| is zero, it is changed to~|m1-m0|; if |n| is zero, it is changed to~|n1-n0|. If |d| is zero, it is changed to~255. If |d1| is zero, it is changed to |255(m1-m0)(n1-n0)|. After these substitutions have been made, the parameters must satisfy $$\hbox{|m0=lisa(0,0,0,0,0,0,0,0,0,area)| is equivalent to the call |@t\\{lisa\_pix}@>=lisa(360,250,255,0,360,0,250,0,255*360*250,area)|; this special case delivers the original \.{lisa.dat} data as a 360\times250 array of integers in the range [0\,.\,.\,255]. You can access the pixel in row~k and column~l by writing$$\hbox{|*(@[@t\\{lisa\_pix}@>@]+n*k+l)|}\,, where |n| in this case is 250. A square array extracted from the top part of the picture, leaving out Mona's hands at the bottom, can be obtained by calling |lisa(250,250,255,0,250,0,250,0,0,area)|. The call |lisa(36,25,25500,0,0,0,0,0,0,area)| gives a $36\times25$ array of pixel values in the range $[0\,.\,.\,25500]$, obtained by summing $10\times10$ subsquares of the original data. The call |lisa(100,100,100,0,0,0,0,0,0,area)| gives a $100\times100$ array of pixel values in the range $[0\,.\,.\,100]$; in this case the original data is effectively broken into subpixels and averaged appropriately. Notice that each output pixel in this example comes from 3.6 input rows and 2.5 input columns; therefore the image is being distorted (compressed vertically). However, our GraphBase applications are generally interested more in combinatorial test data, not in images per~se. If |(m1-m0)/m=(n1-n0)/n|, the output of |lisa| will represent square pixels.'' But if |(m1-m0)/m<(n1-n0)/n|, a halftone generated from the output will be compressed in the horizontal dimension; if |(m1-m0)/m>(n1-n0)/n|, it will be compressed in the vertical dimension. If you want to reduce the original image to binary data, with the value~0 wherever the original pixels are less than some threshold value~|t| and the value~1 whenever they are |t| or more, call |lisa(m,n,1,m0,m1,n0,n1,@t}\penalty0{@>0,t*(m1-m0)*(n1-n0),area)|. The subroutine call |lisa(1000,1000,255,0,250,0,250,0,0,area)| produces a million pixels from the upper part of the original image. This matrix contains more entries than the original data in \.{lisa.dat}, but of course it is not any more accurate; it has simply been obtained by linear interpolation---in fact, by replicating the original data in $4\times4$ subarrays. Mona Lisa's famous smile appears in the $16\times32$ subarray defined by |m0=94|, |m1=110|, |n0=97|, |n1=129|. The |smile| macro makes this easily accessible. (See also |eyes|.) A string |lisa_id| is constructed, showing the actual parameter values used by |lisa| after defaults have been supplied. The |area| parameter is omitted from this string. @= #define smile @t\quad@> m0=94,m1=110,n0=97,n1=129 /* $16\times32$ */ #define eyes @t\quad@> m0=61,m1=80,n0=91,n1=140 /* $20\times50$ */ extern char lisa_id[]; @ @= char lisa_id[]= "lisa(360,250,9999999999,359,360,249,250,9999999999,9999999999)"; @ If the |lisa| routine encounters a problem, it returns |NULL| (\.{NULL}), after putting a nonzero number into the external variable |panic_code|. This code number identifies the type of failure. Otherwise |lisa| returns a pointer to the newly created array. (The external variable |panic_code| is defined in {\sc GB\_\,GRAPH}.) @d panic(c) @+{@+panic_code=c;@+gb_trouble_code=0;@+return NULL;@+} @ The \CEE/ file \.{gb\_lisa.c} begins as follows. (Other subroutines come later.) @p #include "gb_io.h" /* we will use the {\sc GB\_\,IO} routines for input */ #include "gb_graph.h" /* we will use the {\sc GB\_\,GRAPH} data structures */ @h@# @@; @@; @@; @# long *lisa(m,n,d,m0,m1,n0,n1,d0,d1,area) unsigned long m,n; /* number of rows and columns desired */ unsigned long d; /* maximum pixel value desired */ unsigned long m0,m1; /* input will be from rows $[|m0|\,.\,.\,|m1|)$ */ unsigned long n0,n1; /* and from columns $[|n0|\,.\,.\,|n1|)$ */ unsigned long d0,d1; /* lower and upper threshold of raw pixel scores */ Area area; /* where to allocate the matrix that will be output */ {@+@@;@# @; @; @; return matx; } @ @= long *matx=NULL; /* the matrix constructed by |lisa| */ register long k,l; /* the current row and column of output */ register long i,j; /* all-purpose indices */ long cap_M,cap_N; /* |m1-m0| and |n1-n0|, dimensions of the input */ long cap_D; /* |d1-d0|, scale factor */ @ @= if (m1==0 || m1>MAX_M) m1=MAX_M; if (m1<=m0) panic(bad_specs+1); /* |m0| must be less than |m1| */ if (n1==0 || n1>MAX_N) n1=MAX_N; if (n1<=n0) panic(bad_specs+2); /* |n0| must be less than |n1| */ cap_M=m1-m0;@+cap_N=n1-n0; if (m==0) m=cap_M; if (n==0) n=cap_N; if (d==0) d=MAX_D; if (d1==0) d1=MAX_D*cap_M*cap_N; if (d1<=d0) panic(bad_specs+3); /* |d0| must be less than |d1| */ if (d1>=0x80000000) panic(bad_specs+4); /* |d1| must be less than $2^{31}$ */ cap_D=d1-d0; sprintf(lisa_id,"lisa(%lu,%lu,%lu,%lu,%lu,%lu,%lu,%lu,%lu)", m,n,d,m0,m1,n0,n1,d0,d1); @ @= matx=gb_typed_alloc(m*n,long,area); if (gb_trouble_code) panic(no_room+1); /* no room for the output data */ @ @= @; @; @; @* Elementary image processing. As mentioned in the introduction, we can visualize the input as a giant $mM\times nN$ matrix, into which an $M\times N$ image is placed by replication of pixel values, and from which an $m\times n$ image is derived by summation of pixel values and subsequent scaling. Here |M=m1-m0| and |N=n1-n0|. Let $(\kappa,\lambda)$ be a position in the giant matrix, where $0\le\kappa= long *cur_pix; /* current position within |in_row| */ long lambda; /* right boundary in giant for the input pixel in |cur_pix| */ long lam; /* the first giant column not yet used in the current row */ long next_lam; /* right boundary in giant for the output pixel in column~|l| */ @ @= lambda=n;@+cur_pix=in_row+n0; for (l=lam=0; l=lambda) cur_pix++,lambda+=n; if (lambda= kappa=0; out_row=matx; for (k=kap=0; k=kappa) { @; kappa+=m; } if (kappa; kap=nk; }@+while (kap; } @ @= long kappa; /* bottom boundary in giant for the input pixels in |in_row| */ long kap; /* the first giant row not yet used */ long next_kap; /* bottom boundary in giant for the output pixel in row~|k| */ long f; /* factor by which current input sums should be replicated */ long *out_row; /* current position in |matx| */ @* Integer scaling. Here's a general-purpose routine to compute$\lfloor na/b\rfloor$exactly without risking integer overflow, given integers$n\ge0$and$0= static long na_over_b(n,a,b) long n,a,b; {@+long nmax=el_gordo/a; /* the largest $n$ such that $na$ doesn't overflow */ register long r,k,q,br; long a_thresh, b_thresh; if (n<=nmax) return (n*a)/b; a_thresh=b-a; b_thresh=(b+1)>>1; /* $\lceil b/2\rceil$ */ k=0; do@+{@+bit[k]=n&1; /* save the least significant bit of $n$ */ n>>=1; /* and shift it out */ k++; }@+while (n>nmax); r=n*a;@+ q=r/b;@+ r=r-q*b; @; return q; } @ @= static long bit[30]; /* bits shifted out of |n| */ @ @= do@+{@+k--;@+ q<<=1; if (r= if (*out_row<=d0) *out_row=0; else if (*out_row>=d1) *out_row=d; else *out_row=na_over_b(d,*out_row-d0,cap_D); @* Input data format. The file \.{lisa.dat} contains 360 rows of pixel data, and each row appears on five consecutive lines of the file. The first four lines contain the data for 60 pixels; each sequence of four pixels is represented by five radix-85 digits, using the |icode| mapping of {\sc GB\_\,IO}. The fifth and final line of each row contains $4+4+2=10$ more pixels, represented as $5+5+3$ radix-85 digits. @= if (gb_open("lisa.dat")!=0) panic(early_data_fault); /* couldn't open the file; |io_errors| tells why */ for (i=0;i= for (i=m1;i= {@+register long dd; for (j=15,cur_pix=&in_row[0];;cur_pix+=4) { dd=gb_digit(85);@+dd=dd*85+gb_digit(85);@+dd=dd*85+gb_digit(85); if (cur_pix==&in_row[MAX_N-2]) break; dd=dd*85+gb_digit(85);@+dd=dd*85+gb_digit(85); *(cur_pix+3)=dd&0xff;@+dd=(dd>>8)&0xffffff; *(cur_pix+2)=dd&0xff;@+dd>>=8; *(cur_pix+1)=dd&0xff;@+*cur_pix=dd>>8; if (--j==0) gb_newline(),j=15; } *(cur_pix+1)=dd&0xff;@+*cur_pix=dd>>8;@+gb_newline(); } @ @= static long in_row[MAX_N]; @* Planar graphs. We can obtain a large family of planar graphs based on digitizations of Mona Lisa by using the following simple scheme: Each matrix of pixels defines a set of connected regions containing pixels of the same value. (Two pixels are considered adjacent if they share an edge.) These connected regions are taken to be vertices of an undirected graph; two vertices are adjacent if the corresponding regions have at least one pixel edge in common. We can also state the construction another way. If we take any planar graph and collapse two adjacent vertices, we obtain another planar graph. Suppose we start with the planar graph having $mn$ vertices $[k,l]$ for $0\le k0$ and to $[k-1,l]$ when $k>0$. Then we can attach pixel values to each vertex, after which we can repeatedly collapse adjacent vertices whose pixel values are equal. The resulting planar graph is the same as the graph of connected regions that was described in the previous paragraph. The subroutine call |plane_lisa(m,n,d,m0,m1,n0,n1,d0,d1)| constructs the planar graph associated with the digitization produced by |lisa|. The description of |lisa|, given earlier, explains the significance of parameters |m|, |n|, |d|, |m0|, |m1|, |n0|, |n1|, |d0|, and |d1|. There will be at most $mn$ vertices, and the graph will be simply an $m\times n$ grid unless |d| is small enough to permit adjacent pixels to have equal values. The graph will also become rather trivial if |d| is too small. Utility fields |first_pixel| and |last_pixel| give, for each vertex, numbers of the form $k*n+l$, identifying the topmost/leftmost and bottommost/rightmost positions $[k,l]$ in the region corresponding to that vertex. Utility fields |matrix_rows| and |matrix_cols| in the |Graph| record contain the values of |m| and~|n|; thus, in particular, the value of |n| needed to decompose |first_pixel| and |last_pixel| into individual coordinates can be found in |g->matrix_cols|. The original pixel value of a vertex is placed into its |pixel_value| utility field. @d pixel_value x.I @d first_pixel y.I @d last_pixel z.I @d matrix_rows uu.I @d matrix_cols vv.I @p Graph *plane_lisa(m,n,d,m0,m1,n0,n1,d0,d1) unsigned long m,n; /* number of rows and columns desired */ unsigned long d; /* maximum value desired */ unsigned long m0,m1; /* input will be from rows $[|m0|\,.\,.\,|m1|)$ */ unsigned long n0,n1; /* and from columns $[|n0|\,.\,.\,|n1|)$ */ unsigned long d0,d1; /* lower and upper threshold of raw pixel scores */ {@+@@;@# init_area(working_storage); @