Peterc_Dušan_full_AUTEX16

16th
AUTEX World Textile Conference 2016
June 8–10, 2016, Ljubljana, SLOVENIA
SERVER SIDE TEXTURE MAPPING FOR FASHION -
THE CASE OF ARAHDRAPE (Oral)
Dušan Peterc
Arahne, d.o.o., Novinarska 3, Ljubljana, Slovenia
dusan.peterc@gmail.com
ABSTRACT
Modern e-commerce web sites need to show products in many different colors and textures. We
compare the implementation of pre-calculated images in the web server and calculation of the
textured images on the fly. We explain the functionality of texture mapping system ArahDrape server,
which runs as a web service.
Keywords: texture mapping, rendering, visualization, web applications, e-commerce
1. INTRODUCTION
Texture mapping was one of the early applications of computer graphics [1]. Over the last 15
years, texture mapping of fabric simulation over photos has become a standard tool in the
design process [2]. We can take any photo of a finished product (shirt, sofa, tie, bed,
chair, ...) apply fabric simulation over selected regions of the photo, and get a realistic
simulation of the product in different pattern, colors or materials. It has become standard
practice in the industry to communicate with prospective buyer based on product
simulations. This is usually done directly by the designer with a special purpose desktop GUI
programs like ArahDrape [3]. Most companies, which develop CAD systems for textile, have
made their own drape software module. Penelope offers Atrezzo 3D [4], Dua offers Portrait
[5], Textronics offers Design 3D [6], Pointcarre offers 3D Mapping [7], Bontex offers
ModelWay [8], Nedgraphics offers Easy Map [9], ScotWeave offers Drape [10].
In many areas, we observe shift from manufacturing to marketing, the focus is not on how to
make it, but how to sell it. With the rise of e-commerce, customers want to see the product in
different colors and fabric selections, prior to purchase. From the user's point of view, this is
usually done in some kind of web based configurator tool, which offers product
personalization. It is not practical to make hundreds of product photos for each color of fabric
variant. In some cases, product is not even available in all colors during the photo session.
Dedicated texture mapping software like ArahDrape can apply thousands of textures in
automatic way from the GUI version. In that case, all the images need to be pre-calculated.
Once calculated, all texture mapped images are stored in web server and web application
chooses to display the correct image according to user's preferences. If we apply only one
texture per image, this approach works relatively well. On the next image you see web site of
Patternbank [11], which sells designs, and offers a user the texture-mapped look on different
products.
1

16th
But if we need to combine several different textures on distinct areas of a single image, the
number of images to store raises exponentially. Let's do a quick calculation: On the next
picture, we have a sofa with cushions, where sofa is available in 100 patterns and we have
200 fabrics for cushions. It does not sound so much, but we need 100 x 200 = 20.000
images to cover all the combinations. You can imagine the problems with even higher
number of fabrics or different contemporary areas for textures.
2
Figure 1: Pattern bank - one texture per image; design by Ruby Valderama
Figure 2: ArahDrape - sofa and cushions with different fabrics

16th
To get around this problem, we can decompose the image in background and several
overlay images with transparency, one per texture. In this way, number of pre-calculated
images becomes linear again. If we do the math for previous example: we need one image
for background, 100 for sofas and 200 for cushions. That is only 301 images, quite
manageable.
It is extremely simple to put those images back together with a few lines of HTML code, and
the web browser will render them as single image.
<HTML><HEAD><META HTTPEQUIV="ContentType" CONTENT="text/html;
charset=UTF8"><TITLE>ArahDrape internet test</TITLE></HEAD>
<BODY>
<IMG style="position:absolute" src="sofa_arahne.png"/>
<IMG style="position:absolute" src="sofa_main.png"/>
<IMG style="position:absolute" src="sofa_pillow.png"/>
</BODY></HTML>
But now we are faced with a new problem: commonly accepted web graphics format like
JPEG does not support transparency. Images with transparency are commonly stored in
RGBA format, where A stands for alpha channel transparency. So we have to use PNG
format. But PNG files use lossless compression, not lossy like JPEG. As a result, the PNG
files are several times bigger than JPEG. A decent looking JPEG image will with 1000x1000
resolution will take approximately 0.2 MB, while equivalent PNG image will take 1 MB or
more, due to its precise (lossless) compression. There are other graphical formats, which
support both lossy compression and transparency, for example Google's WebP, but they are
not well supported in browsers [12]. This prevents the use of high resolution transparent
images in e-commerce web site. Most users do not have high speed connection, and are
unable to transfer tens of megabytes with every mouse click.
2. EXPERIMENTAL WORK
In these circumstances, we have decided to abandon the pre-calculated image approach,
and bring part of ArahDrape directly into the web server. We have split the software in the
desktop GUI part and in texture mapping library, which can be called from command like or
as external library with C language interface. This client side rendering approach allows us
to make texture mapping images on the fly; just the ones, which are actually needed. We
can combine several different textures in one image, and deliver the result as JPEG image.
We can use JPEG, the dominant image format in web browsers, with good compression, so
high resolution images are feasible.
Here is a snippet of C code which illustrates calling ArahDrape from the C library:
adrapeSetProject(“/home/capdam/data/drape/sofa.drape”);
adrapeSetTexture(0, “/home/capdam/data/img/sofaFabric01.jpg”);
adrapeSetTexture(1, “/home/capdam/data/img/cushionFabric01.png”);
adrapeSetOutput(“/home/capdam/data/img/export/sofa0101.jpg”);
adrapeRender();
Call from command line or script would look like this:
adrape /home/capdam/data/drape/sofa.drape
3
Figure 3: Background, sofa and cushions as separate images with transparency

