Photographed-based assessment of dental treatments and procedures

TECHNICAL FIELD

0001The current document is directed to methods and systems for monitoring patient progress during dental treatments and procedures and, in particular, to a photograph-based monitoring method, and system that carries out the method, that uses two-dimensional photographs taken during a patient examination to determine how well the patient's teeth correspond to a three-dimensional representation of the expected positions of patient's teeth according to the treatment plan.

BACKGROUND

0002Prior to the development of oral-cavity-imaging-and-modeling systems, dental practitioners employed mechanical-impression methods to create three-dimensional models of teeth and underlying tissue in order to facilitate fabrication of various types of prostheses, including crowns and bridges. The mechanical-impression technologies generally involved biting, by a patient, into a viscous, thixotropic material that retains an accurate impression of the patient's teeth and underlying tissue when the material is lifted off from the patient's teeth. The material may serve as a mold for casting a positive three-dimensional model of the patient's teeth and underlying gum tissue or as a mold for casting a prosthetic device. While mechanical-impression technologies have been used by dental practitioners for many decades, mechanical-impression technologies are associated with a variety of deficiencies, including a relatively large probability that the impression may be inadvertently altered or damaged during removal of the hardened, viscous, thixotropic material from the patient's teeth as well as during transportation of the impression to laboratories where positive three-dimensional models are cast and prostheses are fabricated. In addition, the procedure is time-consuming and unpleasant to many patients.

0003More recently, semi-automated oral-cavity-imaging-and-modeling systems have been developed to electronically create digital, three-dimensional models of teeth and underlying tissues from images of a patient's oral cavity captured by an electro-optical-mechanical endoscope, or wand, that is guided by a technician within a patient's oral cavity in order to collect a sufficient number of two-dimensional images from which a three-dimensional digital model of the patient's teeth and underlying tissues is computationally generated. The oral-cavity-imaging-and-modeling systems have proven to be faster, more accurate and robust, and more cost effective than mechanical-impression technologies.

0004In many cases, therefore, dental professionals can prepare accurate, three-dimensional models of a patient's teeth and use the three-dimensional models to analyze the patient's dental status and develop treatment plans for various types of deficiencies and pathologies. Furthermore, the three-dimensional model can be electronically manipulated to prepare projected three-dimensional configurations of the patient's teeth for various time points during the course of a treatment plan. Vendors of dental equipment, dental practitioners, and, ultimately, dental patients seek cost-effective and time-effective methods and systems to use the three-dimensional information in order to monitor a dental patient's progress during a course of treatment.

SUMMARY

0005The current document is directed to methods and systems for monitoring a dental patient's progress during a course of treatment. At any particular point in time during the course of treatment, a three-dimensional model of the expected positions of the patient's teeth at that point in time can be projected, in time, from a three-dimensional model of the patient's teeth prepared prior to beginning the treatment. During the course of treatment, a digital camera is used to take one or more two-dimensional photographs of the patient's teeth which are input to a monitoring system. The input two-dimensional photographs represent the actual positions of the patient's teeth. The monitoring system determines virtual-camera parameters for each two-dimensional input image with respect to the projected three-dimensional model and uses the determined virtual-camera parameters to generate two-dimensional images from the three-dimensional model. The generated two-dimensional photographs represent the expected or desired positions of the patient's teeth. The monitoring system then compares each input photograph to the corresponding generated two-dimensional image in order to determine how closely the three-dimensional arrangement of the patient's teeth corresponds to the projected three-dimensional arrangement. When the correspondence falls below a threshold level, an indication that the treatment is not proceeding according to plan is returned to a dental practitioner so that the dental practitioner can take corrective actions The invention is defined by the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

0006<ul id="ul0001" list-style="none" compact="compact"><li><figref idref="f0001">Figure 1</figref> illustrates a three-dimensional model of a dental patient's teeth.</li><li><figref idref="f0002 f0003">Figures 2A-B</figref> illustrate the relationship between a virtual-camera position and a three-dimensional model of a patient's teeth.</li><li><figref idref="f0004 f0007">Figures 3A-D</figref> illustrate one approach to mapping points in the world coordinate system to corresponding points on the image plane of a virtual camera.</li><li><figref idref="f0008">Figure 4</figref> illustrates a continuum of three-dimensional models of a dental patient's teeth that can be electronically prepared to reflect the expected arrangements of the dental patient's teeth during the course of a proposed treatment plan.</li><li><figref idref="f0009 f0012">Figures 5A-D</figref> graphically illustrate the treatment-monitoring method to which the current document is, in part, directed.</li><li><figref idref="f0013">Figure 6</figref> provides a control-flow-diagram illustration of the operation of the treatment-monitoring system and treatment-monitoring method to which the current document is directed.</li><li><figref idref="f0014 f0015">Figures 7A-B</figref> illustrate, using control-flow diagrams, step 604 of <figref idref="f0013">Figure 6</figref>.</li><li><figref idref="f0016">Figure 8</figref> provides a control-flow diagram for step 610 of <figref idref="f0013">Figure 6</figref>, a virtual-camera-parameters determination method.</li><li><figref idref="f0017">Figure 9</figref> provides a control-flow diagram for the initial virtual-camera-parameters adjustment method invoked in step 805 of <figref idref="f0016">Figure 8</figref>.</li><li><figref idref="f0018 f0020">Figures 10A-C</figref> provide additional details with regard to steps 904, 908, and 912 of <figref idref="f0017">Figure 9</figref>.</li><li><figref idref="f0021">Figure 11</figref> shows the second virtual-camera-parameter's adjustment method invoked in step 806 of <figref idref="f0016">Figure 8</figref>.</li><li><figref idref="f0022">Figure 12</figref> provides a control-flow diagram for the optimization step 1106 in <figref idref="f0021">Figure 11</figref>.</li><li><figref idref="f0023 f0025">Figures 13A-C</figref> illustrate computation of a gradient-based cost.</li><li><figref idref="f0026">Figure 14</figref> provides a control-flow diagram for the first virtual-camera-parameters refinement method called in step 807 of <figref idref="f0016">Figure 8</figref>.</li><li><figref idref="f0027">Figure 15</figref> illustrates examples of the tooth groups over which the inner loop of the method illustrated in <figref idref="f0026">Figure 14</figref> iterates.</li><li><figref idref="f0028">Figure 16</figref> illustrates, using the same illustration conventions as used in <figref idref="f0023 f0024 f0025">Figure 13</figref>, computation of the Laplacian vectors for image elements and generation of a Laplacian-vector field.</li><li><figref idref="f0030">Figures 17A-B</figref> illustrate computation of the comparison value or correlation coefficient.</li><li><figref idref="f0031">Figure 18</figref> provides a general architectural diagram for various types of computers, including computers used to implement dental-treatment monitoring systems.</li><li><figref idref="f0032">Figure 19</figref> illustrates an Internet-connected distributed computer system.</li><li><figref idref="f0033">Figure 20</figref> illustrates cloud computing.</li><li><figref idref="f0034">Figure 21</figref> illustrates generalized hardware and software components of a general-purpose computer system, such as a general-purpose computer system having an architecture similar to that shown in <figref idref="f0001">Figure 1</figref>.</li><li><figref idref="f0035 f0036">Figures 22A-B</figref> illustrate two types of virtual machine and virtual-machine execution environments.</li></ul>

DETAILED DESCRIPTION

0007<figref idref="f0001">Figure 1</figref> illustrates a three-dimensional model of a dental patient's teeth. The three-dimensional model 102 includes a three-dimensional model of the teeth associated with the dental patient's upper jaw 104 and a three-dimensional model of the dental patient's teeth associated with the lower jaw 106. The three-dimensional model is generally prepared, using sophisticated imaging and reconstruction hardware and software, based on optical scans of the dental patient's oral cavity. The three-dimensional model may be electronically represented in many different ways, similar to the many different ways in which three-dimensional objects may be represented in various different types of CAD/CAM and various imaging and solid-modeling systems. The model may be electronically presented in a variety of different orientations and configurations. For example, the two jaws 104 and 106 may be rotated about rotation axis 108 so that the teeth associated with the two jaws close together and assume a configuration similar to that in patient with a closed mouth. Each jaw and associated teeth may be, alternatively presented as a separate three-dimensional model.

0008<figref idref="f0002 f0003">Figures 2A-B</figref> illustrate the relationship between a virtual-camera position and a three-dimensional model of a patient's teeth. As shown in <figref idref="f0002">Figure 2A</figref>, the three-dimensional model of the dental patient's teeth 202 is translationally and rotationally positioned within a three-dimensional world coordinate system 204 having three mutually orthogonal axes <i>X, Y,</i> and <i>Z</i>. A two-dimensional view of the three-dimensional model can be obtained, from any position within the world coordinate system external to the three-dimensional model, by simulated image capture using a virtual camera 208. The virtual camera 208 is associated with its own three-dimensional coordinate system 210 having three mutually orthogonal axes <i>x</i>, <i>y,</i> and z. The world coordinate system and the camera coordinate system are, of course, mathematically related by a translation of the origin of the camera <i>x, y, z</i> coordinate system from the origin 212 of the world coordinate system and by three rotation angles that, when applied to the camera, rotate the camera <i>x</i>, <i>y,</i> and z coordinate system with respect to the world <i>X, Y, Z</i> coordinate system. The origin 214 of the camera <i>x</i>, <i>y, z</i> coordinate system has the coordinates (0, 0, 0) in the camera coordinate system and the coordinates (<i>X_c, Y_c,</i> and <i>Z_c</i>) in the world coordinate system. The two-dimensional image captured by the virtual camera 216 can be thought of as lying in the x, z plane of the camera coordinate system and centered at the origin of the camera coordinate system, as shown in <figref idref="f0002 f0003">Figure 2</figref>.

