rcs64241@zach.fit.edu (Shyam Kotha /ADVISOR-Newman) (10/20/90)
Hi, I had strted on X windows(Open Look 2.0) recently and I am working on Image package and not sure how to do the following, can some one help me on this. I want to acess pixel information of an image and manipulate them for writing Image processing routines. I dont want to use XPutpixel etc as that slows down the whole thing, is there any way I can assign a arry containing the pixel values to the data of the image. what I am looking for is something like assigning memory pixrect in Sunview. (i.e) equivalent for mpr_d(mem)->md_image =(short *) buf; where buf is an array containing the pixel values and mem is a memory pixrect. Thank you. Sincerely Shyam Kotha Email : sam@yacht.ee.fit.edu
mouse@LARRY.MCRCIM.MCGILL.EDU (10/20/90)
> I want to acess pixel information of an image and manipulate them for > writing Image processing routines. I dont want to use XPutpixel etc > as that slows down the whole thing, is there any way I can assign a > arry containing the pixel values to the data of the image. > what I am looking for is something like assigning memory pixrect in > Sunview. (i.e) equivalent for > mpr_d(mem)->md_image =(short *) buf; > where buf is an array containing the pixel values and mem is a memory > pixrect. XCreateImage takes a pointer to the data as one of its arguments. Unfortunately there is no clean way (as far as I can tell) to get an XImage with bit and byte sex set the way *you* want them instead of the way *the server* wants them. It works, in my experience, to just bash the values in the structure after creating it, but this is hardly a proper solution. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) (10/22/90)
Shyam Kotha writes: > I want to acess pixel information of an image and manipulate them for writing > Image processing routines. I dont want to use XPutpixel etc as that slows > down the whole thing, is there any way I can assign a arry containing the > pixel values to the data of the image. You can access the image data directly through the data field of the Ximage structure. However, this can get pretty tricky since you potentially have to keep track of the padding, depth, byte and bit order and image format. Not all of these are under your control. You might want to use direct access to the data in the most common circumstances you might come across (eg. depth == 8 && format == ZPixmap) and XGetPixel/XPutPixel for other circumstances so that your application will at least run (albeit rather slowly) on displays that you didn't anticipate. Chris Flatters
etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) (10/22/90)
The XPutPixel is not too bad to use as it is very smart about 8 and 1 bit images. However, a smart implementation for 24 and 32 bit devices would be much appreciated. It has been my experience that using XPutPixel and XGetPixel saves much time and headache when dealing with new depths and devices. We have found the that slowness is tolerable knowing that an application will always work with any depth and bit-byte ordering. -- Eric Taylor Baylor College of Medicine etaylor@wilkins.bmc.tmc.edu (713) 798-3776
randy@erik.UUCP (Randy Brown) (10/22/90)
Shyam Kotha writes: > I want to acess pixel information of an image and manipulate them for writing > Image processing routines. I dont want to use XPutpixel etc as that slows > down the whole thing, is there any way I can assign a arry containing the > pixel values to the data of the image. Have you looked at the MIT shared memory extension? It is undocumented (except in a recent post by Jonathan Corbet, corbet@stout.atd.ucar.edu, in message-id 9010111941.AA00341@mead.atd.ucar.edu), but the source is on the R4 tape under mit/extensions. It seems to be just what is needed for image processing (except, of course, that it only works when both client and server are on the same machine). ... rb (uunet!erik!rbrown)
jimf@SABER.COM (10/23/90)
|The XPutPixel is not too bad to use as it is very smart about 8 and 1 bit |images. [...] We have found the that slowness is tolerable knowing that |an application will always work with any depth and bit-byte ordering. If you're trying to be interactive it's *not* tolerable. I get around this by defining my own image format and slamming it into the XImage structure. The code that transforms into server-native format is much more efficient than the PutPixel/GetPixel code so there's a big jump in throughput. jim frost saber software jimf@saber.com
etaylor@wilkins.iaims.bcm.tmc.edu (Eric Taylor) (10/23/90)
In article <9010221734.AA18340@armory>, jimf@SABER.COM writes: |> |The XPutPixel is not too bad to use as it is very smart about 8 and 1 bit |> |images. [...] We have found the that slowness is tolerable knowing that |> |an application will always work with any depth and bit-byte ordering. |> |> If you're trying to be interactive it's *not* tolerable. I get around |> this by defining my own image format and slamming it into the XImage |> structure. The code that transforms into server-native format is much |> more efficient than the PutPixel/GetPixel code so there's a big jump |> in throughput. |> |> jim frost |> saber software |> jimf@saber.com Yes we did this originally, too, but found that some servers do *NOT* accept any old format that you stuff into an XImage structure. Does an X server have to accept any XImage structure (but do it slowly if it does not match the hardware format)? -- Eric Taylor Baylor College of Medicine etaylor@wilkins.bmc.tmc.edu (713) 798-3776
mouse@LARRY.MCRCIM.MCGILL.EDU (10/24/90)
>>> The XPutPixel is not too bad to use as it is very smart about 8 and >>> 1 bit images. [...] We have found the that slowness is tolerable >>> knowing that an application will always work with any depth and >>> bit-byte ordering. >> If you're trying to be interactive it's *not* tolerable. I get >> around this by defining my own image format and slamming it into the >> XImage structure. The code that transforms into server-native >> format is much more efficient than the PutPixel/GetPixel code so >> there's a big jump in throughput. > Yes we did this originally, too, but found that some servers do *NOT* > accept any old format that you stuff into an XImage structure. Does > an X server have to accept any XImage structure (but do it slowly if > it does not match the hardware format)? According to my skimming of the protocol document, images must be presented to the server in its native format (which the client finds out about at connection setup). It is up to the client to do any reordering necessary. However, the Xlib document says, when talking about XImage structures, You may request that some of the members (for example, height, width, and xoffset) be changed when the image is sent to the server. That is, you may send a subset of the image. Other members (for example, byte_order, bitmap_unit, and so forth) are characteristics of both the image and the server. If these members differ between the image and the server, XPutImage makes the appropriate conversions. So if this isn't happening, there's a bug in XPutImage, or perhaps the server is rejecting data which in fact actually conforms to the format it has requested. Either one calls for a bug report - but make sure you have it right which one it is; an erroneous bug report is often almost worse than no bug report at all. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
jimf@SABER.COM (10/24/90)
|>> I get |>> around this by defining my own image format and slamming it into the |>> XImage structure. The code that transforms into server-native |>> format is much more efficient than the PutPixel/GetPixel code so |>> there's a big jump in throughput. |> Yes we did this originally, too, but found that some servers do *NOT* |> accept any old format that you stuff into an XImage structure. As "der Mouse" said, if it's not working then it's a bug in your Xlib since it normally does the conversion before sending the image off to the server. My application works across a huge range of servers so this can't be a very common problem. The only thing I can think of is that you supplied an n-plane image for a server that didn't support n-plane pixmaps, something that XPutImage won't correct for you and which will generate an error from the server. That's extremely common. Code that does necessary conversions and ships arbitrary images off to a server is available in my xloadimage program in send.c with a number of different image processing functions. This code is fairly fast and very portable so it might be worth looking at. It can be picked up by anonymous ftp from expo.lcs.mit.edu in /contrib/xloadimage.2.01.tar.Z. Happy hacking, jim frost saber software jimf@saber.com