File:533573586
L.Update:
18/02/2016 02:10:00
Type: report
ISHTAR Project - Contract IN31018I
Page: 1 / 7
Author: Piero De Sabbata
Printed: 18/02/2016
Report of the general meeting in Bologna July 20-21
2000-07 – Final Version
This report is diffused only via e-mail, it can be obtained also from the WEB site
http://spring.bologna.enea.it/ishtar, document MG011-012.
The agenda of the meeting is MG011-011-Agenda July 20-212000.doc
Participants
Piero De Sabbata (Enea)
Sergio Fantin (Enea)
Giampaolo Benatti (Coin)
Mauro Bonaldo (Coin)
Fernando Milhano (Neosis)
Joviano Silva (Neosis)
Alexandre Yip (Neosis)
Salvatore Angotti (Cad Modelling)
Riccardo Redaelli (Hitman)
Demonstration of the WEB Portait, release 1 (Mauro Bonaldo, Coin)
WEB Portrait is the module for texture mapping. The system has been adapted for Coin from Portrait, a stand alone
product of the company DGS. This release is able to support the texture using only one kind of fabric for each image,
while the next versions should be able to support multiple kind of fabrics.
Mr Bonaldo presents the system running on the Coin server thorugh a standard browser linked to the Internet.
The system is accessed through a ASP page, the tester can define the base image, the fabric (texture) and the resolution
of the final image (width 640, 800, 1024 pixels) according with document AD024-016-Technical open issues.doc.
Further there is a problem of faithfulness of the colours: it appears very difficult to optimise the ‘reference color point’
in the images of the models, as a result the rendered images appear a bit different from the aspect of the pure square of
fabric.
The results of the functional tests of Coin demonstrate a period between 9 up to 87 seconds may be necessary to obtain
the downloaded images after the start of the texure mapping process. The worst results derive from large image (time to
download) and too many regions in the photography to be textured (time to process the image).
Some other problems of quality of the texture were reported to DGS.
Coin will repeat the tests after adding a second processor to the server to speed up the process.
Furthermore the quality of the result appear to depend upon the quality of the contouring operations: about half an hour
is the mininum time required to prepare a single image.
To simplify the preparation of the catalogue it is decided to store only a set of data regarding the texture module for
each model; this means that every fabric will be processed with the same data, only changing the image of the texture.
The system will receive the image for texture already prepared, in the same scale, with a repetible module and width
and height depending on the pattern (the images will be derived from that of the catalogue of fabrics but could be cut to
optimise squares, lines, etc).
File:533573586
L.Update:
18/02/2016 02:10:00
Type: report
ISHTAR Project - Contract IN31018I
Page: 2 / 7
Author: Piero De Sabbata
Full image:
Selection of module:
Printed: 18/02/2016
Image for texture:
- The next version should overcome some problems that were detected and is scheduled for the end of July 2000.
- To enhance colour appearance it is decided to try to employ images of the fabrics that are taken from photo camera
instead of scanner for the texture mapping (this apply to fabrics that were not scanned by CNR-ITIM).
Also a part of the images of the fabrics for the catalogue will be taken using a photo camera and will be not flat but
‘waved’ to test the customer acceptance of the two representation of the fabric.
- About the interface toward the navigator module, it is a call to page ASP, it is established that the code of the model
and of the fabric will be in the parameters of the ASP call.
Related to each model will be stored the TIF image and the .map (contouring areas) and .grid data (grids and
deformation) files: for each model the files will have the same name (the code of the model) with different extensions.
The image of fabrics to be used as texture will be files .TIF and the name will be given by partnumber and
colournumber of the fabric (es. part: 10015, colour 00538: image 1001500538.tif).
Interface to the WWWEB portrait: HTTP Url to run rendering
To run rendering you must call the following URL:
http://third.gruppocoin.it/webportrait/Rendering.asp?IDModel=xxxx&IDFabric=yyyy&Resolution=kkkk
where:
xxxx is the ID of model (image filename also).
yyyy is the ID of fabric (image filename also).
kkkk is the of image’s resolution.
Resolution’s format are width pixel, comma and height pixel. For example if you wish your image with a max
resolution of 800 width pixel and 600 height pixel you must write kkkk in the same format: 800,600.
Demonstration of the second release of the navigator (Fernando Milhano, Neosis)
A trial session on the navigator http://neoshop2.neosis.pt/ish is presented to the partners.
The following is the list of the modification or comments of the partners:
- Preferences and other customisation of the interface (such as logo) offer an interesting flexibility and are setted in the
backoffice
- When index of available models or fabrics are too long they will be paged (buttons to go to the next/previous page)
- about the form presenting Model:
- sketch and details should be linked to buttons and should appear is a separate popup window (to be compared
with the image of the model)
- the same to call texture mapping module
- zoom should be available as for the fabric
- description and maintenance should appear with a ‘more details’ button, like in fabrics
- the form for fabric is OK, but the calibration and visualisation applet (from ENEA and CNR-ITIM) has some bugs if
the image exceeds the size of the window (scrolling). Enea will procure to fix the bugs.
- customer identification form
File:533573586
L.Update:
18/02/2016 02:10:00
Type: report
ISHTAR Project - Contract IN31018I
Page: 3 / 7
Author: Piero De Sabbata
Printed: 18/02/2016
- the shop and sales retailer version cannot use e-mail to identify the customer and a password is not necessary
(both only in the Internet version); name and surname or another free code should be better (the system assures
that they are unique);
- fields phone is not ‘required’, but ‘optional’
- field birth date is not ‘required’ but ‘optional’
- field ‘provincia’ (in English ‘district’ or ‘state’ in USA) is lacking
- repetition of the fields for contct and delivery address should be avoided (‘please fill if different from the
customer address’)
- after the user identification, if the model table ‘cercadrop’ do not contains the sizes of the customer the system should
anyway enable the session for sizing (only a warning should be emitted).
- if a order is freezed, the necessary fabric is still blocked for a period of X (to be established) days
- A specific paragraf is dedicated to sizing form.
Sizing form
- always display on top model , size, drop, stature of the customer
- a different approach has established for the data to display after the BMA (were body measurements are taken by
hand or via Scanfit); the following table shows the logic organisation in columns of the interface.
A - Body
measurements
(not editable)
40
...
120
two actions available
B- Model
measurements for
that size, drop,
stature
(not editable)
35
22
100
66
CHECK
C- Required
variations
(editable)
D-Absolute
measurements of
customised model
(editable)
2
1
-4
??
37
23
96
ACCEPT ANYWAY
Initial values
To help the people that take measurements it is important to suggest modifications to the model for a standard made-tomeasure dressing.
If the body measurements are not taken (people only work on a reference garment) the first column is empty;
if only some of them appear the cells remain empty for the other.
Else if, for each specific type of measurement (row in the schema), the body measurements exists and in the database
the parameter P exists -that is the difference between body size and model size (arms versus sleeves)- it is possible to
apply the following formula to calculate the initial values of the column C and D (in the database there is a specific field
that says –‘Y’ for yes or ‘N’ for no- when it may be applied, introduced in the latest documents of Hitman AD024-001)
D=A-(B+P1))
C=D-A
If the value P or the body measurement does not exist (or the formula cannot be applied –according with the database
information for that acronym-), the column D is initially filled with the measurements of the reference model and C is
empty or filled with ‘??’.
After, these initial values can be freely changed by the user (for example to follow the taste of the customer that wants
his way of dressing, for example, a special lenght of the sleeves), the whole measurement is in column D, or only the
required changes in respect of the model .
Check and Force
Independently from the presence of body measurements, the user is free to input the data of variations that he wants and
only at the end a check is performed and the system might signal that certain (higlighted on the display) measurements
are out of the range of the size, drop, stature of the customer. The user may decide to change the size, drop, stature on
the display and then the column B, C, D are recalculated based on the new reference and a new check may be
performed, else he can decide to accept anyway the data.
File:533573586
L.Update:
18/02/2016 02:10:00
Type: report
ISHTAR Project - Contract IN31018I
Page: 4 / 7
Author: Piero De Sabbata
Printed: 18/02/2016
A sample session about Check and Force
A first set of data, referred to size 44, drop 2, stature tall; the user fills column C-Variations; the system derives
automatically also column D
Model size 44, D 2, S tall
Type of measure
B-Model
C-Variations (+ or -)
D-Absolute
XXX
80
-5
75
YYY
12
-1
11
ZZZ
40
-8
32
Then the user check the data: the internal rules establish that, for example, measurements type XXX cannot accept an
absolute variation greater then 2 cm.
A warning signals that type XXX has a variation too high, a change of size is suggested.
The user has two ways: ‘accept anyway’ to force the data to the system or try to change the size.
The user choose a size=42
The system recalculate the new values starting from the new values for the model. Now the user can check again.
Model size 42, D 2, S tall
Type of measure
B-Model (new values)
C-Variations (D-B)
D-Absolute (invariated)
XXX
76
-1
75
YYY
10
0
11
ZZZ
36
-4
32
The aim of this approach is to allow the user to find the best compromise between alteration on different sizes of the
same model (today there is not a formalised algorythm of optimisation of the choice).
Personalisations
The previous form regards only measurements that have a reference in the model.
There others measurements necessary to customise the model that are not referenced to the model (for example shoulder
position); this data should be referenced after having defined size, drop, stature and all the changes in the model. The
same screen with two groups or a subsequent screen.
The backoffice to customize the list of adaptations is demonstrated.
The partners point out the lacking of the management of two fields:
- initials or name
- notes
These informations are text fields that the user may fill with free text.
Mr Redaelli points out that some of the fields in the acronyms table that he sent via e-mail were not implemented. The
document AD024-021-acronymsettingHITMAN.xls is printed and explained to mr Milhano and Silva.
Attention: adaptations like ‘standing’ may be thought as referenced to the model: are specific of the order; a new model
might require different adaptations: this information should not be stored as a customer’s feature.
Help for the user
The user (internet user or sales personnel) might require some kind of help to better understand the meaning (or the best
way to take) a measurement: for each row of the form sizing there should be a button to get a window help with an
image and a text about that specific measurements, avoiding a non-localised help of the whole page.
The document MM021-015-misurazione Trousers.zip and MM021-016, produced by Coin in June 1999, are given to
Neosis as an example toghether with the sizing book of Hitman.
Shop version
Coin asks to have the possibility to add a input field for the order number in the order form for the shop version.
File:533573586
L.Update:
18/02/2016 02:10:00
Type: report
ISHTAR Project - Contract IN31018I
Page: 5 / 7
Author: Piero De Sabbata
Printed: 18/02/2016
Test of the Body Measurement Assistant (Angotti, Cad Modelling; Fernando Milhano,
Neosis)
The system BMA runs from an ASP page on a standard browser and is called via the navigator.
The following is the list of the comments from the partners:
- It is necessary that all the data about the body are sent to the navigator (not only size, drop, stature) at the end of a
BMA session. This will be realised by CadModelling as soon as possible.
- BMA is based on an internal database structure that is on the client or on the server; the next version will use the same
database of the navigator and a ADO component (instead of DAO for MS-Access) to have independency from the
database management system thorugh ODBC bridge. These change will require a bit more time.
- CadModellinh and Hitman will check jointly the system with a ‘test set of data’ to be sure of the quality of the results
about sizes.
- BMA will display the family of models choosen by the user and will highlight the fields of measurements that are
required for that kind of models; the user is free to fill-in also the fields of all the other measurements.
- the adaptations as standing and so on that presently are in the BMA will be moved to the sizing form of the navigator
(these informations are configurable through the backoffice modules).
Decision about EDI and XML order exchange
The increasing interest in the XML technology and the contemporary lose of interest in technology such us EDI is
inducing the partners to reconsider the approach of the order transmission between the retailer and the supplier; the use
of EDI technology (established two years ago during the feasibility study) appears less and less to be able to guarantee
the feature of 'open and connectible' system that are one of the requirements of the project and an increasing interest is
toward the XML solutions.
Differently from two years ago, now it is difficult to say that a EDI system is better open to the world than a system
based on XML documents
Presently has been developed a document following EDIFACT 93a that is able to support a made-to-measure order (see
AD024-011-ish-ORDERS1.xls). The architecture supporting these orders is already established and requires the service
of an external BDE service that has been clearly identified in the CSI company (it is only a problem to activate or not a
contarct with this company, being all the technical and procedural problems already solved).
On the contrary the already established front-end for booking documents is quite simple to support and is based on
XML.
The draw back is that presently does not exists an accepted standard about XML documents for the textile sector.
The partners decide that the trial actions will start using an XML document developed fastly by Neosis but that they
will study the international XML frameworks availables for generic commercial documents (like Biztalk, ebXML or
ecXML) to build a document that is compliant with one of them and then to propose a their solution for the made-tomeasure orders. Enea will study these aspects of the problem.
The backoffice module
The backoffice module http://neoshop2.neosis.pt/ishman , necessary to load and maintain the database has been
discussed and presented.
- the main point is that the interface require too much operations for simple input (a form and a click for each datum):
many data in the same form should be better.
- the tables cercadrop is complex and contains data from 11 models per N sizes x M drops x 4 stature. Because Hitman
has excels files of these data it is decided that Neosis will implement a tool to automatically upload the tables.
- other minor updates are discussed.
Neosis point out that the URL http://neoshop2.neosis.pt/ish is only for test purpose with fictitious data, while the URL
http://neoshop2.neosis.pt/ishman contains real data that Hitman is uploading. For this reason it is impossible to
immediately view the results of the uploaded data.
File:533573586
L.Update:
18/02/2016 02:10:00
Type: report
ISHTAR Project - Contract IN31018I
Page: 6 / 7
Author: Piero De Sabbata
Printed: 18/02/2016
Neosis announce a new release of the user manual to describe the new feature of the backoffice (see document US026002-manual_ishtar_versao_ingles(A) .doc).
File:533573586
L.Update:
18/02/2016 02:10:00
Type: report
ISHTAR Project - Contract IN31018I
Page: 7 / 7
Author: Piero De Sabbata
Printed: 18/02/2016
Planning of activities
Because of the absence of Alferano the activities dealing with the deployment in the Internet and Sales representatives
channels were not discussed during the meeting.
August 18th
August 21
Neosis
Neosis
August 25
Coin, All
August 30
August 30
August 30
September 211
September
12
Neosis
Neosis
Hitman
Coin, Hitman
September
30
September
15-30
September
28-29
October 1st
Coin
DECISION to confirm the following activities
shop layout completed
Coin, Hitman
training of shop personnel
All
general meeting in Lisbon
Coin
start up of the trial sales in shop,
Hitman’s front-end is assisted by human operator
All
released a first pre-release of the navigator and of the backoffice
release 1 of backoffice (together with all the data already uploaded)
is sent to the COIN’s server
Coin setup its server,
from now all the upload of data are executed on the backoffice running on the COIN
server
release 1 of the navigator module
release of the feature to automatically upload the cercadrop table
defined a test set of all the models and two fabrics
test of the Navigator and backoffice
videoconference Bologna-Lisbona (Munich?) about results of the test; at 15.30 Italian
time