0009<figref idref="f0003">Figure 2B</figref> illustrates operations involved with orienting and positioning the camera <i>x, y, z</i> coordinate system to be coincident with the world <i>X, Y,</i> Z coordinate system. In <figref idref="f0003">Figure 2B</figref>, the camera coordinate system 216 and world coordinate system 204 are centered at two different origins, 214 and 212, respectively, and the camera coordinate system is oriented differently than the world coordinate system. In order to orient and position the camera <i>x</i>, <i>y, z</i> coordinate system to be coincident with the world <i>X, Y, Z</i> coordinate system, three operations are undertaken. A first operation 220 involves translation of the camera-coordinate system, by a displacement represented by a vector <b>t</b>, so that the origins 214 and 212 of the two coordinate systems are coincident. The position of the camera coordinate system with respect to the world coordinate system is shown with dashed lines, including dashed line 218, with respect to the world coordinate system following the translation operation 220. A second operation 222 involves rotating the camera coordinate system by an angle α (224) so that the <i>z</i> axis of the camera coordinate system, referred to as the <i>z</i>' axis following the translation operation, is coincident with the <i>Z</i> axis of the world coordinate system. In a third operation 226, the camera coordinate system is rotated about the <i>Z</i>/<i>z'</i> axis by an angle θ (228) so that all of the camera-coordinate-system axes are coincident with their corresponding world-coordinate-system axes.

0010<figref idref="f0004 f0007">Figures 3A-D</figref> illustrate one approach to mapping points in the world coordinate system to corresponding points on the image plane of a virtual camera. This process allows virtual cameras to be positioned anywhere within space with respect to a computational three-dimensional model of a patient's teeth and used to generate a two-dimensional image that corresponds to the two-dimensional image that would be captured from a real camera having the same position and orientation with respect to an equivalent solid-model three-dimensional representation of a patient's teeth. <figref idref="f0004">Figure 3A</figref> illustrates the image plane of a virtual camera, an aligned camera coordinate system and world coordinate system, and a point in three-dimensional space that is imaged on the image plane of the virtual camera. In <figref idref="f0004">Figure 3A</figref>, and in <figref idref="f0005 f0007">Figures 3B-D</figref> that follow, the camera coordinate system, comprising the <i>x, y,</i> and <i>z</i> axes, is aligned and coincident with the world-coordinate system <i>X, Y,</i> and <i>Z</i>. This is indicated, in <figref idref="f0004">Figure 3A</figref>, by dual labeling of the <i>x</i> and <i>X</i> axis 302, the <i>y</i> and <i>Y</i> axis 304, and the <i>z</i> and <i>Z</i> axis 306. The point that is imaged 308 is shown to have the coordinates (<i>X_p, Y_p,</i> and <i>Z_p</i>). The image of this point on the virtual-camera image plane 310 has the coordinates (<i>x_i</i>, <i>y_i</i>). The virtual lens of the virtual camera is centered at the point 312, which has the camera coordinates (0, 0, <i>l</i>) and the world coordinates (0, 0, <i>l</i>). When the point 308 is in focus, the distance <i>I</i> between the origin 314 and point 312 is the focal length of the virtual camera. Note that, in <figref idref="f0004">Figure 3A</figref>, the z axis is used as the axis of symmetry for the virtual camera rather than the <i>y</i> axis, as in <figref idref="f0002">Figure 2A</figref>. A small rectangle is shown, on the image plane, with the corners along one diagonal coincident with the origin 314 and the point 310 with coordinates (<i>x_i</i>, <i>y_i</i>). The rectangle has horizontal sides, including horizontal side 316, of length <i>x_i,</i> and vertical sides, including vertical side 318, with lengths <i>y_i</i>. A corresponding rectangle with horizontal sides of length -<i>X_p,</i> including horizontal side 320, and vertical sides of length <i>-Y_p,</i> including vertical side 322. The point 308 with world coordinates <i>X_p, Y_p,</i> and <i>Z_p</i>) and the point 324 with world coordinates (0, 0, <i>Z_p</i>) are located at the corners of one diagonal of the corresponding rectangle. Note that the positions of the two rectangles are inverted through point 312. The length of the line segment 328 between point 312 and point 324 is <i>Z_p</i> - <i>l.</i> The angles at which each of the lines passing through point 312 intersects the <i>z, Z</i> axis are equal on both sides of point 312. For example, angle 330 and angle 332 are identical. As a result, the principal of the correspondence between the lengths of similar sides of similar triangles can be used to derive expressions for the image-plane coordinates (<i>x_i</i>, <i>y_i</i>) for an imaged point in three-dimensional space with world coordinates (<i>X_p, Y_p,</i> and <i>Z_p</i>) 334: <maths id="math0001"><math display="block"><mfrac><msub><mi>x</mi><mi>i</mi></msub><mi>l</mi></mfrac><mo>=</mo><mfrac><mrow><mo>−</mo><msub><mi>X</mi><mi>p</mi></msub></mrow><mrow><msub><mi>Z</mi><mi>p</mi></msub><mo>−</mo><mi>l</mi></mrow></mfrac><mo>=</mo><mfrac><msub><mi>X</mi><mi>p</mi></msub><mrow><mi>l</mi><mo>−</mo><msub><mi>Z</mi><mi>p</mi></msub></mrow></mfrac></math><img file="EP3338245B1_D0001.tif" /></maths><maths id="math0002"><math display="block"><mfrac><msub><mi>y</mi><mi>i</mi></msub><mi>l</mi></mfrac><mo>=</mo><mfrac><mrow><mo>−</mo><msub><mi>Y</mi><mi>p</mi></msub></mrow><mrow><msub><mi>Z</mi><mi>p</mi></msub><mo>−</mo><mi>l</mi></mrow></mfrac><mo>=</mo><mfrac><msub><mi>Y</mi><mi>p</mi></msub><mrow><mi>l</mi><mo>−</mo><msub><mi>Z</mi><mi>p</mi></msub></mrow></mfrac></math><img file="EP3338245B1_D0002.tif" /></maths><maths id="math0003"><math display="block"><msub><mi>x</mi><mi>i</mi></msub><mo>=</mo><mfrac><msub><mi mathvariant="italic">lX</mi><mi>p</mi></msub><mrow><mi>l</mi><mo>−</mo><msub><mi>Z</mi><mi>p</mi></msub></mrow></mfrac><mo>,</mo></math><img file="EP3338245B1_D0003.tif" /></maths><maths id="math0004"><math display="block"><msub><mi>y</mi><mi>i</mi></msub><mo>=</mo><mfrac><msub><mi mathvariant="italic">lY</mi><mi>p</mi></msub><mrow><mi>l</mi><mo>−</mo><msub><mi>Z</mi><mi>p</mi></msub></mrow></mfrac></math><img file="EP3338245B1_D0004.tif" /></maths>

0011Of course, virtual-camera coordinate systems are not, in general, aligned with the world coordinate system, as discussed above with reference to <figref idref="f0002">Figure 2A</figref>. Therefore, a slightly more complex analysis is required to develop the functions, or processes, that map points in three-dimensional space to points on the image plane of a virtual camera. <figref idref="f0005 f0007">Figures 3B-D</figref> illustrate the process for computing the image of points in a three-dimensional space on the image plane of an arbitrarily oriented and positioned virtual camera. <figref idref="f0005">Figure 3B</figref> shows the arbitrarily positioned and oriented virtual camera. The virtual camera 336 is mounted to a mount 337 that allows the virtual camera to be tilted by an angle <i>α</i> 338 with respect to the vertical <i>Z</i> axis and to be rotated by an angle <i>θ</i> 339 about a vertical axis. The mount 337 can be positioned anywhere in three-dimensional space, with the position represented by a position vector <b>w</b>₀ 340 from the origin of the world coordinate system 341 to the mount 337. A second vector <b>r</b> 342 represents the relative position of the center of the image plane 343 within the virtual camera 336 with respect to the mount 337. The orientation and position of the origin of the camera coordinate system coincides with the center of the image plane 343 within the virtual camera 336. The image plane 343 lies within the <i>x, y</i> plane of the camera coordinate axes 344-346. The camera is shown, in <figref idref="f0005">Figure 3B</figref>, imaging a point <b>w</b> 347, with the image of the point <b>w</b> appearing as image point <b>c</b> 348 on the image plane 343 within the virtual camera. The vector <b>w</b>₀ that defines the position of the camera mount 337 is shown, in <figref idref="f0005">Figure 3B</figref>, to be the vector <maths id="math0005"><math display="block"><msub><mi mathvariant="normal">w</mi><mn>0</mn></msub><mo>=</mo><mfenced open="[" close="]"><mtable><mtr><mtd><msub><mi>X</mi><mn>0</mn></msub></mtd></mtr><mtr><mtd><msub><mi>Y</mi><mn>0</mn></msub></mtd></mtr><mtr><mtd><msub><mi>Z</mi><mn>0</mn></msub></mtd></mtr></mtable></mfenced></math><img file="EP3338245B1_D0005.tif" /></maths>

