ximtool and 16bit color
Doug Williams wrote on May 17, 1999
We recently purchased some 16bit color xterms but ximtool fails to work
on them. Every time the command is given, it fails with this error
message:
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 72 (X_PutImage)
Serial number of failed request: 3664
Current serial number in output stream: 3669
I am ready to attribute this problem to ximtool for 2 reasons:
1) the older 8bit xterms don't have this problem
2) I get the exact same problems with the X emulator on my Powermac
depending on what mode I start the program in (8bit mode works
as expected, 16bit mode fails)
The man page for ximtool seems to subtely assume an 8bit system, but I
couldn't find an option to tell ximtool that it was running on a 16bit
system (although I wouldn't expect ximtool to need such an option...)
Can anyone confirm ximtool running on a non-8bit system, or point me to
a way to change my system to support ximtools?
--
-=[doug]=-
dougw@hmc.edu
Mike Fitzpatrick wrote on May 17, 1999
> We recently purchased some 16bit color xterms but ximtool fails to work > on them. Every time the command is given, it fails with this error > message: > > X Error of failed request: BadMatch (invalid parameter attributes) > Major opcode of failed request: 72 (X_PutImage) > Serial number of failed request: 3664 > Current serial number in output stream: 3669 Unfortunately, XImtool and SAOimage currently only work with 8-bit PseudoColor visuals. SAOtng, which is based on Ximtool but with a different GUI and features (available from sao-ftp.hardvard.edu in /pub/rd) has a feature that allows it to run on 16 or 24-bit servers where there is also an 8-bit visual available simultaneously (e.g. the default is a 16-bit TrueColor but 8-bit PseudoColor is also avail- able, use the 'xdpyinfo' command to see if you're server supports this). Not all servers (notably XFree86 on PCs and new Solaris 7 servers depending on the hardware) support this feature so the only option then is to restart the server in 8-bit mode. This applies both to your xterms as well as the X emulators. We are accutely aware this is becoming more of a problem for users and plan to fix it, but it's a non-trivial problem because of the need to dynamically change the brightness/contrast of the image in real time. I hope this helps. Cheers, Mike Fitzpatrick
Doug Mink wrote on May 18, 1999
Doug Williams wrote: > Can anyone confirm ximtool running on a non-8bit system, or > point me to a way to change my system to support ximtools? Because this issue has come up so often, I put one detailed solution on the SAOimage web site at: http://tdc-www.harvard.edu/software/saoimage/saoimage.16bit.html As Mike Fitzpatrick noted, the ability to manipulate contrast and brightness with an interactive response time by changing the color map is a very basic part of the SAOimage and ximtool display programs. Pseudovisual support, which would allow the display program to have a local manipulable color map, is not present on free versions of X for Linux systems where most problems with the 8-bit limitation tend to occur. Thus, adding code to SAOimage and Ximtool to use pseudovisuals has not been a high priority. Future versions of SAOimage are more likely to support pseudovisuals than to support 24-bit image display. -Doug Mink, who currently maintains SAOimage
Tim Pickering wrote on May 24, 1999
fortunately, in linux it's possible to run multiple X servers so that you can have an 8-bit server for IRAF and a 16/24/32-bit one for everything else. in dougw's case where the xterminals are 16-bpp only, he's hosed. i highly doubt we'll ever see PseudoColor visuals become available in XFree86 in >8-bit colordepths simply because there's no real need. ximtool and saoimage are the only apps i know of currently that require them and noone outside of astronomy has ever heard of them. apparently, solaris 7 is likewise not providing PseudoColor in their 24-bit X servers. aips and karma both have image viewers that allow real-time changing of brightness/contrast in 16/24/32-bit displays so it _is_ possible to do it. they're certainly slower at high color depth than in 8 bpp, but with a 300 MHz AMD K6-2 and an AGP video card the performance is adequate and certainly worth not having to deal with color flashing at all. tim -- +----------------------------------------------------------------------+ | Tim Pickering | Kapteyn Institute, Postbus 800 | | tim@astro.rug.nl | 9700 AV Groningen, The Netherlands | | http://www.astro.rug.nl/~tim/ | +31-50-363-6519 | +----------------------------------------------------------------------+ There is no sin but ignorance. -- Christopher Marlowe
Jim Cadien wrote on May 24, 1999
Tim, Saw your IRAF/XImtool msg in adass.iraf.apps. Are the viewers you mention in aips and karma stand-alone, able to be used from iraf? Thanks, Jim Cadien
Martin Bly wrote on May 25, 1999
In article <slrn7kj7js.2sj.tim@grimbergen.astro.rug.nl>, tim@grimbergen.astro.rug.nl (Tim Pickering) writes:
>fortunately, in linux it's possible to run multiple X servers so that
>you can have an 8-bit server for IRAF and a 16/24/32-bit one for
>everything else. in dougw's case where the xterminals are 16-bpp
>only, he's hosed. i highly doubt we'll ever see PseudoColor visuals
>become available in XFree86 in >8-bit colordepths simply because
>there's no real need. ximtool and saoimage are the only apps i know
>of currently that require them and noone outside of astronomy has ever
>heard of them. apparently, solaris 7 is likewise not providing
>PseudoColor in their 24-bit X servers.
Ahem. I'm sitting in front of a Solaris 7 machine running in 24bit X
server mode. It quite happly supports 8 bit pseudocolor as well as
two dozen other visual models.
That said, saoimage won't start because the default colour model isn't
pseudocolor. Applications that do allow you to chose the colour model
will work and I have quite happily run test programs displaying to windows
where the colour model is different than the default. Starlink software
will be able to do this soon.
The Solaris 7 X server is quite spectacular on a elite 3d equiped box.
Martin.
> aips and karma both have image
>viewers that allow real-time changing of brightness/contrast in
>16/24/32-bit displays so it _is_ possible to do it. they're certainly
>slower at high color depth than in 8 bpp, but with a 300 MHz AMD K6-2
>and an AGP video card the performance is adequate and certainly worth
>not having to deal with color flashing at all.
>
>tim
>
>--
>+----------------------------------------------------------------------+
>| Tim Pickering | Kapteyn Institute, Postbus 800 |
>| tim@astro.rug.nl | 9700 AV Groningen, The Netherlands |
>| http://www.astro.rug.nl/~tim/ | +31-50-363-6519 |
>+----------------------------------------------------------------------+
>There is no sin but ignorance.
> -- Christopher Marlowe
>
--
--
--------------------------------------------------------------------------
Martin Bly, Rutherford Appleton Laboratory, UK. Tel: +44|0 1235 445363
Internet: bly@star.rl.ac.uk URL: http://www.starlink.rl.ac.uk/
Mike Fitzpatrick wrote on May 25, 1999
> In article <slrn7kj7js.2sj.tim@grimbergen.astro.rug.nl>, tim@grimbergen.astro.rug.nl (Tim Pickering) writes: > >fortunately, in linux it's possible to run multiple X servers so that > >you can have an 8-bit server for IRAF and a 16/24/32-bit one for > >everything else. in dougw's case where the xterminals are 16-bpp > >only, he's hosed. i highly doubt we'll ever see PseudoColor visuals > >become available in XFree86 in >8-bit colordepths simply because > >there's no real need. ximtool and saoimage are the only apps i know > >of currently that require them and noone outside of astronomy has ever > >heard of them. apparently, solaris 7 is likewise not providing > >PseudoColor in their 24-bit X servers. > > Ahem. I'm sitting in front of a Solaris 7 machine running in 24bit X > server mode. It quite happly supports 8 bit pseudocolor as well as > two dozen other visual models. > > That said, saoimage won't start because the default colour model isn't > pseudocolor. Applications that do allow you to chose the colour model > will work and I have quite happily run test programs displaying to windows > where the colour model is different than the default. Starlink software > will be able to do this soon. You just got lucky with your hardware in that case. The problem is that on PC systems using XFree86 you have *only* an 8-bit or higher mode, not a default 24-bit TrueColor as well as 8-bit PseudoColor available simultaneously. SAOtng quite cleverly takes advantage of this and will start itself in an 8-bit pseudocolor if it's available, but this solution won't work across all platforms (notably XFree86). Simultaneous visuals are promised for XFree86 V4.0 and are alleged to be supported in AcceleratedX servers (if you want to pay $200 for it) but I can't confirm that. The Solaris 7 server has also apparently been dumbed down depending on the hardware as Tim mentions. For example, if you ordered a Sparc Ultra 5 today it comes with a PGX graphics card that must be put into either 8 or 24-bit mode using a root-issued command (e.g. "/usr/sbin/m64config -depth 8") and there are no longer simultaneous visuals available as before (which is not what you would infer from the spec sheet on the Sun web page!). OTOH, my year old Ultra 10 running Solaris 2.5.1 supports 24-bits and multiple depths so I can take advantage of starting Netscape in TrueColor mode to avoid colormap flashing, with Solaris 7 it appears that whether or not you can do this depends on the type of graphics card. I expect any solution to the 24-bit server problem for XImtool and friends must involve support directly for TrueColor visuals so it's portable across all platforms. This leads us straight to the question of how to do the contrast scaling fast enough, and the reason we haven't just thrown in this bit of support as a quick patch. -Mike
Last post on May 25, 1999