RE: [cgmo-webcgm] One more idea for WebCGM 2.0...

Dieter,

I'm unclear exactly what you are proposing.  Originally you
said:

At 02:09 PM 7/5/2004 +0200, Dieter Weidenbrueck wrote:

[...]

-----Original Message-----
From: Dieter Weidenbrueck
[mailto:]
Sent: Montag, 5. Juli 2004 10:35
To: CGM Open Technical Committee
Subject: [cgmo-webcgm] One more idea for WebCGM 2.0...

I suggest that we consider one more addition to WebCGM 2.0, which is
the addition of a preview image in a separate picture.
 
ATA already allows for this, and I think it is a good thing to do.
Users want to catalog CGM files in databases, and we are
often
asked for thumbnails or preview images.
 
The picture could use a reserved name, e.g. "Preview
Image".
 
Thoughts?

ATA allows "reduced resolution raster" images.  T.15.2
(ATA 2.9):

There shall be 1 illustration per metafile.
For reduced raster resolution images of first
picture additional pictures are allowed.
Reduced raster resolution images shall have
the picture identifier of the first picture con
catenated with the string RRn, where n is
the reduced resolution image number. For
symbol library metafiles, an unlimited
number of pictures is
allowed.

How does your proposal differ from this?  I.e., what significant
functional differences would justify defining a similar but different
mechanism?  (Vendors:  does anyone implement this?). 

As I understand ATA spec (2.9 quoted above), the naming mechanism for a
lone raster thumbnail for 'myPicture' would be 'myPictureRR1', and that
raster (TileArray) thumbnail would be the second picture.

Also I'd like to better understand Dieter's use case (which was in reply
to Ulrich's "MetaWeb builds thumbnails on the fly"
comment)...

At 02:09 PM 7/5/2004 +0200, Dieter Weidenbrueck wrote:

Hi
Ulrich,

 

if we provide a picture that is
encoded in a predictable and simply-to understand way (only tiled raster,
only one compression, preferably png for color, g4 for b/w), then a
simple application could extract this image for thumbnail
use.

Also, it becomes possible to
show this image in a preview dialog of a file open dialog without having
to parse the entire CGM.

 

The benefit is that on a web
page showing hundreds of thumbnails you don't have to use hundreds of
viewer instances. You could extract the images and store them on a
server. 

So Dieter would have an application on the server that would extract the
thumbnail from each of possibly hundreds of CGMs, and put the thumbnails
on a Web page.  Since you are avoiding "hundreds of viewer
instances", then you are either:  putting them on the server
Web page as pure PNGs, referenced from HTML (yes?); or, stuffing them all
into a single one-picture CGM instance somehow (probably not this
option?); or ...?

I
guess it would also be possible to extract the preview on the fly,
however, that would require download of the whole file anyway, so it is
not an advantage timewise.

This is the part I don't understand (specifically, why the
"download" complication).  Why couldn't a server-side
application generate raster thumbnails from the whole CGM collection, and
store them on the server (once and for all)?  This is just like your
scenario, except for your scenario the server-side application *extracts*
a thumbnail that is stored in each CGM file, whereas for this variation
the server-side application *generates* the thumbnail from each CGM
file.  I don't see where "download" is necessary in either
case.

-Lofton.

-----Original Message-----
From: Ulrich Laesche
[mailto:]
Sent: Monday, July 05, 2004 1:59 PM
To: ; CGM Open Technical Committee
Subject: RE: [cgmo-webcgm] One more idea for WebCGM
2.0...

Dieter,
 
what would be the difference between rendering a CGM image twice (as
a preview image and as a full view) and your idea?  In MetaWeb, we
offer an option to get rid of the tool- and scrollbars when displaying a
CGM file in a very small window (i.e., preview).  In our JAVA
solution eReview we generate small PNGs on-the-fly if a customer requests
thumbnail display.  In both approaches links are added from the
thumbnail (CGM or PNG) to the original view.  Is it the latter
approach you envision?
 
Regards
Ulrich