0012<figref idref="f0006 f0007">Figures 3C-D</figref> show the process by which the coordinates of a point in three-dimensional space, such as the point corresponding to vector <b>w</b> in world-coordinate-system coordinates, is mapped to the image plane of an arbitrarily positioned and oriented virtual camera. First, a transformation between world coordinates and homogeneous coordinates <i>h</i> and the inverse transformation <i>h</i>^-1 is shown in <figref idref="f0006">Figure 3C</figref> by the expressions 350 and 351. The forward transformation from world coordinates 352 to homogeneous coordinates 353 involves multiplying each of the coordinate components by an arbitrary constant k and adding a fourth coordinate component <i>k.</i> The vector <b>w</b> corresponding to the point 347 in three-dimensional space imaged by the virtual camera is expressed as a column vector, as shown in expression 354 in <figref idref="f0006">Figure 3C</figref>. The corresponding column vector <b>w</b><i>_h</i> in homogeneous coordinates is shown in expression 355. The matrix <b>P</b> is the perspective transformation matrix, shown in expression 356 in <figref idref="f0006">Figure 3C</figref>. The perspective transformation matrix is used to carry out the world-to-camera coordinate transformations (334 in <figref idref="f0004">Figure 3A</figref>) discussed above with reference to <figref idref="f0004">Figure 3A</figref>. The homogeneous-coordinate-form of the vector <b>c</b> corresponding to the image 348 of point 347, <b>c</b><i>_h</i>, is computed by the left-hand multiplication of <b>w</b><i>_h</i> by the perspective transformation matrix, as shown in expression 357 in <figref idref="f0006">Figure 3C</figref>. Thus, the expression for <b>c</b><i>_h</i> in homogeneous camera coordinates 358 corresponds to the homogeneous expression for <b>c</b><i>_h</i> in world coordinates 359. The inverse homogeneous-coordinate transformation 360 is used to transform the latter into a vector expression in world coordinates 361 for the vector <b>c</b> 362. Comparing the camera-coordinate expression 363 for vector c with the world-coordinate expression for the same vector 361 reveals that the camera coordinates are related to the world coordinates by the transformations (334 in <figref idref="f0004">Figure 3A</figref>) discussed above with reference to <figref idref="f0004">Figure 3A</figref>. The inverse of the perspective transformation matrix, <b>P</b>^-1, is shown in expression 364 in <figref idref="f0006">Figure 3C</figref>. The inverse perspective transformation matrix can be used to compute the world-coordinate point in three-dimensional space corresponding to an image point expressed in camera coordinates, as indicated by expression 366 in <figref idref="f0006">Figure 3C</figref>. Note that, in general, the Z coordinate for the three-dimensional point imaged by the virtual camera is not recovered by the perspective transformation. This is because all of the points in front of the virtual camera along the line from the image point to the imaged point are mapped to the image point. Additional information is needed to determine the Z coordinate for three-dimensional points imaged by the virtual camera, such as depth information obtained from a set of stereo images or depth information obtained by a separate depth sensor.

0013Three additional matrices are shown in <figref idref="f0007">Figure 3D</figref> that represent the position and orientation of the virtual camera in the world coordinate system. The translation matrix <b>T_{w<sub2>0</sub2>}</b> 370 represents the translation of the camera mount (337 in <figref idref="f0005">Figure 3B</figref>) from its position in three-dimensional space to the origin (341 in <figref idref="f0005">Figure 3B</figref>) of the world coordinate system. The matrix <b>R</b> represents the <i>α</i> and <i>θ</i> rotations needed to align the camera coordinate system with the world coordinate system 372. The translation matrix <b>C</b> 374 represents translation of the image plane of the virtual camera from the camera mount (337 in <figref idref="f0005">Figure 3B</figref>) to the image plane's position within the virtual camera represented by vector <b>r</b> (342 in <figref idref="f0005">Figure 3B</figref>). The full expression for transforming the vector for a point in three-dimensional space <b>w</b><i>_h</i> into a vector that represents the position of the image point on the virtual-camera image plane <b>c</b><i>_h</i> is provided as expression 376 in <figref idref="f0007">Figure 3D</figref>. The vector <b>w</b><i>_h</i> is multiplied, from the left, first by the translation matrix 370 to produce a first intermediate result, the first intermediate result is multiplied, from the left, by the matrix <b>R</b> to produce a second intermediate result, the second intermediate result is multiplied, from the left, by the matrix <b>C</b> to produce a third intermediate result, and the third intermediate result is multiplied, from the left, by the perspective transformation matrix <b>P</b> to produce the vector <b>c</b><i>_h</i>. Expression 378 shows the inverse transformation. Thus, in general, there is a forward transformation from world-coordinate points to image points 380 and, when sufficient information is available, an inverse transformation 381. It is the forward transformation 380 that is used to generate two-dimensional images from a three-dimensional model or object corresponding to arbitrarily oriented and positioned virtual cameras. Each point on the surface of the three-dimensional object or model is transformed by forward transformation 380 to points on the image plane of the virtual camera.

0014<figref idref="f0008">Figure 4</figref> illustrates a continuum of three-dimensional models of a dental patient's teeth that can be electronically prepared to reflect the expected arrangements of the dental patient's teeth during the course of a proposed treatment plan. In <figref idref="f0008">Figure 4</figref>, lower horizontal arrow 402 represents the timeline of the treatment plan. At an initial starting point 404, specified in <figref idref="f0008">Figure 4</figref> as time <i>t</i>₀, the arrangement of the dental patient's teeth is captured in an initial three-dimensional model 406 of the patient's teeth. A time-projected three-dimensional model, such as three-dimensional model 408, can be electronically prepared as an estimate of how the dental patient's teeth are expected to be arranged at a future point in time <i>t</i>₈₂ during the course of the treatment or procedure. As shown in <figref idref="f0008">Figure 4</figref>, the final time-projected three-dimensional model 410 in the continuous series of three-dimensional models represents the goal for the treatment or procedure that is expected to be obtained at time <i>t</i>₂₂₄. Although only four three-dimensional models are shown in both the treatment or procedure timeline 402 in <figref idref="f0008">Figure 4</figref>, a time-projected three-dimensional model for any point along the timeline can be electronically prepared using extrapolation and simulation-based methodologies.

0015<figref idref="f0009 f0012">Figures 5A-D</figref> graphically illustrate the treatment-monitoring method to which the current document is, in part, directed. As shown in <figref idref="f0009">Figure 5A</figref>, at a particular current point in time, <i>t</i>₈₂, during a dental patient's treatment or procedure, represented in <figref idref="f0009">Figure 5A</figref> by vertical arrow 502, a dental practitioner examines the patient and takes a number <i>n</i> of two-dimensional pictures of the patient's teeth 504. Alternatively, in certain implementations, the two-dimensional pictures may be taken by a patient's friend or relative, or even the patient, using a camera timer or smart-phone features that facilitate acquisition of images of a user. In the current example, <i>n</i> is equal to 3. In general, each photograph or subset of the photographs represents a certain, standard view or image type. A dental practitioner or other person is provided with instructions for capturing an image of a particular standard view or type. As shown in <figref idref="f0010">Figure 5B</figref>, once the practitioner has submitted these two-dimensional images, along with patient information, an indication of the time that the two-dimensional images were captured, and other such information, the treatment-monitoring system, to which the current document is, in part, directed, determines camera parameters for virtual cameras 506-508, the orientations and positions of which most likely correspond to the camera parameters of the dental practitioner's camera at the points in time at which each of the corresponding n two-dimensional pictures, 510-512, respectively, were captured by the dental practitioner or other person.

0016Next, as shown in <figref idref="f0011">Figure 5C</figref>, the determined camera parameters for the virtual cameras are used to generate corresponding two-dimensional images 516-518 corresponding to the <i>n</i> two-dimensional images 510-512 taken by the dental practitioner or other person. Finally, as shown in <figref idref="f0012">Figure 5D</figref>, a comparison operation, such as comparison operation 520, is applied to each pair of a dental-practitioner-submitted image and a corresponding image generated from the three-dimensional model in order to produce a correlation coefficient. In one implementation, the correlation coefficients are expressed as floating point values between 0 and 1 (522 in <figref idref="f0012">Figure 5D</figref>). The correlation coefficients for the individual images are used to generate a single aggregate correlation value 524, in one implementation of the currently described method and system, which is also a floating-point value between 0 and 1 (526 in <figref idref="f0012">Figure 5D</figref>). When the aggregate correlation value computed from the submitted two-dimensional images and the projected three-dimensional model is greater than a threshold value, as determined in step 528, then the treatment-monitoring system stores, in memory, and returns an indication that the treatment is proceeding according to plan 530. Otherwise, the treatment-monitoring system stores, in memory, and returns an indication that the treatment is not going according to plan 532. It should be noted that, in certain implementations, multiple images for a given standard view may be used for generating correlation coefficients and an aggregate correlation coefficient. In other implementations, including an implementation discussed below, a best representative image for each standard view is selected for processing.

