Path: utzoo!mnetor!uunet!husc6!bbn!uwmcsd1!ig!jade!ucbvax!blackstone.UUCP!dargiro From: dargiro@blackstone.UUCP (Danielle Argiro-S) Newsgroups: comp.windows.x Subject: (none) Message-ID: <8712151835.AA12160@blackstone> Date: 15 Dec 87 18:35:21 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 86 To whom it may concern -- We are still having problems using XGetImage under X11, and were hoping you might be able to help. Here is the scenario: We are on a color DEC GPX workstation with a QDSS driver, using Ultrix 1.2. We are writing a plot package for use under XVision, an image processing package that was developed under X10.4. Now we are converting to X11. Right now, we are trying to get laser output under X11 for our plots. This involves getting an image representation of the plot window, then converting that image to our own XVision format, so that we can send it to our Vlaser (imagen or postscript) laser output routine. Under X10.4, we used XSaveImage, which seemed to work quite well. Now that routine is obsolete, so now we are trying to use XGetImage instead. So: We have a graphics window up on the screen called "workspace". It is a Window of size 512 x 512, starting at (32,32) with relation to the root window (assuming the root window encompasses the entire screen). We are saying window_image = XGetImage (display, workspace, 0, 0, 512, 512, AllPlanes, ZPixmap) so that we can interpret the window_image->data (the window info) to put into our own image structure and send the plot to the laser printer. But when we send the image to be displayed, it looks only vaguely like the workspace contents. While some parts of the displayed image are recognisable, it seems almost as if it is interleaving garbage with the valid output. It also seems to be taking too much information in the "width" direction (along the right side of the display were words that had apparently been picked up from the text on the background window) and not enough information in the "height" direction (we recognised the top 1/5 of our plot at the very bottom of the display). We have a routine that will display a raw image without the header, and the results of displaying XImage->data without any interpretation of the data were the same as the results of displaying the image *after* our own specific interpretation of the data. Very odd. Perhaps it would help to know that this is what our XImage structure came out as: width = height = 512; /* what we specified */ xoffset = yoffset = 0; /* these too */ format = ZPixmap; /* fine */ byte_order = LSBFirst; /* what does this mean in terms of how we interpret the image ? */ bitmap_unit = 32; /* what does this mean ?*/ bitmap_bit_order = LSBFirst; /* again, see above question */ bitmap_pad = 8; /* what does this mean ? */ depth = 8; /* ok */ bytes_per_line = 512; /* ok */ bits_per_pixel = 8; /* ok */ red_mask = green_mask = blue_mask = 0; /* bits in z arrangement ? can you please explain this */ So what we need to know is, how does the byte_order affect us? What about the 3 "bitmap" variables? (we will be using XYformat in the future) How do the red_mask, green_mask and blue_mask affect the bit arrangement? How do the variables interact to give us complete information about the structure of the image data? Could any one or more of them be responsible for the strange (and wrong) appearance of the resulting image? Is there anything about the arrangement of the bits in each byte that we should know about before we interpret the data? We have read the documentation several times, but it simply doesn't give enough detail to clarify these issues. If you can answer any or all of our questions, or if you can give us advice that might help us resolve our problem in any way, it would be greatly appreciated. And even if you can't -- Merry Christmas & a Happy New Year! Thanks, Danielle Argiro Mark Young University of New Mexico 277-0801 (work) Albuquerque, NM 87131 242-2427 (home) dargiro@blackstone@hi.unm.edu@hc.dspo.gov (ARPA)