SYSTEM AND METHOD FOR HIGH QUALITY RENDERINGS OF SYNTHETIC VIEWS OF CUSTOM PRODUCTS

FIELD OF THE DISCLOSURE

[0001] One technical field of the disclosure is an approach for automatically configuring custom product options based on user actions monitored and tracked by collaborative computer platforms. Another technical field is tracking the user actions to generate options for customizing products available from the collaborative computer platforms and generating, based on the options, high quality renderings of synthetic views of custom products.

BACKGROUND

[0002] The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.

[0003] There are many systems on the market that are configured to offer the users the opportunity to order products having customized attributes. For example, in the case of the custom manufactured framed products such as photos, digital images, artwork, and other frameable products, the systems may offer the users the opportunity to order the images and frames having customized sizes and colors.

[0004] Customizing the products that have many customizable parameters may be quite challenging. The selection of customization values may have implications on the appearance of the final custom products and on the way that the final custom products are rendered. Therefore, the systems often provide the functionalities for displaying depictions, i.e., synthetic views, of the customized products to help the users to visualize their customized products before the users order the products.

[0005] Generally, synthetic views are digital depictions of the objects displayed on computer-based display devices. In the context of digital customization of products, it is useful to render synthetic views of the products before the products are manufactured. This allows a user to visually check the product features and decorations before actually ordering the product. The synthetic views are often a combination of imagery from digital photography. They may include, for example, digital markups and synthetic renderings derived from, for example, 2D, 2.5D and 3D geometry of the objects.

[0006] Algorithms for high quality digital rendering of geometry have been researched and studied for some time. They typically use simulation of light, texture, and color. Major advancements in this technology include work using Scanline Rendering, Binary Space partitioning, zBuffer, aBuffer, the Pixar’s Reyes rendering system (culminating in the Renderman tool), the wide availability of hardware supporting OpenGL and Direct3D, and improvements in hardware assisted ray-tracing, as implemented in, for example, Intel’s Embree rendering system.

[0007] Usually, the synthetic digital rendering methods may be grouped based on the application area, rendering speed, and quality needs. For example, the real-time rendering applications for simulation and games typically use carefully designed content and geometry rendered with optimized spatial partitioning on hardware using OpenGL or Direct3D. The rendering time for a frame in a real-time rendering application must be rapid, and usually, the latency appears to be a key barrier for supporting user interactions with the application.

[0008] In the entertainment industry, production of imagery for films and prints usually has strict requirements for the quality and creative control. Sometimes, it might be difficult to meet the high quality and artistic requirements. But even if those requirements are met, they are met at the expense of longer rendering times per image.

[0009] Rendering synthetic views for custom products falls between these two applications. Such renderings need to be crafted without the expense incurred by optimizing game assets and need to be performed as a user interacts with a product, longer than a twitch game, but much shorter than a movie frame. Therefore, there is a need for providing high quality rendering techniques for rendering synthetic views of custom products that provide relatively low latencies.

BRIEF DESCRIPTION OF DRAWINGS

[0010] FIG. 1 illustrates an example system for implementing a method for automatically configuring custom product options based on user actions, according to some embodiments; [0011] FIG. 2 illustrates an example processing flow for rendering synthetic views, according to some embodiments;

[0012] FIG. 3 illustrates an example of a user interface of a product customization system, according to some embodiments;

[0013] FIG. 4 illustrates an example processing flow for rendering synthetic images, according to some embodiments;

[0014] FIG. 5 is a block diagram that illustrates a computer system with which the techniques herein may be implemented.

DESCRIPTION OF EXAMPLE EMBODIMENTS

[0015] In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

[0016] Embodiments are described herein according to the following outline:

1.0 OVERVIEW

2.0 STRUCTURAL AND FUNCTIONAL OVERVIEW

3.0 SYNTHETIC VIEW RENDERING REQUIREMENTS

4.0 SYNTHETIC VIEW RENDERING PROCESS

4.1 GENERATING CALIBRATED PRODUCT RENDERING ASSETS

4.2 APPLYING USER-DRIVEN SETTINGS OF PRODUCT OPTION KEY- VALUES TO CALIBRATED PRODUCT RENDERING ASSETS

4.3 INITIATING THE RENDERING APPLICATION

4.4 RENDING THE ASSETS

4.5 DISPLAYING THE ASSETS

5.0 COVERAGE MAP SERVICE

6.0 COVERAGE BUFFER SERVICE

7.0 EXAMPLE METHOD FOR HIGH QUALITY RENDERINGS OF SYNTHETIC VIEWS OF CUSTOM PRODUCTS

8.0 EXAMPLE RENDERING FLOW 9.0 MANUFACTURING

10.0 IMPLEMENTATION MECHANISMS— HARDWARE OVERVIEW

11.0 EXTENSIONS AND ALTERNATIVES

*

[0017] 1.0 GENERAL OVERVIEW

[0018] In some embodiments, techniques are described for improving a product customization process. More specifically, the techniques are intended to improve a user product Tenderer used by the product customization process, and to produce a rendering of the products based on a high quality sub-pixel rendering. An example of the product customization process is described in, for example, US 8,175,931 B2, which includes a description of an example user product Tenderer in FIG. IB (element 109b), FIG. 1C (element 124), and FIG. 2 (element 134). The product customization process described in US 8,175,931 B2 does not, however, disclose the high quality sub-pixel rendering approach.

[0019] The techniques described herein provide a novel and improved method for high quality sub-pixel rendering of customized products where the high quality sub-pixel rendering is one of the critical requirements.

[0020] The system and method presented herein can be used to provide a high quality rendering of synthetic views of any custom product. The system and method can be implemented in software, hardware or a combination of hardware and software and may also be implemented on client/server system, a web server, a terminal, a peer to peer system and the like so that the system and method are not limited to the particular implementation of the system or method.

[0021] 2.0 STRUCTURAL OVERVIEW

[0022] FIG. 1 illustrates an example system for implementing a method for high quality renderings of synthetic views of custom products, according to some embodiments. FIG. 1, the other drawing figures, and all of the description and claims in this disclosure are intended to present, disclose, and claim a technical system and technical methods in which specially programmed computers, using a special-purpose distributed computer system design, execute functions that have not been available before to provide a practical application of computing technology to the problem of machine learning model development, validation, and deployment. In this manner, the disclosure presents a technical solution to a technical problem, and any interpretation of the disclosure or claims to cover any judicial exception to patent eligibility, such as an abstract idea, mental process, method of organizing human activity or mathematical algorithm, has no support in this disclosure and is erroneous.

[0023] The depicted example is provided for illustrative purposes. It should be noted that other implementations may include different configurations of the components than those shown in FIG. 1.

[0024] In the depicted example, a product synthetic view rendering platform 101 comprises a product options module 102, a customized product 104, a rendering engine 106, a user interface 108, a product options selector 110, a synthetic view generator 112, a product data definitions 114, a product options engine 116, and a product options framework 120. Other implementations may include additional components not depicted in FIG. 1. Yet other implementations may include fewer components than those depicted in FIG. 1.

[0025] Product options module 102 may be configured to provide the functionalities for generating, modifying, and integrating product options to customize a product, which then can be sent to synthetic view generator 112 of product synthetic view rendering platform 101 for rendering. Product options module 102 may include a product options framework.

[0026] In some embodiments, product options framework 120 may be configured to provide the framework for handling the product options. It can also facilitate access to a bundling framework providing the logic to support processing attributes that are dependent on values of other attributes. The framework allows accounting for the fact that certain accessories may not fit a particular product. The framework may also allow determining compatibility both in terms of product manufacturing and capabilities of digital images of products to be visualized or rendered on display units.