0017<figref idref="f0013">Figure 6</figref> provides a control-flow-diagram illustration of the operation of the treatment-monitoring system and treatment-monitoring method to which the current document is directed. Additional control-flow diagrams, discussed below, provide greater detail for various steps in the highest-level control-flow diagram shown in <figref idref="f0013">Figure 6</figref>. In step 602, the treatment-monitoring method and/or system ("treatment monitor") receives: (1) n two-dimensional photographs of a first jaw and m two-dimensional photographs of a second jaw of a dental patient examined during the course of a treatment or procedure; (2) exchangeable-image-file-format ("EXIF") metadata for each of the <i>n</i> + <i>m</i> two-dimensional images; (3) text labels for the two-dimensional images, which include, among other things, an indication of a standard type of view represented by each image and characterizations and parameters for the digitally encoded image, including the size of the image, date and time information, and camera settings, including one or more of the camera model and make and camera orientation, aperture, shutter speed, focal length, metering mode, and International Organization for Standardization ("ISO") speed information; (4) a patient ID and other information; and (5) the time and date, <i>t,</i> of the patient examination which produced the two-dimensional photos. In step 604, the treatment monitor checks and verifies the input data. When there are any errors detected, as determined in step 606, an error is returned, in step 608, to allow various types of amelioration procedures to be undertaken, including requesting additional or substitute input information. Otherwise, in step 610, the treatment monitor determines the virtual-camera parameters for each of the input images that have survived the initial check and verification step 604. In step 612, a two-dimensional image corresponding to each of the input images is generated from the time-projected three-dimensional model using the determined set of virtual-camera parameters for the corresponding input image. In step 614, each input image and corresponding model-based projected image is compared to determine a correlation coefficient, and the set of correlation coefficients are used to determine an aggregate correlation coefficient. When the determined aggregate correlation coefficient is greater than a threshold value, as determined in step 616, an indication that the treatment or procedure is on track, ON TRACK, is returned in step 618. Otherwise, an indication that the treatment or procedure is off track, OFF_TRACK, is returned in step 620.

0018<figref idref="f0014 f0015">Figures 7A-B</figref> illustrate, using control-flow diagrams, step 604 of <figref idref="f0013">Figure 6</figref>. In the nested <i>for</i>-loops of steps 702-713, each input image related to each of the first and second jaws of the dental patient is considered. In step 704, the check-and-verification method matches the currently considered image within the nested <i>for-</i>loops with the metadata extracted and collected for that image from the input data. In step 705, the check-and-verify method filters the image to remove inconsistencies and defects and, in certain cases, may expand or contract the contrast within the image, or alter the color balance, in order to adjust the image for further analysis. In step 706, the check-and-verify method carries out a qualitative analysis of the image and assigns a quality metric to the image. This quality metric reflects how well the image corresponds to the image type specified in the metadata, as well as the sharpness, clarity, and completeness of the image. When the currently considered image is equivalent to an image already processed within the nested <i>for</i>-loops, as determined in step 707, and when the quality of metric assigned to the currently considered image is better than that of the already-processed image, as determined in step 708, the already-processed image is replaced by the currently considered image in a set of processed images prepared by the check-and-verify method, in step 709. Otherwise, when the quality metric assigned to the currently considered image is not better than that of the already-processed image, as determined in step 708, the currently considered image is discarded, in step 710. When the currently considered image is not equivalent to an already-processed image, as determined in step 707, the currently considered image is placed, along with the computed quality metric and various metadata, into the set of processed images, in step 711. In step 714, the check-and-verify method verifies the patient ID included in the input information. Turning to <figref idref="f0015">Figure 7B</figref>, when the patient ID is verified, as determined in step 715, and when the set of processed images prepared in the nested <i>for</i>-loops of step 702-713 are deemed adequate for further analysis, as determined in step 717, the check-and-verify method returns, in step 719, without reporting an error condition. In this case, the set of processed images contains a single, best image of each type, and the set of images contains sufficient information to proceed with analyzing progress of the treatment. Otherwise, error conditions are reported in steps 716 and 718. Of course, the check-and-verify method may, in various implementations, carry out additional types of verification and checking of the input data, and may return addition types of error conditions when the additional checks and verifications fail.

0019<figref idref="f0016">Figure 8</figref> provides a control-flow diagram for step 610 of <figref idref="f0013">Figure 6</figref>, a virtual-camera-parameters determination method. In the <i>for</i>-loop of steps 802-812, each image in the set of processed images produced by the check-and-verify method, discussed above with reference to <figref idref="f0014 f0015">Figures 7A-B</figref>, is considered. In step 803, the method uses the metadata associated with the image, including the image type, to initialize a set of virtual-camera parameters associated with the image and to select an iteration count <i>N</i>. Different types of images and images with different characteristics and qualities may require a different number of adjustments and refinements. Then, in the <i>while</i>-loop of steps 804-810, the initial virtual-camera parameters for the image are adjusted and refined, with the <i>while</i>-loop iterating for <i>N</i> iterations. The adjustment and refinement process is non-convex, as a result of which the process does not necessarily converge. In step 805, a first virtual-camera-parameters adjustment method is invoked to make relatively coarse adjustments to the initial virtual-camera parameters. In step 806, a second virtual-camera-parameters adjustment method is invoked to more finely adjust the virtual-camera parameters for the image. In step 807, a first virtual-camera-parameters refinement method is invoked to refine the virtual-camera parameters associated with the image and, in step 808, a second virtual-camera-parameters refinement procedure is invoked to refine the virtual-camera-parameters associated with the image. In step 809, the iteration variable <i>N</i> is decremented. When <i>N</i> is greater than 0, as determined in step 810, then the <i>while</i>-loop of steps 804-810 continues to iterate. Otherwise, in step 811, a final refinement method is called to adjust the virtual-camera parameters for the image. Note that, through the various steps and iterations, the virtual-camera parameters associated with an image are generally continuously adjusted and refined towards a set of virtual-camera parameters that best estimates the position, orientation, and focal length of the dental practitioner's camera, with respect to the patient's teeth, used to initially capture the input image.

0020<figref idref="f0017">Figure 9</figref> provides a control-flow diagram for the initial virtual-camera-parameters-adjustment method invoked in step 805 of <figref idref="f0016">Figure 8</figref>. In step 902, the method uses metadata associated with the image to select a value of an iteration variable <i>M</i>, in similar fashion to the selection of a value for the iteration variable N in step 803 in <figref idref="f0016">Figure 8</figref>, and a set of entries <i>resultSet</i> is initialized to be empty. In step 904, the initial virtual-camera-parameters-adjustment method applies thresholding to each pixel color/intensity value within the image to generate a teeth mask, <i>TM,</i> for the image. When the pixels are encoded in the Lab color model, the <i>a</i> color component of the pixel color/intensity value is thresholded. The Lab color model is a color-opponent space with dimension <i>L</i> for lightness and color-opponent dimensions <i>a</i> and <i>b,</i> based on nonlinearly compressed color space coordinates, such as International Commission on Illumination ("CIE") XYZ color space coordinates. When other color-model encodings are used for pixel colors and intensities, other components or values derived from one or more components of the pixel color/intensity values are thresholded. The elements corresponding to image pixels in the teeth mask <i>TM</i> are associated with one of two binary values to indicate whether the pixel or element corresponds to a tooth region or a non-tooth region within the image. In step 906, a similar teeth mask, <i>TM',</i> is generated from the time-projected three-dimensional using the current virtual-camera parameters for the two-dimensional input image from which teeth mask <i>TM</i> was produced. In step 908, a distance transform of teeth mask <i>TM, TM_dt,</i> is generated. In step 910, the method searches for a minimal-cost overlay of teeth mask <i>TM'</i> onto the distance transform of <i>TM, TM_dt,</i> with the search carried out over various rotations and scale factors of the teeth mask <i>TM'</i> with respect to the distance transform <i>TM_dt.</i> In step 912, adjustments to the virtual-camera parameters for the currently considered two-dimensional image are computed in order to generate a new two-dimensional image from the three-dimensional model and a new teeth mask <i>TM'</i> that correspond to the minimal-cost overlay of the previously computed <i>TM'</i> onto <i>TM_dt.</i> In step 914, a cost of the new <i>TM'</i> teeth mask with respect to <i>TM_dt</i> is computed. The adjusted virtual-camera parameters and computed cost, obtained in steps 912 and 914, are stored as a next entry in the set variable <i>resultSet,</i> in step 916. In step 917, iteration variable <i>M</i> is decremented. When <i>M</i> is still greater than 0, as determined in step 918, control returns to step 906 for an additional iteration of the virtual-camera-parameters adjustment. Otherwise, in step 920, the minimal-cost entry in <i>resultSet</i> is selected and the virtual-camera parameters associated with the two-dimensional image are set to the virtual-camera parameters in the selected entry.

