From: mek@hydrox.enet.dec.com (Mark Klamerus)
Newsgroups: comp.graphics
Subject: ddif converters
Date: 21 Aug 92 14:32:17 GMT
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
Newsgroups: comp.graphics