[0027] In some embodiments, product options module 102 includes a bundling framework. The bundling framework comprises logic to support accurate rendering of bundled products by determining which views of combined products are valid or should be shown in a graphical user interface or other displays. In general, when products are added to a bundle, the bundling logic is configured to examine each product, filter each product based on filters as previously described, and select and order one or more generated views based on matches of the filters.

[0028] Customized product 104 may be configured to store customized products data in product synthetic view rendering platform 101. For example, customized product 104 may capture data representing the customization options selected by a user as the user customizes the product using product synthetic view rendering platform 101 and the choices that the user makes as the user navigates through the product customization options.

[0029] Rendering engine 106 may be configured to execute a rendering logic. The rendering logic may be configured to accommodate product options and bundles. In an embodiment, the rendering logic supports defining rendering files and adding elements to the rendering logic using declarative statements rather than pure programming. Attributes of views may be declared in rendering files that serve as configuration files to drive rendering processes. In an embodiment, the capabilities of the rendering logic are matched to the bundles of products through other declaratory statements and the matching syntax that are described later.

[0030] User interface 108 may be configured to facilitate interactions between rendering platform 101 and users. In an embodiment, a product bundle is defined as an association of two or more products that can be visualized together in a graphical user interface and are compatible or can be ordered together for use together or in a combined custom manufactured product.

[0031] Product options selector 110 may be configured to provide the functionalities for tracking the options selected by users as the users navigate via the user interface driven by the application executing on product synthetic view rendering platform 101.

[0032] Synthetic view generator 112 may be configured to provide the functionalities for implementing a system and method for high quality rendering of synthetic view of custom product presented herein.

[0033] Product data definitions 114 may be configured to store and provide definitions of products and various customization options for the products. Product data definitions may be processed using an attribute engine and key-value pairs, described later.

[0034] Product options engine 116 may be configured to provide the functionalities for managing various options and option configuration for the product offered to the users.

[0035] 3.0 SYNTHETIC VIEW RENDERING REQUIREMENTS

[0036] In some embodiments, a product customization process permits a user to customize a product using functionalities available via a user interface. The interface may be implemented to generate and display one or more web pages on a user display device. The user interface may be configured to, for example, allow the user to interactively apply colors, tiled images, and photographic or designed images (e.g., user designed images) to a two dimensional pattern pieces that comprise the product, as described below in more detail.