0021<figref idref="f0018 f0020">Figures 10A-C</figref> provide additional details with regard to steps 904, 908, and 912 of <figref idref="f0017">Figure 9</figref>. <figref idref="f0018">Figure 10A</figref> illustrates the thresholding step 904 in <figref idref="f0017">Figure 9</figref>. A small hypothetical portion of an image 1002 is shown as the original image in <figref idref="f0018">Figure 10A</figref>. Each pixel in the original image is shown to have an intensity/color-component value. In the thresholding operation, those pixels with intensity/color-component values less than a threshold value, in the current hypothetical case 5, are assigned to the value 1 and all other pixels are assigned to the value 0. In one implementation, the threshold value is determined using well-known Otsu's well-known thresholding method, in which image pixels are partitioned into two classes on the assumption that the intensity-value distribution of the pixels can be modeled as a bi-modal distribution. Otsu's method seeks a threshold that minimizes the intra-class variance, which is the weighted sum of the intensity-value variances of the two classes. Pixels assigned the value 1 are considered to be tooth-region pixels and the other pixels are considered to be non-tooth-region pixels. Thus, in the thresholded image 1004, a small interior region 1006 corresponds to teeth. In addition, there are two small, teeth-like regions 1008 and 1010 adjacent to the edge of the image. In a next step, any of the teeth regions adjacent to the edge are backfilled with 0 values, since the teeth should not be at the borders of the photographs according to the procedures and protocols for taking photographs by the dental practitioner. A final step, not shown in <figref idref="f0018">Figure 10A</figref>, reconsiders 0-backfilled regions to ensure that teeth-like regions have not been inadvertently back filled. The result of the next step is a tooth mask 1012 with an interior tooth-corresponding region 1014 with 1-valued pixels and an outer region with 0 value corresponding to non-tooth regions 1016.

0022<figref idref="f0019">Figure 10B</figref> illustrates the computation of a distance transform of one mask in computing the cost of an overlay of a second mask onto this distance transform. A first mask 1020 is shown in <figref idref="f0019">Figure 10B</figref>. The outer portion of the mask 1022 is shown in grid lines and has one of two binary values and an interior portion of the mask 1024 is shown without grid lines and each element or pixel in the interior portion has the other of the two binary values. A second mask 1026 is shown below the first mask. Note that the interior region of the second mask 1028 is differently shaped in size than the interior region 1024 of the first mask 1020. A distance transformation transforms the first mask 1020 into a first-mask distance transform 1030. In this transformation, the value of the elements or pixels in the first mask are replaced by the distance, in elements or pixels, that needs to be traversed from the element to the boundary between the outer and inner portions of the first mask. For example, from pixel 1032, no other pixels or elements need to be traversed in order to reach the boundary 1034 of the inner and outer mask regions, and therefore pixel or element 1032 has value 0 in the distance transform. Many different types of distance metrics can be used, including Euclidian distance, city-block distance, and other such distances. In the right-hand corner of <figref idref="f0019">Figure 10B</figref>, the second mask 1026 is rotated with respect to the distance transform of the first mask 1030 and overlaid on top of the distance transform of the first mask to produce an overlay 1040. In the search for the minimal cost or best overlay of <i>TM'</i> with respect to <i>TM_dt,</i> in step 910 of <figref idref="f0017">Figure 9</figref>, a state space search is carried out in which various possible rotations and translations of the second mask are considered with respect to the distance transform of the first mask for various different scales, or sizings, of the second mask. The cost for a particular overlay, such as overlay 1040, is computed as the sum of the values of the elements in the distance transform underlying the interior region 1028 of the second mask, as indicated 1042 in <figref idref="f0019">Figure 10B</figref> below the overlay 1040.

0023<figref idref="f0020">Figure 10C</figref> illustrates certain of the adjustments of the virtual-camera parameters in order to create a projected image from which a new <i>TM'</i> that corresponds to a minimal-cost overlay of the <i>TM'</i> over the distance transform can be prepared. The adjustments include adjusting the position or center of the virtual camera 1060, adjusting the roll and yaw angles of the virtual camera 1062 and 1064, and adjusting the focal length or distance of the virtual camera from the surface of the 3D model 1066. The adjustments alter one or more of the shape, size, and orientation of the inner teeth region of the previous <i>TM'</i> so that a minimal-cost overlay of the new <i>TM'</i> is obtained. First, the camera is rotated 1060 so that the center of mass of the two masks, <i>TM</i> and <i>TM',</i> coincide. For this purpose, two vectors are constructed in a coordinate system with an origin coincident with the camera position. The two vectors include a first vector that describes the position of the <i>TM</i> center of mass and a second vector that describes the position of the <i>TM'</i> center of mass. The camera is rotated about a rotation axis coincident with the vector obtained as the cross-product of the first and second vectors. The camera roll angle is adjusted 1062, for front or side views only, by fitting straight lines through both teeth masks and rotating camera around the z axis (346 in <figref idref="f0005">Figure 3B</figref>) so that the lines are parallel. To modify the area of mask <i>TM'</i> 1066, the camera is moved closer or further from the three-dimensional model. A coefficient <i>K</i> controls this movement. When <i>K ></i> 1, the camera is moved away from the three-dimensional model. Otherwise, the camera is moved closer to the three-dimensional model. Coefficient <i>K</i> is found using an empirical formula <maths id="math0006"><math display="block"><mi>K</mi><mo>=</mo><mn>1</mn><mo>+</mo><mfrac><mn>1</mn><mn>2</mn></mfrac><mfenced><mroot><mfrac><mfenced open="|" close="|"><mi mathvariant="italic">TM</mi><mo>′</mo></mfenced><mfenced open="|" close="|"><mi mathvariant="italic">TM</mi></mfenced></mfrac><mn>4</mn></mroot><mo>−</mo><mn>1</mn></mfenced><mo>,</mo></math><img file="EP3338245B1_D0006.tif" /></maths> where |<i>TM</i>| and |<i>TM'</i>| are the areas, in pixels, of the two masks <i>TM</i> and <i>TM',</i> respectively. Adjustment of the yaw angle 1064 is carried for front or side views, but not for occlusal views. The yaw angle is computed using parameters of parabolas that are fitted through masks and an empirical formula for computing of the yaw angle in radians, provided below: <maths id="math0007"><math display="block"><mi>y</mi><mo>=</mo><msub><mi>a</mi><mn>1</mn></msub><msup><mi>x</mi><mn>2</mn></msup><mo>+</mo><msub><mi>b</mi><mn>1</mn></msub><mi>x</mi><mo>+</mo><msub><mi>c</mi><mn>1</mn></msub><mo>,</mo></math><img file="EP3338245B1_D0007.tif" /></maths> where <i>x, y</i> ∈ <i>TM,</i><maths id="math0008"><math display="block"><mi>y</mi><mo>=</mo><msub><mi>a</mi><mn>2</mn></msub><msup><mi>x</mi><mn>2</mn></msup><mo>+</mo><msub><mi>b</mi><mn>2</mn></msub><mi>x</mi><mo>+</mo><msub><mi>c</mi><mn>2</mn></msub><mo>,</mo></math><img file="EP3338245B1_D0008.tif" /></maths> where <i>x, y</i> ∈ <i>TM',</i><maths id="math0009"><math display="block"><mi mathvariant="italic">yaw</mi><mspace width="1ex" /><mi mathvariant="italic">angle</mi><mo>=</mo><mfrac><mn>1</mn><mn>2</mn></mfrac><msqrt><mfenced open="|" close="|"><msub><mi>a</mi><mn>1</mn></msub><mo>−</mo><msub><mi>a</mi><mn>2</mn></msub></mfenced></msqrt><mo>∗</mo><mi mathvariant="italic">sign</mi><mfenced><msub><mi>a</mi><mn>1</mn></msub><mo>−</mo><msub><mi>a</mi><mn>2</mn></msub></mfenced><mo>.</mo></math><img file="EP3338245B1_D0009.tif" /></maths>

0024<figref idref="f0021">Figure 11</figref> shows the second virtual-camera-parameters adjustment method invoked in step 806 of <figref idref="f0016">Figure 8</figref>. In step 1102, the metadata associated with the image is used to determine a value for an iteration variable <i>N.</i> Then, in the <i>for-</i>loop of steps 1104-1107, each of the two jaws of the dental patient, and their associated teeth, are considered. In step 1105, the jaw and associated teeth that are not currently considered are removed from the image and from current consideration. Then, in step 1106, the virtual-camera parameters associated with the image are optimized for that portion of the image corresponding to the currently considered jaw and associated teeth.

0025<figref idref="f0022">Figure 12</figref> provides a control-flow diagram for the optimization step 1106 in <figref idref="f0021">Figure 11</figref>. In step 1202, an initial value of a variable <i>cost</i> is set to a large number and the variables <i>p</i> and <i>q</i> are both set to the current virtual-camera parameters. Then, in the <i>while</i>-loop of steps 1204-1212, an optimization method is used to find an optimized set of virtual-camera parameters for the currently considered image. The <i>while</i>-loop iterates over a number of iterations indicated by the iteration variable <i>N</i>, determined in step 1102 of <figref idref="f0021">Figure 11</figref>. In step 1205, a two-dimensional image is generated from the three-dimensional model using the virtual-camera parameters <i>q.</i> In step 1206, a gradient-based <i>cost</i> is computed for this generated two-dimensional image with respect to the currently considered input image. When the new gradient-based cost is greater than the value stored in the variable <i>cost,</i> the virtual-camera parameters <i>p</i> are returned, in step 1208, since these parameters correspond at least to a local minimum discovered in the previous iteration of the <i>while</i>-loop. Otherwise, the value of the variable <i>cost</i> is set to the new cost computed in step 1206 and the virtual-camera parameters <i>p</i> are set to <i>q,</i> in step 1209. In step 1210, the virtual-camera parameters <i>q</i> are perturbed in the direction of minimizing the cost within certain predefined limits. In step 1211, the iteration variable <i>N</i> is decremented. When the iteration variable <i>N</i> is greater than or equal to 0, as determined in step 1212, control returns to step 1205 for another iteration of the <i>while</i>-loop. Otherwise, the current virtual-camera parameters <i>p</i> are returned, in step 1213. The optimization approach illustrated in <figref idref="f0022">Figure 12</figref> is used subsequently for numerous steps, described below.

