| 1 | .\" RCSid "$Id" | 
| 2 | .TH PINTERP 1 1/24/96 RADIANCE | 
| 3 | .SH NAME | 
| 4 | pinterp - interpolate/extrapolate view from pictures | 
| 5 | .SH SYNOPSIS | 
| 6 | .B pinterp | 
| 7 | [ | 
| 8 | view options | 
| 9 | ][ | 
| 10 | .B "\-t threshold" | 
| 11 | ][ | 
| 12 | .B "\-z zout" | 
| 13 | ][ | 
| 14 | .B \-f | 
| 15 | .I type | 
| 16 | ][ | 
| 17 | .B \-B | 
| 18 | ][ | 
| 19 | .B \-a|q | 
| 20 | ][ | 
| 21 | .B "\-e exposure" | 
| 22 | ][ | 
| 23 | .B \-n | 
| 24 | ] | 
| 25 | .B "pictfile zspec .." | 
| 26 | .SH DESCRIPTION | 
| 27 | .I Pinterp | 
| 28 | interpolates or extrapolates a new view from | 
| 29 | one or more RADIANCE pictures and | 
| 30 | sends the result to the standard output. | 
| 31 | The input picture files must contain correct view specifications, as | 
| 32 | maintained by | 
| 33 | .I rpict(1), | 
| 34 | .I rview(1), | 
| 35 | .I pfilt(1) | 
| 36 | and | 
| 37 | .I pinterp. | 
| 38 | Specifically, | 
| 39 | .I pinterp | 
| 40 | will not work on pictures processed by | 
| 41 | .I pcompos(1) | 
| 42 | or | 
| 43 | .I pcomb(1). | 
| 44 | Each input file must be accompanied by a z specification, which | 
| 45 | gives the distance to each pixel in the image. | 
| 46 | If | 
| 47 | .I zspec | 
| 48 | is an existing file, it is assumed to contain a short floating point | 
| 49 | number for each pixel, written in scanline order. | 
| 50 | This file is usually generated by the | 
| 51 | .I \-z | 
| 52 | option of | 
| 53 | .I rpict(1). | 
| 54 | If | 
| 55 | .I zspec | 
| 56 | is a positive number rather than a file, it will be used as a | 
| 57 | constant value for the corresponding image. | 
| 58 | This may be useful for certain transformations on "flat" images or | 
| 59 | when the viewpoint remains constant. | 
| 60 | .PP | 
| 61 | The | 
| 62 | .I \-n | 
| 63 | option specifies that input and output | 
| 64 | z distances are along the view direction, | 
| 65 | rather than absolute distances to intersection points. | 
| 66 | This option is usually appropriate with a constant z | 
| 67 | specification, and should not be used with | 
| 68 | .I rpict(1) | 
| 69 | z files. | 
| 70 | .PP | 
| 71 | The | 
| 72 | .I \-z | 
| 73 | option writes out interpolated z values to the specified file. | 
| 74 | Normally, this information is thrown away. | 
| 75 | .PP | 
| 76 | .I Pinterp | 
| 77 | rearranges the pixels from the input pictures to produce a | 
| 78 | reasonable estimate of the desired view. | 
| 79 | Pixels that map within the | 
| 80 | .I \-t | 
| 81 | threshold of each other (.02 times the z distance | 
| 82 | by default) are considered coincident. | 
| 83 | With the | 
| 84 | .I \-a | 
| 85 | option, image points that coincide will be averaged together, giving | 
| 86 | a smooth result. | 
| 87 | The | 
| 88 | .I \-q | 
| 89 | option turns averaging off, which means that the first mapped pixel | 
| 90 | for a given point will be used. | 
| 91 | This makes the program run faster and | 
| 92 | take less memory, but at the expense of image quality. | 
| 93 | By default, two or more pictures are averaged together, and a single | 
| 94 | picture is treated with the faster algorithm. | 
| 95 | This may be undesirable when a quick result is desired from multiple | 
| 96 | input pictures in the first case, or a single picture is being | 
| 97 | reduced in size (anti-aliased) in the second case. | 
| 98 | .PP | 
| 99 | Portions which were hidden or missing in the input pictures must be | 
| 100 | "filled in" somehow, and a number of methods are provided by the | 
| 101 | .I \-f | 
| 102 | option. | 
| 103 | The default value for this option is | 
| 104 | .I \-fa, | 
| 105 | which results in both foreground and background filling. | 
| 106 | The foreground fill algorithm spreads each input pixel to cover all | 
| 107 | output pixels within a parallelogram corresponding to that pixel's | 
| 108 | projection in the new view. | 
| 109 | Without it, each input pixel contributes to at most one output | 
| 110 | pixel. | 
| 111 | The background algorithm fills in those areas in the final picture | 
| 112 | that have not been filled with foreground pixels. | 
| 113 | It does this by looking at the boundary surrounding each blank area | 
| 114 | and picking the | 
| 115 | farthest pixels to each side, assuming that this will make a suitable | 
| 116 | background. | 
| 117 | The | 
| 118 | .I \-ff | 
| 119 | option tells the program to use only the foreground fill, the | 
| 120 | .I \-fb | 
| 121 | option says use only background fill, and the | 
| 122 | .I \-f0 | 
| 123 | option says not to use either fill algorithm. | 
| 124 | .PP | 
| 125 | Even when both fill algorithms are used, there may still be some unfilled | 
| 126 | pixels. | 
| 127 | By default, these pixels are painted black and assigned a z distance | 
| 128 | of zero. | 
| 129 | The | 
| 130 | .I \-fc | 
| 131 | option can be used to change the color used for unfilled pixels, and | 
| 132 | the | 
| 133 | .I \-fz | 
| 134 | option can be used to set the z distance (always along the view direction). | 
| 135 | Alternatively, the | 
| 136 | .I \-fr | 
| 137 | option can be used to compute these pixels using | 
| 138 | .I rtrace(1). | 
| 139 | The argument to this option is a quoted string containing arguments | 
| 140 | for | 
| 141 | .I rtrace. | 
| 142 | It must contain the octree used to generate the input | 
| 143 | pictures, along with any other options necessary to match the | 
| 144 | calculation used for the input pictures. | 
| 145 | The | 
| 146 | .I \-fs | 
| 147 | option can be used to place a limit on the distance (in pixels) over which | 
| 148 | the background fill algorithm is used. | 
| 149 | The default value for this option is 0, which is interpreted as no limit. | 
| 150 | A value of 1 is equivalent to turning background fill off. | 
| 151 | When combined with the | 
| 152 | .I \-fr | 
| 153 | option, this is roughly equivalent to the | 
| 154 | .I \-ps | 
| 155 | option of | 
| 156 | .I rpict(1). | 
| 157 | .PP | 
| 158 | In order of increasing quality and cost, one can use the | 
| 159 | .I \-fa | 
| 160 | option alone, or the | 
| 161 | .I \-fr | 
| 162 | option paired with | 
| 163 | .I \-fs | 
| 164 | or | 
| 165 | .I \-ff | 
| 166 | or | 
| 167 | .I \-f0. | 
| 168 | The last combination will result in the recalculation of all pixels | 
| 169 | not adequately accounted for in the input pictures, with an | 
| 170 | associated computational expense. | 
| 171 | It is rare that the | 
| 172 | .I \-fs | 
| 173 | option results in appreciable image degradation, so it is usually | 
| 174 | the second combination that is used when the background fill | 
| 175 | algorithm results in objectionable artifacts. | 
| 176 | .PP | 
| 177 | The | 
| 178 | .I \-B | 
| 179 | option may be used to average multiple views read from the standard | 
| 180 | input into a single, blurred output picture. | 
| 181 | This is similar to running | 
| 182 | .I pinterp | 
| 183 | multiple times and averaging the output together with a program like | 
| 184 | .I pcomb(1). | 
| 185 | This option is useful for simulating motion blur and depth of field. | 
| 186 | (See also | 
| 187 | .I pdfblur(1).)\0 | 
| 188 | The input views are reported in the information header of the output | 
| 189 | file, along with the averaged view. | 
| 190 | The picture dimensions computed from the first view will be the | 
| 191 | ones used, regardless whether or not the subsequent views agree. | 
| 192 | (The reported pixel aspect ratio in the output is determined from | 
| 193 | these original dimensions and the averaged view.)\0 | 
| 194 | Note that the expense of the | 
| 195 | .I \-fr | 
| 196 | option is proportional to the number of views computed, and the | 
| 197 | .I \-z | 
| 198 | output file will be the z-buffer of the last view interpolated | 
| 199 | rather than an averaged distance map. | 
| 200 | .PP | 
| 201 | In general, | 
| 202 | .I pinterp | 
| 203 | performs well when the output view is flanked by two nearby input | 
| 204 | views, such as might occur in a walk-through animation sequence. | 
| 205 | The algorithms start to break down when there is a large difference | 
| 206 | between the view desired and the view(s) provided. | 
| 207 | Specifically, obscured objects may appear to have holes in them and | 
| 208 | large areas at the image borders may not be filled by the | 
| 209 | foreground or background algorithms. | 
| 210 | Also, specular reflections and highlights will not be interpolated | 
| 211 | very well, since their view-dependent appearance will be | 
| 212 | incompletely compensated for by the program. | 
| 213 | (The | 
| 214 | .I \-a | 
| 215 | option offers some benefit in this area.)\0 | 
| 216 | .PP | 
| 217 | The | 
| 218 | .I \-e | 
| 219 | option may be used to adjust the output image exposure, with the | 
| 220 | same specification given as for | 
| 221 | .I pfilt. | 
| 222 | The actual adjustment will be rounded to the nearest integer f-stop | 
| 223 | if the | 
| 224 | .I \-q | 
| 225 | option is in effect (or there is only a single input picture). | 
| 226 | .SH EXAMPLE | 
| 227 | To interpolate two frames of a walk-through animation, anti-alias to | 
| 228 | 512x400 and increase the exposure by 2.5 f-stops: | 
| 229 | .IP "" .2i | 
| 230 | pinterp -vf 27.vf -a -x 512 -y 400 -e +2.5 30.pic 30.z 20.pic 20.z > 27.pic | 
| 231 | .PP | 
| 232 | To extrapolate a second eyepoint for a stereo pair and recalculate | 
| 233 | background regions: | 
| 234 | .IP "" .2i | 
| 235 | pinterp -vf right.vf -ff -fr "-av .1 .1 .1 scene.oct" left.pic left.z > right.pic | 
| 236 | .SH AUTHOR | 
| 237 | Greg Ward | 
| 238 | .SH "SEE ALSO" | 
| 239 | getinfo(1), pdfblur(1), pfilt(1), pmblur(1), rpict(1), ranimate(1), | 
| 240 | rtrace(1), rview(1) |