[0037] Data generated by the user interface may include user account data, a product description (that describes the user's custom product), user image designs (that contains the user content), color choices (the colors chosen by the user), material choices (the type of materials for the custom product), and the finishing choices (the finishing selected by the user for the custom product). Based on that information, the user interface may assemble a set of instructions that describe the user design and request images of the final product from, for example, a user product Tenderer. The resulting interaction may be performed in real time. [0038] In some embodiments, a process of rendering synthetic views of one-of-a-kind products in response to user actions has a unique set of requirements. The requirements are typically separate from the real-time or production media rendering. Examples of the requirements include the following requirements:

1. Each individual request may require new assets, so caching of textures on graphics hardware may be associated with a high latency cost.

2. Each request breaks frame-to-frame coherence strategies for optimizing rendering.

3. Each custom product has different graphic characteristics, making the special case rendering and tuning used in games and simulations less effective.

4. Requirements for rendering time or pipe latency are based on product browsing timing rather than proving a smooth frame rate or optimizing rendering for a movie frame. Typically, the rendering time for a product view may be greater than the 1/60 sec render time for a simulation, and much less than the 20 minute render time typical for a frame of a feature film. Acceptable latencies may range from 1/15 sec to % sec.

5. Image quality is expected to be high since the image depiction directly impacts the user’s perception of the custom product.

6. Rendering with a high quality sub-pixel sampling is needed to resolve the complex product geometry and transparencies.

[0039] In some embodiments, the system and method described herein solve the requirements issues for high quality rendering at least for the last group of requirements, i.e., for the high quality sub-pixel rendering requirement. The solution allows resolving the complex product geometry and transparencies. The solution provides, among other things, a novel method for sampling sub-pixel geometry.

[0040] The presented system and method overcome the limitations of the low level rendering portions of the prior art, which tend to use implicit surface detection (as in Embree approach), use explicit subdivision into pixel buckets (as in Reyes approach), and use explicit scan conversion of geometry (as in Catmull ’78 approach).

[0041] Embree is a kernel framework for an efficient ray tracing on x86 CPUs. Embree is directed to professional rendering environments in which scenes with high geometric complexity and indirect illumination are the norm rather than the exception. To address this, Embree provides a set of commonly used kernels optimized for different ISA vector widths, workloads (e.g., coherent and incoherent ray distributions, static and dynamic scenes), and application-specific priorities (e.g., maximal performance or minimal memory usage). Renderers built on these kernels can achieve a bounding volume hierarchies (BVH) build and ray traversal performance comparable to existing methods on many CPUs or GPUs.

[0042] Reyes is an image rendering system developed at Lucasfilm Ltd. and currently in use at Pixar. Reyes provides an architecture optimized for fast high-quality rendering of complex animated scenes, i.e., to be able to compute a feature-length film in approximately a year. It provides high-quality means that are virtually indistinguishable from live action motion picture photography and complex means as visually rich as real scenes.

[0043] The explicit scan conversion of geometry, as in Catmull, implements a hidden- surface algorithm with anti-aliasing. The aliasing problems usually include jagged edges, small objects popping on and off the screen in successive frames, moire patterns in rendering periodic images, fine detail breaking up, and so on. The problem occurs mainly because the image space is sampled at discrete points corresponding to the pixels. Catmull’s hidden surface algorithm includes, among other things, sorting all polygons on highest “y” value, initializing an active polygon list to be empty, and repeating for each scanline: adding polygons from y-list that enter this scanline to active polygon list, initializing the x-bucket to be empty the scanline array to background, and looping through each polygon in an active polygon list by performing specific clipping, replacing, and sorting operations on the polygons.

[0044] In some embodiments, the presented system and method overcome the limitations of the techniques for handling sub-pixel transparency or anti-aliasing, including accumulated jittered random sampling, accumulating micro-polygons, or using a modified Reyes to store transparency and color data in an A-Buffer.

[0045] An A-buffer (i.e., anti-aliased, area-averaged, accumulation buffer) is a general hidden surface mechanism suited to medium scale virtual memory computers. It resolves visibility among an arbitrary collection of opaque, transparent, and intersecting objects. Using an easy to compute Fourier window, it increases the effective image resolution many times over the Z-buffer with a moderate increase in cost.

[0046] In some embodiments, the presented system and method overcome the limitations of other methods with respect to the availability of computer memory by utilizing, for example, the A-Buffer algorithms to store coverage data.

[0047] In some embodiments, the system and method described herein use a hybrid approach, which explicitly relies on scan converting, but implicitly relies on deriving sub- pixel coverage using modem scalar instructions, and a carefully constructed coverage data set to perform the implicit calculations.

[0048] 4.0 SYNTHETIC VIEW RENDERING PROCESS

[0049] FIG. 2 illustrates an example processing flow for rendering synthetic views, according to some embodiments. The steps described in FIG. 2 may be performed using the components of product synthetic view rendering platform 101, described in FIG. 1.

[0050] 4.1 GENERATING CALIBRATED PRODUCT RENDERINGS ASSETS

[0051] In step 202, a process of generating a synthetic view rendering begins from generating calibrated product renderings assets. The calibrated product rendering assets may be generated by creating a digital representation of a referenced physical product. A referenced physical product may be produced using designated colors and patterns. The colors and patterns may be generally referred to as “markups.”

[0052] A markup is recognized and used to construct geometry, design areas, masks, local surface shading, and global luminance shading. The geometry, luminance maps, and color maps are usually tied to product options key-values.

[0053] 4.2 APPLYING USER-DRIVEN SETTINGS OF PRODUCT OPTION KEY¬

VALUES TO CALIBRATED PRODUCT RENDERING ASSETS

[0054] In step 202A, as part of generating the calibrated product rendering assets, user- driven settings of product option key -values are applied to the calibrated product rendering assets. This may include setting a substrate, trim, or other key-values associated with color or textural appearance. A substrate may be the material from which the product is made. For example, the substrate for a poster is paper, the substrate for a t-shirt is a cotton cloth, the substrate for a phone case may be polycarbonate, and so forth. In some embodiments, texture assets and color maps may be set by reference.

[0055] In some embodiments, applying the product option key-values also includes setting design areas associated by key-value. This may include setting design area references by, for instance, setting an image to render into a design U-V geometry specified by a markup.

[0056] In some embodiments, applying the product option key-values also include setting product parametric key-values. This may include transforming the geometry features and placements. The keys for a particular product may include a product height, a product width, a product depth, a product circumference, a placement of designs, a design height, a design width and the like.

[0057] In some embodiments, trim geometry features and placements are transformed. The transformation may include fitting the framing or edging to the geometry features and setting physical profiles of framing or edging.

[0058] In some embodiments, view parameters are set. This may include setting geometry transforms to a specific view. This may also include setting in-situ transforms.

[0059] 4.3 INITIATING THE RENDERING APPLICATION

[0060] In step 202B, a rendering application is initiated. In this step, a CoverageMap service is initialized. The CoverageMap service is described later.

[0061] 4.4 RENDERING THE ASSETS

[0062] In step 208, the assets are rendered. In this step a Coverage buffer service is initialized. The Coverage buffer service is described later.

[0063] Then, for each surface in the calibrated product rendering asset, the following is performed: in step 208A, the surface appearance assets are bound to the corresponding colors, textures, designs, parametric shading, and the like.

[0064] Then, in step 208B, for each polygon in the calibrated product rendering asset, a hybrid scanline and implicit structure are built. This may include determining triangle points, triangle deltas, and ImplicitTriangles.

[0065] In step 208C, the converted surfaces are scanned into explicit pixel samples and the pixel samples are implicitly evaluated into a CoverageMap.

[0066] In some embodiments, each triangle is scan-converted by performing the following: for each X,Y pixel in the scan, the Impli ci tTri angle is evaluated using the CoverageMap Service. If the X,Y pixel is fully inside the polygon, then a default full CoverageMap is set. However, if the X,Y pixel is partially inside the polygon, then a CoverageMap is calculated. Then, the pixel is set in the Coverage buffer. If the pixel is visible, then the pixel is shaded.

[0067] In step 208D, the Coverage buffer is converted to a final image. This is described in detail later.

[0068] 4.5 DISPLAYING THE ASSETS

[0069] FIG. 3 illustrates an example of a user interface 130 of the product customization system, according to some embodiments. The depicted example shows an example of a rendered image 134, which corresponds to a rendered image 134 shown in FIG. 2 of US 8,175,931 B2.

[0070] The user interface may include a view option portion 132 that allows the user/consumer to select between a product view or a design view in a view portion 134. The view portion also has a view selector 134a that allows the user/consumer to select among the views (upper, outside quarter, outside front or tongue, for example) to be displayed in the view portion. The user interface may also include a view tools portion 136 that allows the user to replace or delete a portion of the view (dotted box tool), zoom the view (the magnifying glass tool) and/or view the pair of products together in the view portion.

[0071] The user interface further comprises a product options tab 137 (a Keds Shoe option tab because the product in the example is a Keds shoe) that allows the user to select various product options (such as colors and patterns for the design area and for accessories) and a customize it a tab 138 that allows the user to customize the product with user content as described below in more detail. As shown, the product options tab (herein the product is a shoe) may further include a product summary portion 137a that displays a summary of the particular product, a size portion 137b that allows the user to select the appropriate size of the product, an extra laces portion 137c that allows the user to select extra laces to be purchased with the customized product, a color and prints portion 137d that allows the user to select a color and/or print for each piece of the product (such as the upper, tongue, inside quarter, insole, heel and outside quarter in the shoe example), a trims and detail user interface 137e that allows the user to select certain trims and details for the product and a commerce portion 137f that allows the user to select a quantity of products to purchase, shows the accumulated price of the products and allows the user to add the customized products to an electronic shopping cart.

[0072] 5.0 COVERAGE MAP SERVICE

[0073] The core of the presented approach is a CoverageMap service. The CoverageMap service provides the evaluation of an Impli ci tTri angle and provides a coverage map for, for example, a 16x16 sub pixel area. The CoverageMap service may be implemented in many ways. Below is an example of one possible implementation of the CoverageMap Service. It should be noted that this embodiment is tuned to a specific scalar instruction set, so other instruction sets may require separate embodiments.

[0074] In some embodiments, a CoverageMap structure is designed to represent a single edge of a polygon, and to evaluate the 16x16 binary coverage of that edge for any X,Y pixel. The structure may contain:

1. coverage, a 256 bit vector containing the 16x16 coverage map, and

2. centroid, a 128 bit vector containing 4 single precision floating point values containing the sampling point for the CoverageMap that corresponds to a coverage area. [0075] The CoverageMap service may evaluate an X,Y pixel against a single edge, the edge may be represented by an edge, a 128 bit vector containing 4 single precision floating point values describing the edge holding a, b, c, d; where a, b is the normal of a 2d edge, c is the offset from the normal to 0,0 for the edge, and d is the distance from the upper left corner of a pixel to its center.

[0076] In one implementation, the CoverageMap service is represented by an Intel

> m256i register defined in the AVX2 instruction set (see imminitrin.h Meta Header file for Intel(R) Architecture intrinsic functions).

[0077] In one implementation, the centroid is represented by an Intel ml28 register referenced in the SSE4.1 instruction set (see smmintrin.h, Meta Header file for Intel(R) Architecture intrinsic functions).

[0078] In one implementation, an edge is represented by an Intel ml28 register referenced in the SSE4.1 instruction set (see smmintrin.h, Meta Header file for Intel(R) Architecture intrinsic functions).

[0079] An example of a pseudo-code for one implementation of the CoverageMap is provided below:

[0080] /**

[0081] * CoverageMap

[0082] * A structure to hold a 16x16 binary coverage map.

[0083] * It will return the area of the map, and perform

[0084] * Boolean operations on it.

[0085] */

[0086] struct align (32) CoverageMap

[0087] {

[0088] public:

[0089] union {

[0090] > m256i coverage;

[0091] struct { uint64 a, b, c, d; };

[0092] };

[0093] embree::Vector4f centroid;

[0094]

[0095] > forceinline CoverageMap() { }

[0096] > forceinline ~CoverageMap() { }

[0097]

[0098] > forceinline CoverageMap(uint64 n)

[0099] { [0100] coverage = _mm256_setl_epi64x(n);

[0101] }

[0102] > forceinline CoverageMap(const CoverageMap & q)

[0103] {

[0104] coverage = q. coverage;

[0105] centroid = q. centroid;

[0106] }

[0107]

[0108] /**

[0109] * Returns the area this map covers of a single pixel.

[0110] * @returns the area of coverage 0...255.

[0111] */

[0112] static forceinline int32 area( m256i & map)

[0H3] {

[0114] uint64 n = _mm_popcnt_u64(map.m256i_u64[0]);

[0115] n += mm_popcnt u64(map.m256i u64[l]);

[0116] n += _mm_popcnt_u64(map.m256i_u64[2]);

[0117] n += _mm_popcnt_u64(map.m256i_u64[3]);

[0118] return((int32)n);

[0H9] }

[0120]

[0121] /**

[0122] * Returns the area this map covers of a single pixel.

[0123] * @returns the area of coverage 0...255.

[0124] */

[0125] > forceinline int32 area()

[0126] {

[0127] uint64 n = mm _popcnt_u64(a);

[0128] n += _mm_popcnt_u64(b);

[0129] n += _mm_popcnt_u64(c);

[0130] n += _mm_popcnt_u64(d);

[0131] return((int32)n);

[0132] }

[0133] /** [0134] * Clears the map

[0135] */

[0136] > forceinline void clear()

[0137] {

[0138] a = 0;

[0139] b = 0;

[0140] c = 0;

[0141] d = 0;

[0142] centroid = embree::Vector4f(0.0f);

[0143] }

[0144] /**

[0145] * Intersects this map with another map

[0146] * @param The map to intersect this map with.

[0147] */

[0148] > forceinline void intersect(CoverageMap & q)

[0149] {

[0150] coverage = _mm256_and_si256(coverage, q.coverage);

[0151] }

[0152] /**

[0153] * Unions this map with another map

[0154] * @param The map to combine this map with.

[0155] */

[0156] > forceinline void combine(CoverageMap & q)

[0157] {

[0158] coverage = _mm256_or_si256(coverage, q.coverage);

[0159] }

[0160] /**

[0161] * Subtracts another map from this map.

[0162] * @param The map to subtract from this map.

[0163] */

[0164] > forceinline void difference(CoverageMap & q)

[0165] {

[0166] coverage = _mm256_andnot_si256(q. coverage, coverage);

[0167] } [0168] /**

[0169] * returns the centroid for this map

[0170] * @param The returned centroid for this map

[0171] */

[0172] > forceinline void getCentroid(embree::Vec2f & n)

[0173] {

[0174] n.x = centroid.x;

[0175] n.y = centroid.y;

[0176] }

[0177] };

[0178] Note that the Boolean area operations on the CoverageMap, intersect, combine, and difference are performed by a single scalar instruction taking a single clock cycle. This allows for very fast calculations of sub-pixel rendered regions. Note also that the area may be computed using scalar instruction popcnt() operations, this allows for the fast conversion of a coverage area into an opacity.

[0179] The number of possible edges in a 16x16 sub pixel array is relatively small. In one embodiment, an array of all possible edges may be represented by 256 angles and 512 subpixel distances from the upper left corner of the array. In one embodiment the pixel distance for distance are sqrt(2.0) / 512.0, and the angular units are (2.0 * PI()) / 256.0.

[0180] An example of a pseudo-code for one implementation of building this array (using embree::math.h for intrinsics) is provided below:

[0181] /**

[0182] * Builds the look-up table to map angles and distance to coverage.

[0183] */

[0184] void buildCoverageMapLook()

[0185] {

[0186] mapLook.resize(512 * 256); // fixed size of coverage map look-up

[0187] int32 mapDex = 0;

[0188] for (int32 i = 0; i < 256; i++)

[0189] {

[0190] float angle = (float)i * ((float)embree::TwoPiTy() / 256. Of);

[0191] for (int32 j = 0; j < 512; j++)

[0192] {

[0193] float d = (float)j * (gSqrtTwo / 512. Of); [0194] d = d - gHalfSqrtTwo;

[0195]

[0196] embree::Vector4f edge = embree::Vector4f(embree::cos(angle), embree: :sin(angle), d, O.Of);

[0197]

[0198] CoverageMap map;

[0199] double accumX = 0.0;

[0200] double accumY = 0.0;

[0201] double accumCount = 0;

[0202] for (int32 ii = 0; ii < 16; ii++)

[0203] {

[0204] float y = ii * (l.Of / 15. Of) - 0.5f;

[0205] uintl6 scanLine = 0;

[0206] for (int32 jj = 0; jj < 16; jj++)

[0207] {

[0208] float x = jj * (l.Of / 15. Of) - 0.5f;

[0209] embree::Vector4f sample = embree::Vector4f(x, y, 1.0, O.Of);

[0210] float nd = embree::dot(edge, sample);

[0211] if (nd < 0)

[0212] {

[0213] accumX += x;

[0214] accumY += y;

[0215] accumCount += 1.0;

[0216] scanLine |= 1 «jj;

[0217] }

[0218] }

[0219] map.m256.coverage_ul6[ii] = scanLine;

[0220] }

[0221] if (accumCount > 0)

[0222] {

[0223] accumX = accumX / accumCount;

[0224] accumY = accumY / accumCount;

[0225] } [0226] map. centroid = embree: :Vector4f((float)accumX, (float)accumY, O.Of,

(float)(accumCount));

[0227] mapLook[mapDex] = map;

[0228] mapDex++;

[0229] }

[0230] }

[0231] }

[0232] A pixel coordinate may also be represented by a ml28 register. It may be converted so that a dot product with the edge structure may produce a distance from the edge if the pixel is in the form x, y, 1, 1.

[0233] It is useful to quickly prepare a given integer X, Y pixel for evaluation against an edge.

[0234] An example of a pseudo code for a possible implementation for this conversion is described below:

[0235] /**

[0236] * Builds a pixelCoord for calculating pixel coverage.

[0237] * @param the pixel's x location

[0238] * @param the pixel's y location

[0239] * @returns a Vector4f of the pixel coordinate to perform coverage calculations.

[0240] */

[0241] static forceinline embree::Vector4f pixelCoord(int32 x, int32 y)

[0242] {

[0243] > ml28i origin = _mm_set_epi32(l, 1, y, x); // note set is in order(3, 2,

1, 0)

[0244] embree: : Vector4f coord = _mm_cvtepi32 _ps(origin); // fast convert to float

[0245] coord += embree: :Vector4f(0.5f, 0.5f, 0, 0); // round

[0246] return(coord);

[0247] }