16th
t1 /home/capdam/data/img/sofaFabric01.jpg
t2 /home/capdam/data/img/cushionFabric01.png
o /home/capdam/data/img/export/sofa0101.jpg
You can see that in both cases it is very easy to use – define drape project file, give file-
names of textures to replace, and the desired output file. Format of the image file is
recognized automatically based on the suffix.
Command line interface and library interface both have their advantages and flaws. Library
approach is better since start-up overhead is lower, every time we need to call ArahDrape
rendering, we have functions at our disposal and we don't need to start a new process. If we
do ArahDrape from the command line, program needs to load itself in memory and only then
start its calculations. But if the library has even tiny memory leaks (does not free all the
memory after use), then program will occupy more and more memory after continuous use.
After prolonged use in web server, this will inevitably lead to memory starvation, and
program will crash after using maximum available memory. The bad thing is that the whole
web service will crash, since it runs in the same process. If we use command line, then
ArahDrape exits and frees the resources after each invocation. So small memory leaks
never accumulate and cause damage. Even in the worst case, if rendering has some error
and crashes, the web application does not crash, it only fails to display the rendered image.
So we have a tradeoff between speed (call from library) and reliability (call fom command
line).
We have tested the program intensively with tools like Valgrind [13], so we are quite sure
that program does not have significant memory leaks. Still, errors can never be ruled out
100% in non-trivial programs.
The other difference between using pre-calculated drape images and rendering them on the
fly is the use of resources. With pre-caluculated images, we need large storage device (hard
disk or SSD), wheres on the fly rendering needs powerful CPU, preferably multi-core. If we
get lots of concurrent requests for rendering, the response time can slow down, if the
computer does not have enough CPU cores. In the more advanced setups, we could use a
cluster of computers with load balancing.
If we need to increase the speed of rendering, we can marry the two approaches and
implement image caching, by storing the rendered images for future use. In order to to limit
the maximum amount of space the rendered images will occupy, we simply add aging to the
cache, and periodically delete rendered images, which have not been recently used.
At Arahne, we were always liberal with the demo versions of the software, providing potential
users an easy way to test it. Before ArahDrape server version, ArahDrape was save disabled
in the demo, but it allowed printing. So users could try it, but it was impractical for everyday
use. With the advent of ArahDrape server, we have changed this approach. In the desktop
version of ArahDrape, we now allow saving, but prevent printing. This allows potential users
of ArahDrape server to prepare the drape models in advance, even before buying the server
edition. It also allows clients with large deployments to install many ArahDrape desktop
systems, without worrying about the software license cost, and prepare the drape projects in
parallel. The print enabled desktop version continues to be sold to customers, who do not
need ArahDrape server, but only wish to print out the draped images.
3. RESULTS AND DISCUSSION
The server side rendering of ArahDrape was implemented in June 2015, and it is already
deployed in industrial use as a C library in web applications and as a command line
program. It is also used as rendering engine in third party software like Vedo of Bottinelli
Informatica [14]. Vedo can work as an Internet application or be even included in touch
sensitive presentation table. The table can access data from private cloud (remote web
server) or from a local computer.
The system's response time is very good, about 0.2 seconds for 1000 x 1000 pixel image, so
it fully supports interactive use. The software is available for Linux or Mac OS X in 32 or 64
4

