Article View: comp.graphics.avs
Article #48Re: Problem with RGB byte ordering between AVS modules
From: Ethan A Merritt
Date: Tue, 11 Aug 1992 17:20
Date: Tue, 11 Aug 1992 17:20
41 lines
2807 bytes
2807 bytes
In article <1992Aug11.143929.1993@convex.com>, dlc@convex.com (Dominique
Le Corre) writes:
|> In article <1992Aug10.195155.4648@u.washington.edu> I wrote:
|> >
|> > The area around the cursor is obtained using the call XGetImage(),
|> >from which the (4 bytes per pixel) pixel array is copied to the data field
|> >of the output (AVSfield_char) port. All very well except that on my
|> >DECstation this results in the RGB bytes being interpreted in reverse
|> >order.
|> I would suspect this has to do with little/big Indian.
|> Anyway, I've got no explanation, but a workaround:
|> Feed your image into 3 extract scalars (R,G,B), and then back into combine
|> scalars, crossing the R & B ports.
Ugh. The mind reels at the wasted CPU cycles and memory usage
(remember that the cursor tracker is in a for(1) {...} loop!). I can do
much better than that by simply inverting the bytes per brute force inside
the track_cursor module. Even that is a distasteful waste of CPU cycles
though, especially since the image display module is apparently going to do
it all over again just to get back where I started.
Perhaps I was too terse in my original complaint. I know perfectly
well that the problem is in whether the byte order is little/big endian. I
also know that there is a field in the XImage structure which describes this.
The problem is that the AVSfield_char structure _doesn't_ have such a field
(that I can see anyway) so I can't pass this information on with the data.
Others have suggested that I check the .../avs/port.h header for correctness,
but this is a red herring (I think). The data is perfectly consistent inside
the module I'm compiling; it's after it goes out the output port that I'm
unhappy with its treatment!
Let me try again, with a more specific request:
Anyone know how to either (1) specify which endedness an XImage structure
will have upon return from XGetImage, or (2) persuade the internal AVS
display image modules to use a particular endedness, or (3) use some
entirely different mechanism for cursor_tracking?
still head-scrathing,
Ethan A Merritt
Technical Details
Message-ID:
<1992Aug11.172034.23919@u.washington.edu>Path:
arc1-ca.pugleaf.net!sparky!uunet!dtix!darwin.sura.net!mips!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!batcomputer!cornell!uw-beaver!news.u.washington.edu!provolone.bchem.washington.edu!merrittReferences:
<1992Aug10.195155.4648@u.washington.edu> <1992Aug11.143929.1993@convex.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!dtix!darwin.sura.net!mips!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!batcomputer!cornell!uw-beaver!news.u.washington.edu!provolone.bchem.washington.edu!merritt From: merritt@provolone.bchem.washington.edu (Ethan A Merritt) Newsgroups: comp.graphics.avs Subject: Re: Problem with RGB byte ordering between AVS modules Message-ID: <1992Aug11.172034.23919@u.washington.edu> Date: 11 Aug 92 17:20:34 GMT References: <1992Aug10.195155.4648@u.washington.edu> <1992Aug11.143929.1993@convex.com> Sender: news@u.washington.edu (USENET News System) Reply-To: merritt@u.washington.edu Organization: University of Washington Lines: 41