[0248] Now the converted pixel may be implicitly evaluated by the edge quickly with a dot product. This can be done in 1.5 clock cycles using the _mm_dp_ps() intrinsic function.

[0249] An example of a pseudo-code for a possible implementation of evaluating the pixel and returning a CoverageMap is included below:

[0250] /** [0251] * Makes a coverage map for an edge and a pixel.

[0252] * @param the edgeAngle

[0253] * @param the pixelCoord

[0254] * @param the found CoverageMap

[0255] * @param the found centroid

[0256] * @returns the index of the found coverageMap.

[0257] */

[0258] > forceinline int32 coverageMap(

[0259] embree::Vector4f& edge,

[0260] embree::Vector4f& pixel,

[0261] CoverageMap& map)

[0262] {

[0263] float d = embree::dot(edge, pixel);

[0264] if (d < 0)

[0265] {

[0266] map = CAverageMap(Oxffffffffffffffff);

[0267]

[0268] map.v = embree::Vector4f(0, 0, 0, 256. Of);

[0269] return(0);

[0270] }

[0271] if (d >= gSqrtTwo)

[0272] {

[0273] map = CoverageMap(O);

[0274] map.v = embree::Vector4f(0.0f);

[0275] return(511);

[0276] }

[0277] d *= (512. Of / gSqrtTwo);

[0278] d = floored);

[0279] int32 angle = normalToAngle(edge) & 255;

[0280] int32 mapDex = (angle * 512) + (int32)d;

[0281] map = mapLook[mapDex];

[0282] return(mapDex);

[0283] } [0284] It is worth noting that most pixel evaluations may be fully within the edge, or outside it, so the fast evaluation using the intrinsic scalar dot product instruction may be applied. The evaluation of an ImplicitTriangle may be optimized by performing three dotproduct edge evaluations for a quick accept/reject.

[0285] 6.0 THE COVERAGE BUFFER SERVICE

[0286] Once the scan converted pixel for a triangle is positively evaluated, a

CoverageMap may be added to the Coverage buffer.

[0287] In one implementation, the Coverage buffer is a 2D array of 32-bit integers that are the start of an indexed list of CoverPix structures. On initialization, the array is set to the size of the image to be rendered, and its values are set to -1 to indicate that they are empty.

