[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:STAR::VATNE
Created:Mon Oct 30 1989
Last Modified:Mon Dec 31 1990
Last Successful Update:Fri Jun 06 1997
Number of topics:3726
Total number of notes:19516

435.0. "No support for IBM bit-order, foo!" by MU::PORTER (waiting for Baudot) Sat Mar 18 1989 00:05

    I created a DDIF file containing a bitmap image. Since the
    image came from a large blue machine, I set the image attribute
    DDIF$_IDU_PIXEL_ORDER to the value DDIF$K_REVERSE_PIXEL_ORDER (and
    though how nice it was not to have to flip bits for a change).
    
    Unfortunately, neither Paint nor the DDIF viewer seem to
    want to take any notice of the stated pixel order, so the
    image came out slightly scrambled.
    
    In order to get it to work, I had to insert some code to
    reverse the bit ordering of each byte (i.e. change the data to
    DDIF$K_STANDARD_PIXEL_ORDER).
    
    Is this an intended restriction of Paint and the DDIF viewer, or
    did I do something wrong?
    
    (Note, I posted here rather than looking for a DDIF or CDA conference,
     since I think it's really a question about the capabilities
     of a couple of DECwindows programs...)
    
    dave
    

T.RTitleUserPersonal
Name
DateLines
435.1Reply from VAS (w/ permission)VIA::BAZEMOREBarbara b.Mon Mar 20 1989 14:0920
From:	ILLUSN::SORNSON      "Well, WE had it TOUGH!" 20-MAR-1989 11:02:56.69
To:	VIA::BAZEMORE
CC:	SORNSON
Subj:	RE: Pixel order problem solved w/ new DDIF proposal?

    Barbara,

    	VAS/ISL V1.1 will have services that can be used to correct the
    problem, but changing attributes in a frame won't ever, all alone,
    solve the problem, since changing attributes (with frame services)
    never changes the data.

    	He can call IMG$PIXEL_REMAP with a global, predefined table that
    will reverse the bits in a byte for each byte.

    	Questions like this should be redirected to the
    EDWIN::IMAGE_SERVICES conference.

    								-mark.

435.2We working on it...EVETPU::BRAMHALLMark BramhallMon Mar 20 1989 16:4716
    Reply .1 describes a routine in the Image Services Library (ISL) that
    will help you rearrange bits within a byte.  And, it says that ISL V1.1
    will have some better services.
    
    The DECwindows applications that deal with images are using ISL for
    their actual image storage.  The current version of ISL (V1.0 as I
    recall) does not have the full set of bits-within-byte and bytes-
    within-integer handling capabilities.  In fact, the DDIF specification
    is missing some needed definitions to fully describe all cases.  We
    (the CDA/DDIF group) are working with the ISL people to get DDIF
    upgraded to contain all needed definitions and to get ISL upgraded to
    support same.
    
    So, sorry for the short term problem, but we're working on making it
    behave just like you really want it to behave!

435.3MU::PORTERwaiting for BaudotMon Mar 20 1989 20:1411
OK, thanks.  Since this is just a hack, I don't really care too
much -- I can flip the bits around in my code.

Note that .1 says that "changing attributes never changes the data".
I don't expect it to.  What I do expect is that if I prepare the
data in big-endian format, and set the appropriate attribute to say
that it's big-endian, then the various DECwindows utilities will treat it
as big-endian.

dave

435.4We all need wider visionSMURF::HOFFMANanywhere in the universeMon Mar 20 1989 22:3918
    Our experience is that the DECwindows application which use DDIF
    Images, in particular Paint and Cardfiler, contain assumptions
    about bit-ordering and byte-ordering in images.  We have identified
    some of these to the developers.  In these cases, at least,
    the Image Services Library routines are available (even on ULTRIX)
    to perform the necessary manipulations.  The applications,
    regrettably, were not written or thoroughly tested with the 
    rest of the world in mind.  The proper approach to this kind of
    situation is to obtain and install a lot more equipment that
    uses non-DEC byte and bit ordering.  X terminals, Sun Workstations,
    that kind of thing.  We've been burned before in DECwindows
    by the lack of such an Interoperability test base and probably
    will be again and again until the equipment is in place.
    
    John Hoffman
    ULTRIX DECwindows Engineering
    

435.5The applications do (did) have a problemRAB::FINNEGANAll of the best intentions are less than one good act.Tue Mar 21 1989 13:0712
   
    John is correct, I have fixed cardfiler for V2.1 of UWS so it works
    on X terminals.  This fix will be in the next base level of VMS (BL2).
    
    The fix was real simple, I added two lines after the create image
    call:
    
          bitmap_image->bitmap_bit_order = NATIVE_BIT_ORDER;
          bitmap_image->byte_order = NATIVE_BYTE_ORDER;
    
    Neal

435.6ULTRIX ISL?AIRBAG::SWATKOBrother, can 'ya spare a Meg?Tue Mar 21 1989 13:558
RE: .4

>  the Image Services Library routines are available (even on ULTRIX)

Where can I get the ULTRIX version?  I've been looking for it.

-Mike

435.7How about inter-system?KALLON::EIRIKURDead Links CoronerTue Mar 21 1989 14:386
    re .5: Neal, with that fix, does the image get stored in a way that is
    readable on systems with other bit-orderings?   Just curious. 
    
    	Eirikur
    

435.8get ULTRIX ISL from the sourceSMURF::HOFFMANanywhere in the universeTue Mar 21 1989 21:5113
    re .6
    
    ULTRIX Image Services Library...
    
    Maybe I jumped the gun a bit here... the ISL is used in our
    development of DECwindows applications, but is not contained
    in the product that we ship.  If you really want it, contact
    Ken MacDonald or Mike O'Connor of the Image Systems Group
    (or whatever they call themselves now).  I'm sure they would
    be pleased to hear of your interest.
    
    John

435.9No only display changedVIA::FINNEGANAll of the best intentions are less than one good act.Wed Mar 22 1989 11:485
    Its only a display issue not a storage issue so I have not changed
    the way I store the data on the disk.
    
    Neal