0026In one implementation, a Nelder-Mead downhill simplex optimization method is employed, with seven dimensions, including three rotations, three translations, and the virtual-camera view angle. In this method, a simplex with <i>n</i> + 1 vertices in <i>n</i> dimensions, for a problem in <i>n</i> variables, is used, with test points corresponding to the vertices. The test points are replaced in a way that conserves the volume of the simplex but moves and deforms the simplex toward a local optimum. There are many variations of the Nelder-Mead downhill simplex optimization method, and many additional optimization methods that may be employed to optimize the virtual-camera parameters.

0027<figref idref="f0023 f0025">Figures 13A-C</figref> illustrate computation of a gradient-based cost. A small portion of the pixels in image 1302 are shown at the top of <figref idref="f0023 f0024 f0025">Figure 13</figref>. The pixels are cells within a grid, such as the cell 1304 with grid coordinates (<i>x,y</i>). The gradient at the location of a pixel (<i>x,y</i>) in an image <i>f</i> is a vector 1306 that can be estimated from a discrete pixel-intensity computation 1308. Thus, the gradient vector ∇<i>f</i>(<i>x,y</i>) can be computed for each pixel or element of an image. The gradient vector 1310 for the pixel <i>f</i>(<i>x,y</i>) 1304 is shown as an example of a gradient associated with a pixel element. By computing the gradient at each pixel in an image, with different methods used to compute certain of the boundary-pixel gradient vectors, an image can be transformed into a vector field. Two images can be compared by computing a comparison value based, in part, on a comparison of the gradient-vector fields of the two images.

0028<figref idref="f0024">Figure 13B</figref> illustrates generation of histograms for the intensity values of two images that are to be compared. The probability that a randomly selected pixel from the images has a particular intensity value can be computed from pixel-intensity histograms. In <figref idref="f0024">Figure 13B</figref>, two images 1320 and 1322 are shown. Image 1320 is referred to as image <b>I</b>₁ and image 1322 is referred to as image <b>I</b>₂. As usual, the pixels within the images are shown as rectangular or square cells and the cells are associated with coordinates with respect to x 1324-1325 and <i>y</i> 1326 and 1327 axes. Each pixel is associated with an intensity value. The intensity value may have different components, depending on the color model used to encode the colors and intensities of the pixel, or may be associated with a single intensity derived from the multiple color/intensity components associated with a pixel. In one implementation, each pixel is associated with an averaged intensity that represents the average of three color-channel intensities. The intensity for a pixel with coordinates (<i>x, y</i>) of image <b>I</b>₁ is denoted as <b>I</b>₁(<i>x</i>, <i>y</i>). For example, the intensity of cell 1328 is <b>I</b>₁(4, 12). Histograms 1330-1332 are be prepared from the intensity values of the pixels of the individual images <b>I</b>₁ and <b>I</b>₂ and for the combination of the two images. For example, histogram 1330 is prepared from image <b>I</b>₁. The horizontal axis 1335 of the histogram is incremented in increasing intensity values and the vertical axis 1336 represents the number of pixels in the image having a particular intensity value. Of course, the histograms may be computationally represented by arrays of pixel counts indexed by intensity values. Histogram 1331 is prepared, in similar fashion, from image <b>I</b>₂ 1322. The joint histogram 1332 is a histogram showing the number of matching or aligned pixels, in the two images <b>I</b>₁ and <b>I</b>₂, having a particular ordered pair of intensity values. The horizontal axis 1338 of the joint-image histogram 1332 is incremented in pairs of intensity values and the vertical axis 1339 represents the number of equivalent, aligned pixel pairs having a particular ordered pair of intensities. One pixel of each pair of pixels is selected from the first of the two images and the other pixel of each pair of pixels is selected from the second of the two images, with both pixels of each pair having the same <i>(x, y)</i> coordinates. The histograms can be thought of as discrete probability distributions. For example, the probability that a randomly selected pixel from image <b>I</b>₁ has the intensity value 10 1340 can be computed as the number of pixels in image <b>I</b>₁ with intensity value 10 1342 divided by the number of pixels in image <b>I</b>₁ 1344. In similar fashion, the probability that two aligned and matching pixels and images <b>I</b>₁ and <b>I</b>₂ have a particular ordered pair of intensity values 1346 is computed as the ratio of the number of pixels of the two images having the ordered pair of intensity values divided by the total number of the pixels in each of the two images 1348.

0029As shown in <figref idref="f0025">Figure 13C</figref>, the intensity probabilities computed for randomly selected pixels of the two images <b>I</b>₁ and <b>I</b>₂ and joint intensity probabilities for pairs of matching pixels selected from the two images can be represented by alternative, simpler notation 1350. Using this notation, the expressions 1352 show calculation of the Shannon entropy H₁, H₂, and H_1,2 for image <b>I</b>₁, image <b>I</b>₂, and the combination of images <b>I</b>₁ and <b>I</b>₂, respectively. The mutual information for the two images <b>I</b>₁ and <b>I</b>₂, MI(<b>I</b>₁, <b>I</b>₂) is then computed, as shown in Figure 1354. from the entropies computed in expressions 1352. A variety of alternative expressions for MI(<b>I</b>₁, <b>I</b>₂) in terms of entropies, joint entropies, and conditional entropies can instead be used to compute MI(<b>I</b>₁, <b>I</b>₂). A cost function that represents a comparison value for two images <b>I</b>₁ and <b>I</b>₂ is then computed as the negative of the mutual information of the two images multiplied by a computed value G(<b>I</b>₁, <b>I</b>₂), as shown in expression 1356. The computed value G(<b>I</b>₁, <b>I</b>₂) is, as shown in expression 1358, computed as the sum of a function <i>f</i> () computed over all of the pixels of the images. The function <i>f</i> () takes, as arguments, the gradients computed for each pixel (<i>x, y</i>) for the two images and the value in the teeth mask computed for the first of the two images. As shown in expression 1360, the function <i>f</i> () has the value <maths id="math0010"><math display="inline"><mi>cos</mi><mfenced><mi mathvariant="bold-italic">a</mi><mi mathvariant="bold-italic">b</mi></mfenced><mo>∗</mo><msqrt><mrow><mi>min</mi><mfenced><mfenced open="|" close="|"><mi mathvariant="bold-italic">a</mi></mfenced><mfenced open="|" close="|"><mi mathvariant="bold-italic">b</mi></mfenced></mfenced></mrow></msqrt></math><img file="EP3338245B1_D0010.tif" /></maths> when the pixel to which the function is applied is a member of a teeth region in the mask and is otherwise 0. The cost-function value is minimized, by optimization methods discussed above with reference to <figref idref="f0022">Figure 12</figref>.

0030<figref idref="f0026">Figure 14</figref> provides a control-flow diagram for the first virtual-camera-parameters refinement method called in step 807 of <figref idref="f0016">Figure 8</figref>. In step 1402, the metadata associated with the currently considered input image is used to determine the value for an iteration variable <i>N</i> and a set variable <i>resultSet</i> is initialized to be empty. In step 1404, the current virtual-camera parameters for the image are stored. In an outer <i>for</i>-loop of steps 1406, each of the patient's two jaws and associated teeth are separately considered in two iterations. In the inner <i>for</i>-loop of steps 1407-1411, each tooth group of the currently considered jaw is considered. The rest of the image other than the currently considered tooth group is masked out of the image, in step 1408. Then, in step 1409, an optimization procedure equivalent to the optimization procedure discussed above with reference to <figref idref="f0022">Figure 12</figref> is used to optimize the virtual-camera parameters for the currently considered input image. In step 1410, the optimized virtual-camera parameters are stored as a next entry in the set <i>resultSet</i> produced by the inner and outer <i>for</i>-loops of steps 1406-1413. Finally, in step 1411, the current virtual-camera parameters are reset to the stored virtual-camera parameters, stored in step 1404. Following termination of the two nested loops in steps 1406-1413, a refined virtual-camera parameter is computed from the entries stored in the set <i>resultSet</i> by the two nested loops, in step 1414. This computation may involve illuminating outlying results from the results set and then averaging or using a weighted average on the remaining results of the results set. Then, in step 1415, the virtual-camera parameters for the currently considered input image are set to the refined virtual-camera parameters determined in step 1414.

