NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/graphics/9046

Internet Message Format | 1992-08-21 | 5.2 KB

Path: sparky!uunet!olivea!decwrl!pa.dec.com!hydrox.enet.dec.com!mek
From: [e-mail] (Mark Klamerus)
Newsgroups: comp.graphics
Subject: ddif converters
Message-ID: <[e-mail]>
Date: 21 Aug 92 14:32:17 GMT
Lines: 124
X-Received: by usenet.pa.dec.com; id AA19872; Fri, 21 Aug 92 07:32:25 -0700
X-Received: by enet-gw.pa.dec.com; id AA15200; Fri, 21 Aug 92 07:32:17 -0700
X-Received: from hydrox.enet; by decwrl.enet; Fri, 21 Aug 92 07:32:17 PDT
X-To: comp.graphics.usenet
X-Apparently-To: comp.graphics.usenet


    hi,

    I'm an imaging systems consultant for digital.

    I've posted memos before regarding tools for getting to/from
    ddif and thought I might follow on at this point.

    Yes, there are tools for getting to and from ddif (image).
    The majority of these run on (only on) DEC platforms.  A brief
    reason for this is that DDIF (Digital Document Interchange Format)
    is a compound document format.  Digital imaging rests on compound
    document, not image-only documents.  Our imaging products/tools
    use this DDIF.

    In order to make it easier/simpler to work with ddif, we've created
    layers of abstraction.

    The lowest level describing our compound documents is ASN.1.
    All Compound documents (DDIF) are described via ASN.1.  ASN.1 is
    not the simplest thing in the world to work with directly, but
    it is an industry standard notation and formatting convention
    supporting compound documents via tags and nesting.

    To make the use of ASN.1 simpler (as well as manage the reading
    and writing of it on different platforms), Digital created the
    Compound Document Architecture (CDA) libraries.  These routines
    allow for the creation of ASN.1-based compound documents without
    having to know anything (well, not much) about the physical layer.
    You do need to know the overall architecture however.

    In order to manage image more easily, Digital created a suite of
    imaging routines (several libraries) which rest on the CDA libraries.
    All our imaging products use these layers.  With these routines
    a simple image reading, decompressing, scaling, display routine
    would be built as:

        .
        .
        .

        ImageCtx = ImgOpenFile(
            ImgK_ModeImport, ImgK_FtypeDDIF,
            strlen( filename ), filename,
            0, 0 );

        ImageFid = ImgImportFrame( ImageCtx, 0 );

        ImgCloseFile( ImageCtx, 0 );

        .
        .
        .

        ImgGet( ImageFid, Img_CompressionType, &ImageCmp, 4, 0, 0 );

            if ( ImageCmp != ImgK_PcmCompression )
                    ImgDecompress( ImageFid );

        .
        .
        .

        ItemInfo( itmlst[ 0 ], IdsNprotocol,    Ids_XImage );
        ItemInfo( itmlst[ 1 ], IdsNworkstation, display );
        ItemInfo( itmlst[ 2 ], IdsNwsWindow,    window );
        ItemInfo( itmlst[ 3 ], NULL,            NULL );

        presentation = IdsCreatePresentSurface( itmlst );

        .
        .
        .

        ItemInfo( itmlst[ 0 ], IdsNscaleMode, Ids_Flood );
        ItemInfo( itmlst[ 1 ], NULL,          NULL );

        rendering = IdsCreateRendering( ImageFid, presentation, itmlst );


    I've left out the non-image components, but in general, it is a very
    simple process in which the programmer doesn't need to know much
    at all about the image.  There are much lower-routines available,
    but most people choose not to use them.


    This is a 4-GL (vs a 3-GL or assembly) approach to imaging and has
    the same advantages/drawbacks that 4-GLs have vs. 3-GLs.  it is easy
    to use, but wraps you in an environment and way of doing things.
    This approach works where the environment exists, but isn't self-
    sufficient.  That is, you need to do Digital imaging on platforms
    where the cda and imaging libraries are present.  At this time, that
    is limited to Ultrix, and VMS.  The CDA routines are present on
    MS-DOS, Sun, and OS-2, but not the imaging routines.  Converting
    to/from ddif images must be done on a Digital system.  In turn,
    on the digital platforms, there are converters to/from gif, tiff,
    paint, pnm and other formats.  We generally use other converters,
    such as the pbmplus toolkit to get from one of these to anything
    more specific.


    As a result of public outcry (both internal to DEC and externally)
    and because one of our imaging OEMs will be providing some funding,
    I'm developing a library which works directly with the physical layer.
    Nothing other than the ANSI 'C' libraries is being used in these
    libraries.  I've finished the ASN.1 aspects of the program and am
    now working on what to do with the data plan.  I'm first working
    on reading/writing black and white (uncompressed), then compressed,
    then grayscale and color (uncompressed), then compressed.

    My initial target is tiff, but pnm, fax, and gif seem reasonable.
    At that point, I expect to stop.  We still need to consider the
    support and business issues of just sending these out over the
    internet.  If someone else wishes to engage in a similar effort,
    there are published documents on asn.1 and digital's use of it
    (our particular architecture using it).  I expect it may still be
    1-2 mo before the routines I'm engaged in developing will first
    become available, so long as the OEM provides the funding, possibly
    longer if they don't.   It's not impossible to work with ddif.  It's
    very easy on a digital platform (just like using a 4gl would be),
    but without the libraries it is still possible.


    Mark