[0288] A CoverPix is an intermediate representation of a shaded pixel that holds shading and surface data, an index to a CoverageMap, a SurfacelD, and compositing information.

[0289] An example of pseudo code for a possible implementation of a CoverPix is shown below:

[0290] struct CoverPix

[0291]

[0292] /**

[0293] * CompositeOp declaration.

[0294] * @param The CoverPixel atop the dest.

[0295] * @param The pixel beneath the CoverPixel.

[0296] */

[0297] typedef float (*CompositeOp)(CoverPix& top, embree::Vector4f &dest);

[0298]

[0299] embree::Vector4f color; // the shaded color of this pixel

[0300] CompositeOp compositeOp; // the compositing operation tao apply this pixel

[0301] float depth; // the depth for this pixel

[0302] float coverage; // the coverage of this pixel

[0303] int32 next; // the next pixel in z order

[0304] int32 mapDex; // the coverage map index

[0305] uint64 surfld;; // the surface ID for this pixel

[0306]

[0307] > forceinline CoverPixQ { } // Nothing set here for speed. Use Coverage buffer ::set() to allocate.

[0308] > forceinline -CoverPixQ { } [0309] > forceinline CoverPix(const CoverPix& a)

[0310] {

[0311] color = a. color;

[0312] depth = a.depth;

[0313] compositeOp = a. compositeOp;

[0314] mapDex = a.mapDex;

[0315] coverage = a. coverage;

[0316] next = a. next;

[0317] surfld = a.surfld;

[0318] }

[0319] }

[0320] In some embodiments, the Coverage buffer holds a resizable array of CoverPix and CoverageMaps. When a shaded pixel is added to the Coverage buffer, a CoverPix and CoverageMap are allocated for them (if needed) and they are placed into a z-ordered linked list in the Coverage buffer.

[0321] An example of pseudo code of a possible implementation of the Coverage buffer structure is shown below:

[0322] struct Coverage buffer