0031<figref idref="f0027">Figure 15</figref> illustrates examples of the tooth groups over which the inner loop of the method illustrated in <figref idref="f0026">Figure 14</figref> iterates. At the top of <figref idref="f0027">Figure 15</figref>, a chart indicating the universal numeric code for human teeth is provided 1502. Example tooth groups are shown below the chart, such as example tooth group 1504 consisting of the four teeth 7, 8, 9, and 10. Various different partitionings of teeth into tooth groups can be employed for deriving the multiple iterations of the inner loop of the nested <i>for</i>-loops discussed above with reference to <figref idref="f0026">Figure 14</figref>.

0032The current discussion has been proceeding through the steps shown in <figref idref="f0016">Figure 8</figref>. The second virtual-camera-parameters refinement method, invoked in step 808, uses an optimization method similar to that discussed above with reference to <figref idref="f0022">Figure 12</figref> on the full complement of teeth. The final refinement method, invoked in step 811 of <figref idref="f0016">Figure 8</figref>, is similar to the method invoked in step 808, with the exception that the cost is computed from a consideration of the second derivatives of the images at the image elements, or Laplacian vectors, rather than the first derivatives, or gradient vectors. <figref idref="f0028">Figure 16</figref> illustrates, using the same illustration conventions as used in <figref idref="f0023 f0024 f0025">Figure 13</figref>, computation of the Laplacian vectors for image elements and generation of a Laplacian-vector field.

0033As discussed above with reference to <figref idref="f0012">Figures 5D</figref> and <figref idref="f0017">9</figref>, once all the input images are associated with finally refined virtual-camera parameters, a comparison is made between each input image and a corresponding image generated from the three-dimensional model in order to generate a comparison value or correlation coefficient. <figref idref="f0029 f0030">Figures 17A-B</figref> illustrate computation of the comparison value or correlation coefficient. As shown in <figref idref="f0029 f0030">Figure 17</figref>, a two-dimensional image 1702 <b>I</b>_s is generated from the three-dimensional model 1704 using the virtual-camera parameters determined, as discussed above with reference to <figref idref="f0016">Figure 8</figref>, for a corresponding input image <b>I</b>_p 1708. Next, a contour line that encloses the teeth in the image is generated 1706. This contour line is then overlaid or superimposed over the original input image 1708 to produce an overlaid image 1710. As shown in <figref idref="f0029">Figure 17A</figref> in inset 1712, for each pixel (<i>x, y</i>) lying along the contour line 1714, a small square, rectangular, or other compact region 1716, ε<i>_x,y,</i> can be constructed. The comparison values generated from the overlaid image 1710 involve computing the cost of the pixels that lie along the contour in both the input image <b>I</b>_p and the image generated from the three-dimensional model <b>I</b>_s. The cost for a contour-overlapping pixel (<i>x, y</i>) is computed as shown in expression 1720 in <figref idref="f0030">Figure 17B</figref>. When the absolute values or magnitudes of the gradients for pixel (<i>x, y</i>) in both images is greater than a threshold <i>T,</i> which has the value 3 in one implementation, the cost for the pixel is the dot product of the gradients for the pixel in the two images divided by the product of the magnitudes of the two gradients. Otherwise, the cost is 0. A fitness or similarity metric can be computed, as shown in Figure 1722, as the sum of the costs of the pixels lying along the contour divided by the length of the contour, in pixels. An alternative fitness or similarity metric is shown in expression 1724. In the alternative fitness value, the cost for the two images is computed as the sum of the cost of the pixels along the contour divided by the sum of the maximum cost of any pixel in the region ε<i>_x,y</i> for each of the pixels in the two images (<i>x, y</i>). This alternative metric has greater reliability when input images are slightly blurred by applying a Gaussian filter. Either fitness value or a linear combination of the two fitness values may be used as the computed similarity metric or correlation coefficient for the comparison of the two images.

0034It should be noted that, in general, color images are processed by the monitoring method. When gradients and Laplacian vectors are computed, they are computed based on an overall luminance or intensity computed from the three different color values of whatever color scheme is used to encode the images.

0035<figref idref="f0031">Figure 18</figref> provides a general architectural diagram for various types of computers, including computers used to implement dental-treatment monitoring systems. The computer system contains one or multiple central processing units ("CPUs") 1802-1805, one or more electronic memories 1808 interconnected with the CPUs by a CPU/memory-subsystem bus 1810 or multiple busses, a first bridge 1812 that interconnects the CPU/memory-subsystem bus 1810 with additional busses 1814 and 1816, or other types of high-speed interconnection media, including multiple, high-speed serial interconnects. These busses or serial interconnections, in turn, connect the CPUs and memory with specialized processors, such as a graphics processor 1818, and with one or more additional bridges 1820, which are interconnected with high-speed serial links or with multiple controllers 1822-1827, such as controller 1827, that provide access to various different types of mass-storage devices 1828, electronic displays, input devices, and other such components, subcomponents, and computational resources. It should be noted that computer-readable data-storage devices include optical and electromagnetic disks, electronic memories, and other physical data-storage devices. Those familiar with modern science and technology appreciate that electromagnetic radiation and propagating signals do not store data for subsequent retrieval, and can transiently "store" only a byte or less of information per mile, far less information than needed to encode even the simplest of routines.

0036Of course, there are many different types of computer-system architectures that differ from one another in the number of different memories, including different types of hierarchical cache memories, the number of processors and the connectivity of the processors with other system components, the number of internal communications busses and serial links, and in many other ways. However, computer systems generally execute stored programs by fetching instructions from memory and executing the instructions in one or more processors.

0037<figref idref="f0032">Figure 19</figref> illustrates an Internet-connected distributed computer system. As communications and networking technologies have evolved in capability and accessibility, and as the computational bandwidths, data-storage capacities, and other capabilities and capacities of various types of computer systems have steadily and rapidly increased, much of modern computing now generally involves large distributed systems and computers interconnected by local networks, wide-area networks, wireless communications, and the Internet. <figref idref="f0032">Figure 19</figref> shows a typical distributed system in which a large number of PCs 1902-1905, a high-end distributed mainframe system 1910 with a large data-storage system 1912, and a large computer center 1914 with large numbers of rack-mounted servers or blade servers all interconnected through various communications and networking systems that together comprise the Internet 1916. Such distributed computing systems provide diverse arrays of functionalities. For example, a PC user sitting in a home office may access hundreds of millions of different web sites provided by hundreds of thousands of different web servers throughout the world and may access high-computational-bandwidth computing services from remote computer facilities for running complex computational tasks.

0038Until recently, computational services were generally provided by computer systems and data centers purchased, configured, managed, and maintained by service-provider organizations. For example, an e-commerce retailer generally purchased, configured, managed, and maintained a data center including numerous web servers, back-end computer systems, and data-storage systems for serving web pages to remote customers, receiving orders through the web-page interface, processing the orders, tracking completed orders, and other myriad different tasks associated with an e-commerce enterprise.

0039<figref idref="f0033">Figure 20</figref> illustrates cloud computing. In the recently developed cloud-computing paradigm, computing cycles and data-storage facilities are provided to organizations and individuals by cloud-computing providers. In addition, larger organizations may elect to establish private cloud-computing facilities in addition to, or instead of, subscribing to computing services provided by public cloud-computing service providers. In <figref idref="f0033">Figure 20</figref>, a system administrator for an organization, using a PC 2002, accesses the organization's private cloud 2004 through a local network 2006 and private-cloud interface 2008 and also accesses, through the Internet 2010, a public cloud 2012 through a public-cloud services interface 2014. The administrator can, in either the case of the private cloud 2004 or public cloud 2012, configure virtual computer systems and even entire virtual data centers and launch execution of application programs on the virtual computer systems and virtual data centers in order to carry out any of many different types of computational tasks. As one example, a small organization may configure and run a virtual data center within a public cloud that executes web servers to provide an e-commerce interface through the public cloud to remote customers of the organization, such as a user viewing the organization's e-commerce web pages on a remote user system 2016.

0040Cloud-computing facilities are intended to provide computational bandwidth and data-storage services much as utility companies provide electrical power and water to consumers. Cloud computing provides enormous advantages to small organizations without the resources to purchase, manage, and maintain in-house data centers. Such organizations can dynamically add and delete virtual computer systems from their virtual data centers within public clouds in order to track computational-bandwidth and data-storage needs, rather than purchasing sufficient computer systems within a physical data center to handle peak computational-bandwidth and data-storage demands. Moreover, small organizations can completely avoid the overhead of maintaining and managing physical computer systems, including hiring and periodically retraining information-technology specialists and continuously paying for operating-system and database-management-system upgrades. Furthermore, cloud-computing interfaces allow for easy and straightforward configuration of virtual computing facilities, flexibility in the types of applications and operating systems that can be configured, and other functionalities that are useful even for owners and administrators of private cloud-computing facilities used by a single organization.