16th
bit versions. Latest version of Windows 10 can run unmodified Linux binaries in bash shell,
so Windows is now also a valid deployment platform for ArahDrape server edition [15].
Automatic creation of texture mapped images within the web server also requires some
compromises. If we prepare the texture mapping “manually” with the use of desktop
program, we can fix the starting point of each texture, if it is not aligned in esthetically
pleasing way. We can also adjust shades for very light or very dark fabrics, so that mapping
looks more realistic. In the automatic way, we can not make these adjustments; texture
might start at an awkward point, and some fabrics will look like unrealistic black spot or
glowing white; not blending nicely in the background.
In the future, web development will probably shift to client side rendering in full 3D. We have
made first experiments in that direction using WebGL technology back in 2013 [16]. The
results are very promising, since 3D view does not require any plug-in or special software to
be installed in the web browser. The 3D view is fully interactive and user can change rotation
angle, zoom, position, and choose the texture to be applied. Rendering runs at full speed
supported by the graphics hardware. Once the 3D data is loaded in the graphics engine,
there is no network traffic, and all the rendering is done locally. Besides PC computers, it
also works on tablets and smart-phones.
Rendering software relies purely on HTML5, Javascript and WebGL (JavaScript protocol to
directly access local graphics card). In 2013, the WebGL technology was not yet supported
in all the browsers, but in 2016, most up to date browsers support it [17]. WebGL is still
relatively “dangerous” technology, since a bug in the WebGL software can easily crash the
graphics card, thus crashing the whole computer. This opens doors to dangerous DOS
(Denial of Service) attacks. This problem will need to be solved before wider adoption of
WebGL. Another potential problem is that the texture to be applied must be transmitted in full
5
Figure 4: ArahWeave3D - WebGL rendering of a sofa in browser

16th
resolution to the viewer's device. This is a problem from DRM (Digital Rights Management)
point of view, as it allows easy stealing of complete fabric designs at high resolution. Many
customers would not be comfortable with such a solution. If we use server side rendering,
and only transmit the rendered image from the server, client never gets access to the full
resolution source fabric textures, so this approach is inherently more secure.
Anyhow, these are technological problems, which are solvable. The biggest problem lies
elsewhere. It is very difficult to create realistic 3D objects; it lies well beyond average textile
designer's skill set. Anyone can take a photo and draw regions and grid to apply textures.
But very few people have 3D modeling skills. So we believe the normal draping of photos will
continue to play important role in e-commerce.
4. CONCLUSIONS
We have shown how to change the implementation of e-commerce product presentation
from from display of pre-calculated images, to calculating the draped images directly in the
web server. The system's response time is good enough for interactive use, and we could
also deliver the images faster over a slow network connection, since we can use smaller
JPEG image instead of a series of transparent overlay PNG images.
5. REFERENCES
[1] Rogers, DF; Procedural Elements for Computer Graphics, McGraw Hill, New York,
1985. pp. 355-363.
[2] Gomes, J; Darsa, L; Costa, B; Velho, L; Warping and Morphing of Graphical Objects,
Morgan Kaufmann, San Francisco, 1999. pp 378-379
[3] Gregorčič, A; Peterc, D; ArahDrape User's Manual, http://www.arahne.eu/pdf/adrape-
EN.pdf Online: 1.08.2015. Accessed 16.04.2016
[4] Penelope, http://www.penelopecad.com/productes/producte.php?id_pagina=113&p=6,
Accessed: 16.04.2016
[5] DGS Dua, http://www.msitaly.com/images/software/portrait/Portrait_ita.pdf Accessed:
16.04.2016
[6] Textronic, http://www.textronic.com/cad-design-3d.htm Accessed: 16.04.2016
[7] Pointcarre, http://www.pointcarre.com/3D.html Accessed: 16.04.2016
[8] Bontex, http://www.bontex.it/Stile-e-Design/modelway.html Accessed: 16.04.2016
[9] Nedgraphics, http://www.nedgraphics.com/fashion-design/easy-map-suite/ Accessed:
16.04.2016
[10] ScotWeave, http://scotweave.com/products/product/drape Accessed: 16.04.2016
[11] Ruby Valderama, https://patternbank.com/rubyvalderama?page=3 Accessed:
16.04.2016
[12] WebP, http://caniuse.com/#feat=webp Accessed: 16.04.2016
[13] Julian Seward, Valgrind, http://valgrind.org/ Accessed: 16.04.2016
[14] Bottinelli, E; Vedo: Catalogo Multimediale dei Disegni,
http://www.bottinelliinformatica.it/en/media/prodotti/vedo.pdf Online: 1.02.2016.
[15] Harsh, M; Run Bash on Ubuntu on Windows,
https://blogs.windows.com/buildingapps/2016/03/30/run-bash-on-ubuntu-on-windows/
Online: 30.03.2016. Accessed: 16.04.2016
[16] Drole, B, Peterc, D; 3D for the 3D Challanged,
http://www.arahne.si/home/news/301-3d-for-the-3d-challenged.html Online: 5.01.2014.
[17] WebGL, http://caniuse.com/#feat=webgl Accessed: 16.04.2016
6

16th
Corresponding author:
Dušan PETERC
Arahne, d.o.o.
Novinarska 3
1000 Ljubljana, Slovenia
E-mail: dusan.peterc@gmail.com
7

Peterc_Dušan_full_AUTEX16

Recommandé

Recommandé

Contenu connexe

Similaire à Peterc_Dušan_full_AUTEX16

Similaire à Peterc_Dušan_full_AUTEX16 (20)

Peterc_Dušan_full_AUTEX16