[0323] {

[0324] typedef std::vector<CoverPix> PixList;

[0325] typedef std: :vector<CoverageMap> MapList;

[0326]

[0327] std::vector<PixList> pixLists;

[0328] std::vector<MapList> mapLists;

[0329] cv::Mat coverBuff;

[0330]

[0331]

[0332] Coverage buffer() { }

[0333] -Coverage buffer() { }

[0334] Coverage buffer(const Coverage buffer& a)

[0335] {

[0336] pixLists = a.pixLists;

[0337] mapLists = a. mapLists;

[0338] coverBuff = a. coverBuff; [0339] }

[0340]

[0341] Coverage buffer(int32 width, int32 height)

[0342] {

[0343] build(width, height);

[0344] }

[0345]

[0346] /**

[0347] * Builds the Coverage buffer, allocating coverBuff, pixes, and maps.

[0348] * @param The width of the rendering area.

[0349] * @param The height of the rendering area.

[0350] */

[0351] void build(int32 width, int32 height)

[0352] {

[0353] coverBuff = cv::Mat(height, width, CV_32SC1);

[0354] coverBuff = -1;

[0355] pixLists.resize(height);

[0356] mapLists.resize(height);

[0357] CoverageMap map(

[0358] map.v = embree::Vector4f(0, 0, 0, 256. Of);

[0359]

[0360] for (int32 i = 0; i < height; i++)

[0361] {

[0362] pixLists[i].reserve(width * 3);

[0363] mapLists[i].reserve(width » 1);

[0364] mapLists[i].push_back(map); //reserve full coverage map as index 0.

[0365] }

[0366] }

[0367] }

[0368] In this implementation, the CoverPix and CoverageMaps are allocated as arrays for each “x” scanline. This is to allow multithreaded rendering of the image by scanline areas. When a shaded scan-converted pixel is placed into the map, if it is determined that pixel of the Coverage buffer is empty, then it may just be allocated and set. If the new pixel falls behind another pixel in the map that is fully opaque, it may be ignored. If the new pixel has the same surfacelD and matches the “z” depth of a pixel in the Coverage buffer, then it may be combined into the existing CoverPix of that surface. If none of these are the case, then a new CoverPix is allocated, and its index is sorted into the linked list of CoverPix ids for its X,Y location.

[0369] Shading the pixel is the most expensive single operation, so it is performed only if the pixel will contribute to the rendering.

[0370] An example of pseudo code of an implementation of the Coverage buffer:: set function, along with helper functions, is described below:

[0371] /**

[0372] * Pushes a map onto the mapLists.

[0373] * @param The map to push.

[0374] * @param The scanline index for the mapLists

[0375] * @returns The index for this scanline for the new map.

[0376] */

[0377] > forceinline int32 pushMap(CoverageMap &map, int32 y)

[0378] {

[0379]

[0380] int32 mapDex = mapLists[y].size();

[0381] mapLists[y].push_back(map);

[0382] return(mapDex);

[0383] }

[0384] /**

[0385] * Pushes a CoverPix onto the pixLists.

[0386] * @param The CoverPix to push.

[0387] * @param The scanline index for the pixLists

[0388] * @returns The index for this scanline for the new CoverPix.

[0389] */

[0390] > forceinline int32 pushPix(CoverPix &pix, int32 y)

[0391] {

[0392] int32 pixDex = pixLists[y].size();

[0393] pixLists[y].push_back(pix);

[0394] return(pixDex);

[0395] }

[0396] [0397] /**

[0398] * Sorts a pixel into the Coverage buffer

[0399] * @param The source ScanShader

[0400] * @param The ShadePoly context for setting the pixel.

[0401] * @param the horizontal offset in pixels.

[0402] * @param the vertical offset in pixels.

[0403] * @param the compositing operation for the pixel

[0404] */

[0405] void set(RasterShader &shader, ShadePoly &context, int32 x, int32 y)

[0406] {

[0407] embree::Vector4f coord = CoverageMapping::pixelCoord(x, y); // the coord for CoverageMapping

[0408] if (context.update(*gCoverage, coord)) // update the poly

[0409] {

[0410] PixList& pixes = pixLists[y];

[0411] MapList& maps = mapLists[y];

[0412]

[0413] int32* buff = (int32*)coverBuffptr(y, x); // the pixel is within sub-pixel limits.

[0414] embree::Vector4f cSample = context. centerSample(coord);

[0415] float depth = cSample[2];

[0416]

[0417] if (buff[0] < 0) // if there is no

CoverPix set in the buffer...

[0418] {

[0419] shader. shadePixel (context); // shade the pixel.

[0420]

[0421] CoverPix pix;

[0422] pix. color = context, pixel;

[0423] pix. depth = depth;

[0424] pix. setOp(shader.blendMode);

[0425] pix. next = -1; [0426] pix.surfld = shader.id;

[0427]

[0428] if (context.cMap.v.w == 256) // if there is full pixelcoverage...

[0429] {

[0430] pix.mapDex = 0; // use pre-allocated full CoverageMap

[0431] pix.coverage = l.Of;

[0432] }

[0433] else

[0434] { // else we need to allocate a CoverageMap

[0435] int32 mapDex = pushMap(context.cMap, y); // from the context's coverage map.

[0436] pix.mapDex = mapDex;

[0437] pix.coverage = context.cMap.v[3] * (l.Of / 256. Of);

[0438]

[0439] int32 thisDex = pushPix(pix, y); // save the

CoverPix to the list

[0440] buff[0] = thisDex; // place the

CoverPix index in buffer

[0441]

[0442] else

[0443]

[0444] int32 nextDex = bufffO]; // the current index

[0445] bool hidden = pixesfnextDex], depth < depth && // fast return on occulution.

[0446] pixesfnextDex], col or[3] > 0.999f &&

[0447] pixesfnextDex], coverage > 0.999f;

[0448]

[0449] if (! hidden)

[0450] {

[0451] int32* lastRef = buff; // the forward link to fix. [0452] int32 curDex = nextDex;

[0453]

[0454] float zDiff = pixes[nextDex], depth - depth;

[0455]

[0456] while (nextDex >= 0 && // traverse list for insertion sort.

[0457] (pixes[nextDex], depth - depth) > -gCoverage buff erZTol erance)

[0458] {

[0459] curDex = nextDex;

[0460] zDiff = pixes[curDex], depth - depth;

[0461] nextDex = pixes[curDex].next; // update the current index.

[0462] lastRef = &pixes[curDex] .next; // update the forward link

[0463] }

[0464]

[0465] bool sameSurface = curDex >= 0 &&

[0466] pixes[curDex].surf!d == shader.id &&

[0467] embree::abs(zDiff) < gCoverage buff erZTol erance;

[0468]

[0469]

[0470] if (sameSurface)

[0471] {

[0472] CoverageMap& currentMap = context. cMap;

[0473] float currentCoverage = currentMap. v.w * (l.Of / 255. Of);

[0474] float combinedCoverage = currentCoverage + pixes[curDex], coverage;

[0475] sameSurface = combinedCoverage <= l. lf;

[0476] if (! sameSurface)

[0477] {

[0478] if (zDiff > 0)

[0479] {

[0480] curDex = nextDex;

[0481] } [0482] }

[0483] }

[0484]

[0485] if (sameSurface )

[0486] {

[0487] // Pixels at the same depth and with the same surfld

[0488] // are treated as the same surface.

[0489] CoverageMap& currentMap = context. cMap;

[0490]

[0491] if (pixes[curDex], coverage < 1.Of) // if surface not already shaded....

[0492] { // we need to combine sub-pixel coverage. [0493] float cO — currentMap. v.w; // cO is the coverage of the source in subpixels (0...256) [0494] {

[0495] float cl = pixes[curDex], coverage; // cl is the coverage of the destination map

[0496] CoverageMap& destMap =

[0497] maps[pixes[curDex].mapDex];

[0498]

[0499] CoverageMap temp = destMap;

[0500] temp.difference(currentMap);

[0501]

[0502] float c2 = temp.area(); // c2 = pixes[curDex].map - currentMap;

[0503] {

[0504] float sum = c2 + cO; // sum is total coverage of combined maps

[0505] if (sum)

[0506] {

[0507] shader. shadePixel (context); [0508]

[0509] cO = cO / sum; // cl is now the source contribution

[0510] c2 = c2 / sum; // c2 is now the dest contribution.

[0511]

[0512] pixes[curDex].color =

[0513] pixes[curDex].color * c2 +

[0514] context.pixel * cO; // calc the new dest color

[0515]

[0516] currentMap. combine(destMap); // union the src and dest maps.

[0517] currentMap.v.w = currentMap. area(); // update the map's area

[0518] if (currentMap.v.w != 256) // if not full coverage

[0519] {

[0520] if (pixes[curDex], coverage == 256) // if the existing map used pre-allocated full coverage...

[0521] {

[0522] // allocate a new map

[0523] pixes[curDex], coverage =

[0524] currentMap.v.w * (l.Of / 256. Of);

[0525] int32 mapDex = pushMap(currentMap

[0526] pixes[curDex].mapDex = mapDex;

[0527] }

[0528] else

[0529] {

[0530] pixes[curDex], coverage =

[0531] currentMap.v.w * (l.Of / 256. Of);

[0532] destMap = currentMap; already an allocated map, just set it.

[0533] } [0534] }

[0535] else

[0536] {

[0537] pixes[curDex].mapDex = 0; // it is full coverage, so use pre-allocated full coverage map.

[0538] pixes[curDex], coverage = l.Of;

[0539] if (pixes[curDex].color[3] > 0.999f)

[0540] {

[0541] buff[0] = curDex;

[0542] }

[0543]

[0544]

[0545]

[0546]

[0547] }

[0548] }

[0549] else

[0550] {

[0551] // the new pixel does not match a destination map level.

[0552]

[0553] shader. shadePixel (context); // shade the pixel

[0554] CoverPix pix;

[0555] pix. color = context, pixel;

[0556] pix. depth = depth;

[0557] pix. setOp(shader.blendMode);

[0558] pix. next = nextDex;

[0559] pix.surfld = shader.id;

[0560] if (context.cMap.v.w == 256) // if it is full coverage...

[0561] {

[0562] pix.mapDex = 0; // use the pre- allocated map.

[0563] pix. coverage = l.Of;

[0564] } [0565] else

[0566] { // need to allocate a coverage map...

[0567] pix. coverage =

[0568] context.cMap.v.w * (l.Of / 256. Of);

[0569] int32 mapDex = pushMap(context.cMap, y);

[0570] pix.mapDex = mapDex; // set the pointer.

[0571]

[0572] int32 thisDex = pushPix(pix, y); // allocate the pixel

[0573] *lastRef = thisDex; // link into the list

[0574] if (context.cMap.v.w == 256) // if it is full coverage...

[0575] {

[0576] if (pix.color[3] > 0.999f) // if it is opaque...

[0577] {

[0578] buff[0] = thisDex; // drop all further pixels.

[0579]

[0580]

[0581]

[0582]

[0583]

[0584] }

[0585] }

[0586] Piecewise fitting based on coverage is performed if the pixels are on the same surface. Piecewise fitting is performed using the Boolean operations provided by the

CoverageMap service. These calculations, intersect, difference, and combine may be performed using single inline scalar instructions. Note that the “z” linked list is sorted furthest from the view to closest. This allows to quickly reject the occultation and is the same order the pixels will be composited.

[0587] Once all the polygons have been scan converted, and the Coverage buffer is fully set, it may be traversed and composited into the final image. This is done by traversing each pixel’s linked list, applying compositions in the linked order. [0588] An example of pseudo code of one possible implementation of this compositing for the Coverage buffer is described below:

[0589] /**

[0590] * Composite each pixel list in the Coverage buffer to a destination image.

[0591] * @param The destination image.

[0592] */

[0593] void compositeCoverage(cv::Mat& dest, embree::Vector4f fillColor)

[0594] {

[0595] _ml28i shuffle32to8;

[0596] shuffle32to8.ml28i_u64[0] = 0x808080800C080400;

[0597] shuffle32to8.ml28i_u64[l] = 0x8080808080808080;

[0598]

[0599] CoverageMap fillMap;

[0600]

[0601] if (fillColor[3] > 0.0)

[0602] {

[0603] fillMap = CoverageMap(Oxffffffffffffffff);

[0604] fillMap. v = embree::Vector4f(0, 0, 0, 256. Of);

[0605] }

[0606] else

[0607] {

[0608] fillMap = CoverageMap(O);

[0609] fillMap. v = embree::Vector4f(0, 0, 0, 0);

[0610]

[0611] }

[0612] if (dest.cols == coverBuffcols &&

[0613] dest.rows == coverBuffrows) // size must match

[0614] {

[0615] if (dest.type() == CV_8UC4) // if dest is 8bit 4 channel...

[0616] {

[0617] int32* srcBuff = (int32*)coverBuffptr();

[0618] int32 coverStride = coverBuffstep[0] / sizeof(int32);

[0619] uint32* destBuff = (uint32*)dest.ptr(); [0620] int32 destStride = dest.stepfO] / sizeof(uint32);

[0621] for (int32 i = 0; i < dest.rows; i++) // traverse the rows

[0622] {

[0623] MapList& maps = mapLists[i];

[0624] PixList& pixes = pixLists[i];

[0625]

[0626] int32 tempMapDex = maps.size();

[0627] maps.push back(fillMap);

[0628] int32* srcScan = srcBuff;

[0629] uint32* dstScan = destBuff;

[0630]

[0631] for (int32 j = 0; j < dest.cols; j++) // traverse the columns.

[0632] {

[0633] int32 currPix = srcScan[0];

[0634] CoverPix destPix;

[0635]

[0636] maps[tempMapDex] = fillMap;

[0637]

[0638] destPix. color = fillColor;

[0639] destPix. coverage = fillMap.v.w * 1. Of / 256. Of;

[0640] destPix. depth = HUGE VALF;

[0641] destPix. mapDex = tempMapDex;

[0642]

[0643] while (currPix >= 0) // traverse the CoverPix list.

[0644] {

[0645] CoverPix: :compositeCoverage(pixes[currPix], destPix, maps);

[0646] currPix = pixesfcurrPix], next; // advance to next CoverPix.

[0647] }

[0648]

[0649] destPix. color =

[0650] embree: :min(destPix. color, embree: : Vector4f(l .Of));

// clip to 1.0. [0651]

[0652] ml28i dest8bit =

[0653] _mm_cvtps_epi32(destPix. color * 255. Of); // convert from floats to 32 bit integers [0654] dest8bit =

[0655] _mm_shuffle_epi8(dest8bit, shuffle32to8); // convert from 32 bit integers to unsigned 8 bit components.

[0656] dstScan[0] = dest8bit.ml28i_u32[0]; // set the dest

[0657]

[0658] srcScan++; // step to next pixel in scanline

[0659] dstScan++;

[0660] }

[0661] srcBuff += coverStride; // step to next scanline.

[0662] destBuff += destStride;

[0663] }

[0664] }

[0665] }

[0666] }

[0667] In some embodiments, all shaded values are pre-multiplied by alpha, and top pixel’s coverage*alpha is used as a combined scalar for applying a PixCover’s shaded value.

[0668] In some embodiments, complex scenes may be composed using piecewise surface occlusion using techniques similar to those described for piecewise fitting.

[0669] In some embodiments, the compositing operations may be described by enumeration. An example is described below:

[0670] // blend mode for compositing within Coverage buffer.

[0671] enum BlendMode

[0672]

[0673] Over = 0, // dst = (src * src. alpha) + (dst * (1 -src. alpha))

[0674] Mui = 1, // dst = dst * src;

[0675] Copy = 2, // dst = src

[0676] Add = 3, // dst = dst + src; [0677] Sub = 4, // dst = dst-src;

[0678] Min = 5, // dst = MIN(src,dst);

[0679] Max = 6, // dst = MAX(src,dst);

[0680] };

[0681] After rendering using the presented high quality rendering approach, the rendered image is shown as element 134 described in FIG. 3, which corresponds to the image (element 134), generated using a different approach and is shown in FIG. 2 in US 8, 175,931 B2. It is worth noting that the sub-pixel rendering portion of the rendering adds about 20% to the rendering time while providing a virtual 16x in linear resolution.

[0682] 7.0 EXAMPLE METHOD FOR HIGH QUALITY RENDERINGS OF

SYNTHETIC VIEWS OF CUSTOM PRODUCTS

[0683] In some embodiments, a method for high quality renderings of synthetic view of custom manufactured product comprises rendering of an image of the custom manufactured product where instructions for manufacturing the product are provided by a ProductOptions framework composed of a set of constrained key-value pairs.

[0684] In some embodiments, a product option may be represented as a key -value pair. The key-value pair is a label that may span individual products and represent a class of products. The keys of pairs may include a material type, a color, a size, and the like.

[0685] The value in a key-value pair is a specific discrete or continuous value that sets a manufacturing instruction. Examples of discrete (enumerated) values may include a discrete type of fabric such as cotton, cotton-polyester blend, silk, and the like. The discrete values may also include specific colors, such as white, navy, black, and the like.

[0686] Examples of continuous values of key -value pairs may include a single element, such a length or a ribbon, a vector, such as a size of a frame for a print (width (in inches)) or a height (in inches)), or the size of a box for the European countries, such as a size of a box for the EU (width (in millimeters), height (in millimeters), depth (in millimeters)).

[0687] The values may also reference a known file type, such as an image for the design on a t-shirt, such as an embroidery file for the back of a jacket, such as an engraving design for a bracelet, and the like.

[0688] In some embodiments, values in key-value pairs may include a set of graphic primitives for a design, such as an image, a line, a circle, a rectangle, a text, a group, and the like.

[0689] The product option key -values may have default values. Default values are pre-set values that will produce a product without changing any key -value pairs through customization. When key -values are changed they may produce a product option framework event chain. A product option framework event chain is a journal of each key -value change ordered in time.

[0690] A product type may itself be represented by a product option key -value. Using this option type, one product type may be associated with another product type through a well- known relationship. The product option framework event chain may include one or more products, and the chain may represent or memorialize an event. The products may represent or memorialize an event. Examples of events may include invitations, save the date cards, birthday cards, birthday gifts, anniversary cards, birth announcements, RSVP cards, holiday cards, holiday gifts, thank-you cards, get-well cards, and the like.

[0691] The ProductOption key-value pairs may be used to automatically present an interface to a user. The ProductOption key -values pairs may be set, or changed, based on actions, or input, provided by a user.

[0692] In some embodiments, a calibrated product rendering asset is rendered as an image of the custom manufactured product by applying key -value pairs. The key -value pairs may set at least one of: a color or a color map of the rendering asset, a texture or the textural surface of the rendering asset, an image representing an ornamentation or pattern on the product, or the size relationships of the geometry of the rendering asset.

[0693] The high quality rendering method presented herein utilizes a scan-converting geometry at pixel resolution. Furthermore, the sub-pixel coverage is evaluated using the edge evaluation performed by a dot product scalar instruction. Moreover, the sub-pixel coverage is evaluated using binary arrays of at least 16x16 using scalar instructions.

[0694] 8.0 EXAMPLE RENDERING FLOW

[0695] FIG. 4 illustrates an example processing flow for rendering synthetic images, according to some embodiments. The process allows manufacturing the user designed products and includes applying the user created colors and designs to the products made out of, for example, flat pattern pieces of fabric and sewn together. The steps described in FIG. 4 may be performed by a product customization system implemented in, for example, product synthetic view rendering platform 101 described in FIG. 1.

[0696] In step 402, a product customization system receives data capturing a customized product. The product customization system may, for example, provide a user interface allowing a user to customize the product. Then the product customization platform may receive the data capturing the customized product via the user interface. The interface may be implemented as one or more web pages. The user interface allows the user to interactively apply colors, tiled images, and photographic or designed images to two-dimensional pattern pieces that comprise the product. The data generated by the user interface may include user account data, a product description (that describes the user's custom product), user image designs (that contains the user content), color choices (the color(s) chosen by the user), material choices (the type of material for the custom product) and the finishing choices (the finishing selected by the user for the custom product). The user interface may be configured to assemble a set of instructions that describe the user design and to request the images of the final product from the user product Tenderer.

[0697] In step 404, the product customization system renders the customized product for the user using a user product Tenderer implementing the high quality rendering approach presented herein. The user product Tenderer may receive the data/information/description of the two dimensional pattern pieces (based on the user interactions with the user interface portion) and other user preferences and using information supplied by, for example, a reflection module. The reflection module may be configured to generate calibrated color maps and calibrated luminance maps to the calibrated product render assets (including geometry, luminance maps, color maps and safe area coverage maps) that are used to generate the images for the product. Then the Tenderer may synthesize an image of the final cut and stitch manufactured product that is then displayed to the user/consumer.

[0698] In step 406, the product customization system renders the customized product for a manufacturer using the manufacturing product Tenderer implementing the high quality rendering approach presented herein. The manufacturing product Tenderer may receive the data/information/description of the two dimensional pattern pieces, other user preferences and information supplied by the reflection module and prepare the image pattern files, cutting files, and operator directions used by a manufacturing module.

[0699] In step 408, the product customization system sends the customized product to a manufacturer, which uses the manufacturing equipment to manufacture the customized product. The manufacturing may include, for example, the following processes: 1) manufacture the flat pattern pieces using the image pattern files and cutting files; 2) sew the pattern pieces based on the operator directions; 3) perform finishing steps; 4) ship the product based on the operator directions; and/or 5) gather product information for the reflection portion (including patterns, reference product with calibration markup and/or color and material samples) that are input to a model-shot processing component that may perform, for example, various model-shot processing tasks.