0041<figref idref="f0034">Figure 21</figref> illustrates generalized hardware and software components of a general-purpose computer system, such as a general-purpose computer system having an architecture similar to that shown in <figref idref="f0001">Figure 1</figref>. The computer system 2100 is often considered to include three fundamental layers: (1) a hardware layer or level 2102; (2) an operating-system layer or level 2104; and (3) an application-program layer or level 2106. The hardware layer 2102 includes one or more processors 2108, system memory 2110, various different types of input-output ("I/O") devices 2110 and 2112, and mass-storage devices 2114. Of course, the hardware level also includes many other components, including power supplies, internal communications links and busses, specialized integrated circuits, many different types of processor-controlled or microprocessor-controlled peripheral devices and controllers, and many other components. The operating system 2104 interfaces to the hardware level 2102 through a low-level operating system and hardware interface 2116 generally comprising a set of non-privileged computer instructions 2118, a set of privileged computer instructions 2120, a set of non-privileged registers and memory addresses 2122, and a set of privileged registers and memory addresses 2124. In general, the operating system exposes non-privileged instructions, non-privileged registers, and non-privileged memory addresses 2126 and a system-call interface 2128 as an operating-system interface 2130 to application programs2132-2136 that execute within an execution environment provided to the application programs by the operating system. The operating system, alone, accesses the privileged instructions, privileged registers, and privileged memory addresses. By reserving access to privileged instructions, privileged registers, and privileged memory addresses, the operating system can ensure that application programs and other higher-level computational entities cannot interfere with one another's execution and cannot change the overall state of the computer system in ways that could deleteriously impact system operation. The operating system includes many internal components and modules, including a scheduler 2142, memory management 2144, a file system 2146, device drivers 2148, and many other components and modules. To a certain degree, modern operating systems provide numerous levels of abstraction above the hardware level, including virtual memory, which provides to each application program and other computational entities a separate, large, linear memory-address space that is mapped by the operating system to various electronic memories and mass-storage devices. The scheduler orchestrates interleaved execution of various different application programs and higher-level computational entities, providing to each application program a virtual, stand-alone system devoted entirely to the application program. From the application program's standpoint, the application program executes continuously without concern for the need to share processor resources and other system resources with other application programs and higher-level computational entities. The device drivers abstract details of hardware-component operation, allowing application programs to employ the system-call interface for transmitting and receiving data to and from communications networks, mass-storage devices, and other I/O devices and subsystems. The file system 2136 facilitates abstraction of mass-storage-device and memory resources as a high-level, easy-to-access, file-system interface. Thus, the development and evolution of the operating system has resulted in the generation of a type of multi-faceted virtual execution environment for application programs and other higher-level computational entities.

0042While the execution environments provided by operating systems have proved to be an enormously successful level of abstraction within computer systems, the operating-system-provided level of abstraction is nonetheless associated with difficulties and challenges for developers and users of application programs and other higher-level computational entities. One difficulty arises from the fact that there are many different operating systems that run within various different types of computer hardware. In many cases, popular application programs and computational systems are developed to run on only a subset of the available operating systems, and can therefore be executed within only a subset of the various different types of computer systems on which the operating systems are designed to run. Often, even when an application program or other computational system is ported to additional operating systems, the application program or other computational system can nonetheless run more efficiently on the operating systems for which the application program or other computational system was originally targeted. Another difficulty arises from the increasingly distributed nature of computer systems. Although distributed operating systems are the subject of considerable research and development efforts, many of the popular operating systems are designed primarily for execution on a single computer system. In many cases, it is difficult to move application programs, in real time, between the different computer systems of a distributed computer system for high-availability, fault-tolerance, and load-balancing purposes. The problems are even greater in heterogeneous distributed computer systems which include different types of hardware and devices running different types of operating systems. Operating systems continue to evolve, as a result of which certain older application programs and other computational entities may be incompatible with more recent versions of operating systems for which they are targeted, creating compatibility issues that are particularly difficult to manage in large distributed systems.

0043For all of these reasons, a higher level of abstraction, referred to as the "virtual machine," has been developed and evolved to further abstract computer hardware in order to address many difficulties and challenges associated with traditional computing systems, including the compatibility issues discussed above. <figref idref="f0035 f0036">Figures 22A-B</figref> illustrate two types of virtual machine and virtual-machine execution environments. <figref idref="f0035 f0036">Figures 22A-B</figref> use the same illustration conventions as used in <figref idref="f0034">Figure 21</figref>. <figref idref="f0035">Figure 22A</figref> shows a first type of virtualization. The computer system 2200 in <figref idref="f0035">Figure 22A</figref> includes the same hardware layer 2202 as the hardware layer 2102 shown in <figref idref="f0034">Figure 21</figref>. However, rather than providing an operating system layer directly above the hardware layer, as in <figref idref="f0034">Figure 21</figref>, the virtualized computing environment illustrated in <figref idref="f0035">Figure 22A</figref> features a virtualization layer 2204 that interfaces through a virtualization-layer/hardware-layer interface 2206, equivalent to interface 2116 in <figref idref="f0034">Figure 21</figref>, to the hardware. The virtualization layer provides a hardware-like interface 2208 to a number of virtual machines, such as virtual machine 2210, executing above the virtualization layer in a virtual-machine layer 2212. Each virtual machine includes one or more application programs or other higher-level computational entities packaged together with an operating system, referred to as a "guest operating system," such as application 2214 and guest operating system 2216 packaged together within virtual machine 2210. Each virtual machine is thus equivalent to the operating-system layer 2104 and application-program layer 2106 in the general-purpose computer system shown in <figref idref="f0034">Figure 21</figref>. Each guest operating system within a virtual machine interfaces to the virtualization-layer interface 2208 rather than to the actual hardware interface 2206. The virtualization layer partitions hardware resources into abstract virtual-hardware layers to which each guest operating system within a virtual machine interfaces. The guest operating systems within the virtual machines, in general, are unaware of the virtualization layer and operate as if they were directly accessing a true hardware interface. The virtualization layer ensures that each of the virtual machines currently executing within the virtual environment receive a fair allocation of underlying hardware resources and that all virtual machines receive sufficient resources to progress in execution. The virtualization-layer interface 2208 may differ for different guest operating systems. For example, the virtualization layer is generally able to provide virtual hardware interfaces for a variety of different types of computer hardware. This allows, as one example, a virtual machine that includes a guest operating system designed for a particular computer architecture to run on hardware of a different architecture. The number of virtual machines need not be equal to the number of physical processors or even a multiple of the number of processors.

0044The virtualization layer includes a virtual-machine-monitor module 2218 ("VMM") that virtualizes physical processors in the hardware layer to create virtual processors on which each of the virtual machines executes. For execution efficiency, the virtualization layer attempts to allow virtual machines to directly execute non-privileged instructions and to directly access non-privileged registers and memory. However, when the guest operating system within a virtual machine accesses virtual privileged instructions, virtual privileged registers, and virtual privileged memory through the virtualization-layer interface 2208, the accesses result in execution of virtualization-layer code to simulate or emulate the privileged resources. The virtualization layer additionally includes a kernel module 2220 that manages memory, communications, and data-storage machine resources on behalf of executing virtual machines ("VM kernel"). The VM kernel, for example, maintains shadow page tables on each virtual machine so that hardware-level virtual-memory facilities can be used to process memory accesses. The VM kernel additionally includes routines that implement virtual communications and data-storage devices as well as device drivers that directly control the operation of underlying hardware communications and data-storage devices. Similarly, the VM kernel virtualizes various other types of I/O devices, including keyboards, optical-disk drives, and other such devices. The virtualization layer essentially schedules execution of virtual machines much like an operating system schedules execution of application programs, so that the virtual machines each execute within a complete and fully functional virtual hardware layer.

0045<figref idref="f0036">Figure 22B</figref> illustrates a second type of virtualization. In <figref idref="f0036">Figure 22B</figref>, the computer system 2240 includes the same hardware layer 2242 and software layer 2244 as the hardware layer 2102 shown in <figref idref="f0034">Figure 21</figref>. Several application programs 2246 and 2248 are shown running in the execution environment provided by the operating system. In addition, a virtualization layer 2250 is also provided, in computer 2240, but, unlike the virtualization layer 2204 discussed with reference to <figref idref="f0035">Figure 22A</figref>, virtualization layer 2250 is layered above the operating system 2244, referred to as the "host OS," and uses the operating system interface to access operating-system-provided functionality as well as the hardware. The virtualization layer 2250 comprises primarily a VMM and a hardware-like interface 2252, similar to hardware-like interface 2208 in <figref idref="f0035">Figure 22A</figref>. The virtualization-layer/hardware-layer interface 2252, equivalent to interface 2116 in <figref idref="f0034">Figure 21</figref>, provides an execution environment for a number of virtual machines 2256-2258, each including one or more application programs or other higher-level computational entities packaged together with a guest operating system.

0046Dental-monitoring systems may be implemented using single PCs or servers, may be implemented in distributed computing systems, or may be implemented using cloud-computing facilities. Similarly, practitioners may communicate with a dental-monitoring system using a PC, server, or many other processor-controlled devices, including tablets, lap tops, and smart phones.

0047Many different design and implementation parameters, including operating system, hardware platform, programming language, modular organization, control structures, data structures, and other such parameters may be varied to produce various alternative implementations. As another example, the two-dimensional images acquired from patients during treatments can be obtained by using any of a wide variety of different imaging devices, including two-dimensional digital cameras, three-dimensional digital cameras, film-based cameras with digital-conversion devices, and even non-optical imaging devices.

0048It is appreciated that the previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present disclosure. The invention is defined by the appended claims.