[0700] In step 410, the product customization system performs the reflection process using the reflection module. The reflection module may be a portion of the system that provides feedback to the other portions of the systems. The reflection module may perform, for example, the following tasks: 1) provide updated product patterns to the manufacturing product Tenderer portion (the calibrated patterns and visible area layouts); 2) manufacture reference product used by the user product Tenderer portion (the calibrated patterns and visible area layouts); 3) calibrate pattern position with the manufacturer’s reference product; 4) provide calibrated photographic references of reference product to the user product Tenderer portion; and/or 5) provide calibrated reflectance and color mapping for the user product Tenderer portion (the calibrated color maps and calibrated luminance maps).

[0701] 9.0 MANUFACTURING

[0702] A manufacturing process may pertain to manufacturing a digital product as well as manufacturing a physical product. Since the manufacturing instructions for generating a product are generated based on a plurality of key -value pairs for a digital design of the product, in some situations, the same manufacturing instructions may be used to manufacture the digital product as well as to manufacture the physical product.

[0703] In some embodiments, a product options framework builds an interface for keyvalue pairs called OutputStyle. The interface for the OutputStyle key may allow a designer (or any other collaborator) to select values for the media for the presentation of an interactive design. The choices may include a IPEG Image, a GIFF Image, and an H264_Video.

[0704] If a designer chooses the GIFF Image option, then the product options framework may send the instructions to the manufacturing system to traverse each of the key -values in the KeyValuelournal, and for each key, and use a User Product Renderer to render the state of the custom physical product with that modification as images in the sRGB 32-bit RGBA format. Subsequently, the manufacturing system may store the renderings in a local image cache.

[0705] Then, the manufacturing system may traverse the images stored in the local image cache and determine an optimal color palette for that collection of images.

[0706] Subsequently, the manufacturing system may convert the images in the local image cache from 32-bit RGBA format to 8 bit Indexed color.

[0707] Then, the manufacturing system may embed a digital watermark which encodes the input KeyValue ournal ’s UUID in the 8 bit indexed color image cache.

[0708] Next, the manufacturing system may begin encoding the image file. For example, the manufacturing system may write the header bytes; write the Logical Screen Descriptor bytes; write the found color palette as a gif Global Color Table; write the gif 8 bit character application name; and embed metadata as a comment (or a watermark) which encodes the input KeyValueJournal’s UUID.

[0709] Once the manufacturing system processes all frames, the manufacturing system writes the file terminator (such as an ASCII code for zero) to the image file and outputs the manufactured GIF product.

[0710] At this point, executing the manufacturing instructions for the purpose of manufacturing the product ends, and the manufacturing of the product is completed. [0711] 10.0 IMPLEMENTATION MECHANISM— HARDWARE OVERVIEW

[0712] According to one embodiment, the techniques described herein are implemented by one or more special-purpose computing devices. The special-purpose computing devices may be hard-wired to perform the techniques, or may include digital electronic devices such as one or more application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) that are persistently programmed to perform the techniques, or may include one or more general purpose hardware processors programmed to perform the techniques pursuant to program instructions in firmware, memory, other storage, or a combination. Such special-purpose computing devices may also combine custom hard-wired logic, ASICs, or FPGAs with custom programming to accomplish the techniques. The special-purpose computing devices may be desktop computer systems, portable computer systems, handheld devices, networking devices or any other device that incorporates hard-wired and/or program logic to implement the techniques.

[0713] For example, FIG. 5 is a block diagram that illustrates a computer system 500. Computer system 500 includes a bus 502 or other communication mechanism for communicating information, and a hardware processor 504 coupled with bus 502 for processing information. Hardware processor 504 may be, for example, a general purpose microprocessor.

[0714] Computer system 500 also includes a main memory 506, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 502 for storing information and instructions to be executed by processor 504. Main memory 506 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 504. Such instructions, when stored in non-transitory storage media accessible to processor 504, render computer system 500 into a special-purpose machine that is customized to perform the operations specified in the instructions.

[0715] Computer system 500 further includes a read only memory (ROM) 508 or other static storage device coupled to bus 502 for storing static information and instructions for processor 504. A storage device 510, such as a magnetic disk or optical disk, is provided and coupled to bus 502 for storing information and instructions.

[0716] Computer system 500 may be coupled via bus 502 to a display 512, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 514, including alphanumeric and other keys, is coupled to bus 502 for communicating information and command selections to processor 504. Another type of user input device is cursor control 516, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 504 and for controlling cursor movement on display 512. The input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane. [0717] Computer system 500 may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computer system causes or programs computer system 500 to be a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system 500 in response to processor 504 executing one or more sequences of one or more instructions contained in main memory 506. Such instructions may be read into main memory 506 from another storage medium, such as storage device 510. Execution of the sequences of instructions contained in main memory 506 causes processor 504 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.

[0718] The term “storage media” as used herein refers to any non-transitory media that store data and/or instructions that cause a machine to operate in a specific fashion. Such storage media may comprise non-volatile media and/or volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 510. Volatile media includes dynamic memory, such as main memory 506. Common forms of storage media include, for example, a floppy disk, a flexible disk, hard disk, solid state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge.

[0719] Storage media is distinct from but may be used in conjunction with transmission media. Transmission media participates in transferring information between storage media. For example, transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 502. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.

[0720] Various forms of media may be involved in carrying one or more sequences of one or more instructions to processor 504 for execution. For example, the instructions may initially be carried on a magnetic disk or solid state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 500 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus 502. Bus 502 carries the data to main memory 506, from which processor 504 retrieves and executes the instructions. The instructions received by main memory 506 may optionally be stored on storage device 510 either before or after execution by processor 504.

[0721] Computer system 500 also includes a communication interface 518 coupled to bus 502. Communication interface 518 provides a two-way data communication coupling to a network link 520 that is connected to a local network 522. For example, communication interface 518 may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 518 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 518 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

[0722] Network link 520 typically provides data communication through one or more networks to other data devices. For example, network link 520 may provide a connection through local network 522 to a host computer 524 or to data equipment operated by an Internet Service Provider (ISP) 526. ISP 526 in turn provides data communication services through the worldwide packet data communication network now commonly referred to as the “Internet” 528. Local network 522 and Internet 528 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 520 and through communication interface 518, which carry the digital data to and from computer system 500, are example forms of transmission media. [0723] Computer system 500 can send messages and receive data, including program code, through the network(s), network link 520 and communication interface 518. In the Internet example, a server 530 might transmit a requested code for an application program through Internet 528, ISP 526, local network 522 and communication interface 518.

[0724] The received code may be executed by processor 504 as it is received, and/or stored in storage device 510, or other non-volatile storage for later execution.

[0725] 11.0 EXTENSIONS AND ALTERNATIVES

[0726] In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. Thus, the sole and exclusive indicator of what is the invention and is intended by the applicants to be the invention, is the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction. Any definitions expressly set forth herein for terms contained in such claims shall govern the meaning of such terms as used in the claims. Hence, no limitation, element, property, feature, advantage or attribute that is not expressly recited in a claim should limit the scope of such claim in any way. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.