[comp.sys.amiga.advocacy] Color palette correction

jalkio@cc.helsinki.fi (04/19/91)

Well, I (maybe incorrectly) stated a while ago that the NeXTstation
Color might have a color palette of 16 milloin colors. The reason for
this was a posting in comp.sys.next which explained that while the
machine has only 16 bits for every pixel on screen, it _internally_ has
8 bits for every base color (R, G, B). I understood that it in a way has
a palette of 16M but you can't directly access them. The system
automatically chooses the best shades for each situation from this palette.

Go figure. 

Perhaps saying that the Color station has a palette of 16M is a bit too
much and saying that it only has a palette of 4096 is a bit too
low... The thruth lies somewhere in between.

:-)

			Jouni

rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) (04/19/91)

In article <1991Apr19.003352.6042@cc.helsinki.fi> jalkio@cc.helsinki.fi writes:
>Well, I (maybe incorrectly) stated a while ago that the NeXTstation
>Color might have a color palette of 16 milloin colors. The reason for
>this was a posting in comp.sys.next which explained that while the
>machine has only 16 bits for every pixel on screen, it _internally_ has
>8 bits for every base color (R, G, B). I understood that it in a way has
>a palette of 16M but you can't directly access them. The system
>automatically chooses the best shades for each situation from this palette.
>
>Go figure. 
>
>Perhaps saying that the Color station has a palette of 16M is a bit too
>much and saying that it only has a palette of 4096 is a bit too
>low... The thruth lies somewhere in between.
>
>:-)
>
>			Jouni

  I don't agree with this. Most Amiga graphic programs store images
internally as 24bits and most load/save IFF24 bit images, however
the standard Amiga can only quantize these images to 4096 colors.
The NeXT hardware palette is 12(16?)bits, period. It doesn't matter if the
OS stores pictures internally as 100 bits, the hardware is only
capable of 4096 different colors.

  You can't simply average the software and hardware together and
say 'it's somewhere inbetween.' The hardware determines what
kind of palette the machine has.




--
+-----------------------------------------------------------------------------+
| rjc@gnu.ai.mit.edu   |   //  The opinions expressed here do not in any way  |
| uunet!tnc!m0023      | \X/   reflect the views of my self.                  |
+-----------------------------------------------------------------------------+

dwboyce@acsu.buffalo.edu (Doug Boyce) (04/19/91)

In article <1991Apr19.014549.15293@mintaka.lcs.mit.edu> rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) writes:
:In article <1991Apr19.003352.6042@cc.helsinki.fi> jalkio@cc.helsinki.fi writes:
::Well, I (maybe incorrectly) stated a while ago that the NeXTstation
::Color might have a color palette of 16 milloin colors. The reason for
::this was a posting in comp.sys.next which explained that while the
::machine has only 16 bits for every pixel on screen, it _internally_ has
::8 bits for every base color (R, G, B). I understood that it in a way has
::a palette of 16M but you can't directly access them. The system
::automatically chooses the best shades for each situation from this palette.
::
::Go figure. 
::
::Perhaps saying that the Color station has a palette of 16M is a bit too
::much and saying that it only has a palette of 4096 is a bit too
::low... The thruth lies somewhere in between.
::			Jouni
:
:  I don't agree with this. Most Amiga graphic programs store images
:internally as 24bits and most load/save IFF24 bit images, however
:the standard Amiga can only quantize these images to 4096 colors.
:The NeXT hardware palette is 12(16?)bits, period. It doesn't matter if the
:OS stores pictures internally as 100 bits, the hardware is only
:capable of 4096 different colors.
:
:  You can't simply average the software and hardware together and
:say 'it's somewhere inbetween.' The hardware determines what
:kind of palette the machine has.

[Color debate recently in comp.sys.next]

From: mfriedel@slate.mines.colorado.edu (Fried Mike Microwave)
Subject: Color Station questions
Keywords: Memory,X,display

I have recently seen a lot of questions about the NeXTstation color. 
Here are a few answers I can supply.

1) Speed of Display
	The display is faster than a '30 cube. Depending on the number of open 
windows and their respective bit-levels. (Yes it makes a difference). As most 
applications come up in gray-scale (2bit) by default the display is almost as 
fast as monochrome 0'40. Yes it is possible to make the display dog-slow, but 
only if the the windowsizes exceed the available RAM (and the swapper gets more
than its fair share), and that takes BIG windows and a lot of them. But this is
true for all color displays. So as usual more memory helps. 
(20 is a reasonable value).
	
2) Number of available colors
	4096 colors can be displayed at once on the screen out of a set of 
16million. John Graves from NeXT wrote to me:
	
:Each pixel on NeXTstation Color is represented by 16 bits in DRAM, four bits 
:each for red, green, and blue, plus four bits of "alpha" for transparency. 
:In VRAM (video ram), each pixel is represented by12 bits, four each for red, 
:green, and blue.  Overlaping images are "composited" by the PostScript window 
:manager, taking account of their transparency, before they are put into VRAM.
:Try dragging around an icon for a WriteNow document or use Molecule.App (if
:you have an extended system) to see the effects of transparency.
:The RAMDAC receives four bits from the VRAMs for each color (red, green, and 
:blue).  These four bits address a color palette RAM inside the RAMDAC, 
:selecting an eight bit DAC value.  The color palette is set by the window 
:manager (PostScript) based on the brightness control and a gamma correction 
:function to get the best set of sixteen intensities from the available 256 for
:each channel of red, green, and blue. The gamma function is used to compensate
:for the non-linearity of the phosphors in the monitor.  The color palette is 
:not accessible to the user, to prevent one application from messing us the 
:color palette for all applications.

	
3) X in color.
	Yes it is available. I have ported it (from Mouse-X) and people who 
want to test it are welcome to try. It has a few minor bugs left. Most 
applications run fine, only applications that can't deal with TrueColor (that 
is the only implemented visual for the moment). I am planning to implement 
other visuals, like Direct Color, but I need some more hardware specifactions 
first, and more time.
	
4) Developing color apps
	No, you don't need a color station, or a NeXtdimension to develop color
apps. Here is an excerpt from the Release Notes.

:	7	Multiple, Uniform Window Depths

:With support for multiple screens comes the need for windows to represent 
:data in varying depths.  NeXT has defined in nextdict four standard depths that>windows may logically represent:
:
:	NX_TwoBitGray	(1 spp, 2 bps, 2 bpp, planar)
:	NX_EightBitGray	(1 spp, 8 bps, 8 bpp, planar)
:	NX_TwelveBitRGB	(3 spp, 4 bps, 16 bpp, interleaved)
:	NX_TwentyFourBitRGB	(3 spp, 8 bps, 32 bpp, interleaved)
:
:
:In addition, NX_DefaultDepth is defined as the default depth limit in the 
:Window Server's current context.  Default depth limits are described below.  
:
:A window's depth is uniform throughout its bounds no matter where it lies in 
:the workspace.  This means one can open a 32-bit color window on a MegaPixel 
:display even though the full depth and color cannot be seen.  This is extremely>useful for painting and image-processing applications.  Our strategy is a 
:memory-saving, information-preserving one:  Most users or developers shouldn't >worry about window depths since they are handled automatically by the Window 
:Server and Application Kit.  However, if a developer wishes to control window 
:depths more directly, we have defined a simple API for this control.
:	
:	We introduce the concept of lazy depth promotion.  Windows start out at >minimal depth, for example, NX_TwoBitGray, and are automatically promoted to a >higher depth when necessary.  When one draws precise gray or color into a 
:window, the Window Server may promote it to a higher depth that will better 
:represent the new data.  What depth the window promotes to depends on the color>or image being rendered and the window's depth limit.
:	
:A window's depth limit is the maximum depth a window may attain.  It is set 
:implicitly during window creation to its context's default depth limit.  The 
:Window Server assigns each new context a default depth limit equal to the 
:maximum depth visible on the system.  For example, if you have a 32-bit color 
:display and a MegaPixel display, the default depth limit would be set to 
:NX_TwentyFourBitRGB.   If you only had a MegaPixel display, the default depth 
:limit would be set to NX_TwoBitGray.   The context's default depth limit can be
:changed with the setdefaultdepthlimit operator.  An individual window's depth 
:limit can be changed via the setwindowdepthlimit operator.  WARNING:  The 
:Application Kit controls the depth limits of its contexts and windows. You can
:also find out what a window's current logical depth is by calling 
:currentwindowdepth.
:
:A promotion example:  If a window is NX_TwoBitGray and it's depth limit is 
:NX_TwelveBitRGB, and you draw color, the window will automatically be promoted
:to NX_TwelveBitRGB before rendering.  Lazy promotion is also triggered by the 
:precision of alpha you render with.
: 
:
5) The monitor (17 inch that is)
	Yes, one can notice the difference between the monochrome monitor and 
the colormonitor. On the color monitor single pixel black lines on the borders 
diverge a little. Text is just as crisp as on the monochrome monitor though.
-- 
Doug Boyce    dwboyce@acsu.buffalo.edu

"Speedballs are interesting if you aren't the cannoneer doing the running."

jalkio@cc.helsinki.fi (04/21/91)

In article <1991Apr19.014549.15293@mintaka.lcs.mit.edu>, rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) writes:
> In article <1991Apr19.003352.6042@cc.helsinki.fi> jalkio@cc.helsinki.fi writes:
>>
>>Perhaps saying that the Color station has a palette of 16M is a bit too
>>much and saying that it only has a palette of 4096 is a bit too
>>low... The thruth lies somewhere in between.
>>
>>:-)
>>
>>			Jouni
> 
>   I don't agree with this. Most Amiga graphic programs store images
> internally as 24bits and most load/save IFF24 bit images, however
> the standard Amiga can only quantize these images to 4096 colors.
> The NeXT hardware palette is 12(16?)bits, period. It doesn't matter if the
> OS stores pictures internally as 100 bits, the hardware is only
> capable of 4096 different colors.
> 

I don't think NeXT is just like this. I understood that there really
_ARE_ 16M different shades, of which the operating system automatically
chooses the best suited for each situation (determined by the "basic"
color, of course). You only can't directly access all those shades.
Thus, those 12 (or 16) physical bits just refer to a table where each
entry can contain a 24-bit color value. 

I might have understood wrong, of course.

			Jouni

rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (04/21/91)

In article <1991Apr20.211035.6064@cc.helsinki.fi> jalkio@cc.helsinki.fi writes:
>In article <1991Apr19.014549.15293@mintaka.lcs.mit.edu>, rjc@churchy.gnu.ai.mit.edu (Ray Cromwell) writes:
>> In article <1991Apr19.003352.6042@cc.helsinki.fi> jalkio@cc.helsinki.fi writes:
>>>
>>>Perhaps saying that the Color station has a palette of 16M is a bit too
>>>much and saying that it only has a palette of 4096 is a bit too
>>>low... The thruth lies somewhere in between.
>>>
>>>:-)
>>>
>>>			Jouni
>> 
>>   I don't agree with this. Most Amiga graphic programs store images
>> internally as 24bits and most load/save IFF24 bit images, however
>> the standard Amiga can only quantize these images to 4096 colors.
>> The NeXT hardware palette is 12(16?)bits, period. It doesn't matter if the
>> OS stores pictures internally as 100 bits, the hardware is only
>> capable of 4096 different colors.
>> 
>
>I don't think NeXT is just like this. I understood that there really
>_ARE_ 16M different shades, of which the operating system automatically
>chooses the best suited for each situation (determined by the "basic"
>color, of course). You only can't directly access all those shades.
>Thus, those 12 (or 16) physical bits just refer to a table where each
>entry can contain a 24-bit color value. 
>
>I might have understood wrong, of course.
>
>			Jouni

  Ahh, so the NeXT has a 12bit display. My definition of 'bit display'
is the number of bits per pixel. For instance, most people
incorrectly called some Mac and VGA display cards '24bit'. Actually
these cards are 8bit (can only display 256 colors simulataneously) while
their palletes are 24bit (16M colors).

 For instance, the Amiga HAM mode is only 6 bits per pixel, so it's
a 6bit display. HAM mode groups pixels together (allowing a previous
pixel to be combined with the current color modification). This gives
you an effective 12bits, but you can only partially change a pixel, or
look up a new one.  DCTV allows you to have 6 or 8 bit pixels
grouped together into an NTSC encoding which allows brightness resolution
to change, but chroma(color) will be less accurate (color bleeding).
HAM-E gives the Amiga an 8bit display mode(256 colors at once, something
that should have been done in the custom chips a long time ago). HAM-E
also uses HAM's trick of pixel combining modifications. This time, instead
of 4bit modification you get 6 bit modification which gives you a pseudo-18bit
display.

  My own definition of a 24bit display is this:

 Atleast 24bits of data displayed for each pixel. This means there is
no color lookup table. The display is 'palette mapped'. Each pixel
specifies it's color directly. This means a 640x480 24bit frame
is 921,600 bytes large.

 HAM and DYUV (DCTV and CD-I) are good methods for animation since
they don't require huge amounts of data, and the eye is relatively
poor at perceiving high resolution in fast moving images.




--
/ INET:rjc@gnu.ai.mit.edu     *   // The opinions expressed here do not      \
| INET:r_cromwe@upr2.clu.net  | \X/  in any way reflect the views of my self.|
\ UUCP:uunet!tnc!m0023        *                                              /

xgr39@isuvax.iastate.edu (Marc Barrett) (04/21/91)

In article <1991Apr20.224627.26851@mintaka.lcs.mit.edu>, rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes:
>  Ahh, so the NeXT has a 12bit display. My definition of 'bit display'
>is the number of bits per pixel. For instance, most people
>incorrectly called some Mac and VGA display cards '24bit'. Actually
>these cards are 8bit (can only display 256 colors simulataneously) while
>their palletes are 24bit (16M colors).

   This shows your incredible ignorance about Apple display cards.  
Apple currently produces three video cards for the MAC II line.  Of
these, only one is 8-bit.  The other two -- the 8/24 and 8/24GC --
are true 24-bit video cards in every sense of the word.  BTW, that
one video card that isn't 24-bit can be made into a true 24-bit
video card by merely adding memory to it.

>--
>/ INET:rjc@gnu.ai.mit.edu     *   // The opinions expressed here do not      \
>| INET:r_cromwe@upr2.clu.net  | \X/  in any way reflect the views of my self.|
>\ UUCP:uunet!tnc!m0023        *                                              /

  ----------------------------------------------------------
 / Marc Barrett  -MB- | BITNET:   XGR39@ISUVAX.BITNET      /   
/  ISU COM S Student  | Internet: XGR39@CCVAX.IASTATE.EDU /      
----------------------------------------------------------    

rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (04/22/91)

In article <1991Apr21.084554.14077@news.iastate.edu> xgr39@isuvax.iastate.edu writes:
>In article <1991Apr20.224627.26851@mintaka.lcs.mit.edu>, rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes:
>>  Ahh, so the NeXT has a 12bit display. My definition of 'bit display'
>>is the number of bits per pixel. For instance, most people
>>incorrectly called some Mac and VGA display cards '24bit'. Actually
>>these cards are 8bit (can only display 256 colors simulataneously) while
>>their palletes are 24bit (16M colors).
>
>   This shows your incredible ignorance about Apple display cards.  
>Apple currently produces three video cards for the MAC II line.  Of
>these, only one is 8-bit.  The other two -- the 8/24 and 8/24GC --
>are true 24-bit video cards in every sense of the word.  BTW, that
>one video card that isn't 24-bit can be made into a true 24-bit
>video card by merely adding memory to it.

  Well excuse me Mr. Mac, but I was talking about the standard 8bit
color card Apple puts in Color Macs. A lot of people refer to these
as 24bit because they have a 16M color palette. Now for the gotcha,
go read comp.sys.mac.system and watch people talk about how slow
their Macs become in 24bit mode.

>  ----------------------------------------------------------
> / Marc Barrett  -MB- | BITNET:   XGR39@ISUVAX.BITNET      /   
>/  ISU COM S Student  | Internet: XGR39@CCVAX.IASTATE.EDU /      
>----------------------------------------------------------    


--
/ INET:rjc@gnu.ai.mit.edu     *   // The opinions expressed here do not      \
| INET:r_cromwe@upr2.clu.net  | \X/  in any way reflect the views of my self.|
\ UUCP:uunet!tnc!m0023        *                                              /

torrie@cs.stanford.edu (Evan Torrie) (04/22/91)

rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes:

>  Well excuse me Mr. Mac, but I was talking about the standard 8bit
>color card Apple puts in Color Macs. 

  The on-board graphics on the IIsi and IIci is an 8 bit implementation.
The LC is 16 bit.  These graphics modes are built into the motherboard, and
don't use a card at all.  The cards which Apple does sell, as Marc mentioned,
are all either 24 bit already, or can be upgraded to 24 bit from 8 bit by
just adding VRAMs.

>A lot of people refer to these
>as 24bit because they have a 16M color palette. 

  Actually I've never heard anyone refer to the 8 bit graphics as 24 bit
graphics.  People mention a 16 million colour PALETTE, but they always say
8 bit graphics [i.e. only 256 of those 16 million on screen at one time].
At least, this is my experience from reading MacWorld, MacUser etc...



-- 
------------------------------------------------------------------------------
Evan Torrie.  Stanford University, Class of 199?       torrie@cs.stanford.edu   
"She's got a tongue like an electric eel, and she likes the taste of a 
 man's tonsils!"  - Rik Flashheart

awessels@ccwf.cc.utexas.edu (Allen Wessels) (04/22/91)

In article <1991Apr21.181052.12234@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes:

>  Well excuse me Mr. Mac, but I was talking about the standard 8bit
>color card Apple puts in Color Macs. A lot of people refer to these
>as 24bit because they have a 16M color palette. Now for the gotcha,
>go read comp.sys.mac.system and watch people talk about how slow
>their Macs become in 24bit mode.

Only idiots and sleazy marketers refer to those cards as 24 bit.  I haven't
seen an ad labeling those cards as 24 bit in years, and I don't know anyone
with a color monitor who calls their 8 bit card a 24 bit color setup.  You'd
have to be a real dope to do that, because when you change the bit depth in
the control panel, it SAYS explicitly the number of colors being displayed.
(Well OK, in 24 bit mode it just says millions rather than 16.7 million.)

Yeah, 24 bit unaccelerated is kind of slow.  On the other hand, it takes about
a half-second to switch bit depths, so it isn't that much of a problem, and if
you are doing 24 bit graphics, you probably need an accelerator anyway.

greg@ccwf.cc.utexas.edu (Greg Harp) (04/22/91)

In article <1991Apr20.211035.6064@cc.helsinki.fi> jalkio@cc.helsinki.fi writes:
>
>I don't think NeXT is just like this. I understood that there really
>_ARE_ 16M different shades, of which the operating system automatically
>chooses the best suited for each situation (determined by the "basic"
>color, of course). You only can't directly access all those shades.
>Thus, those 12 (or 16) physical bits just refer to a table where each
>entry can contain a 24-bit color value. 

Well, I really doubt any "choosing" per se goes on.  At work when we do
something where we use less bits than provided we call it "throwing away
the bits we didn't really need anyway." ;-)

[BTW: To those interested we were adding hand scanner input to our
signature recognition software and we had a 256-grey scanner... :-) ]

Really, I'd be willing to bet that they just don't use the 12 least
significant bits of color.  It's possible some rounding might go on,
though. 

I'd have to check into it, but I'll bet there are only 4-bit video D/As in
the NeXTStation Color, like the Amiga.

Greg
-- 
       Greg Harp       |"How I wish, how I wish you were here.  We're just two
                       |lost souls swimming in a fishbowl, year after year,
greg@ccwf.cc.utexas.edu|running over the same ground.  What have we found?
  s609@cs.utexas.edu   |The same old fears.  Wish you were here." - Pink Floyd

mark@calvin..westford.ccur.com (Mark Thompson) (04/25/91)

In article <1991Apr22.064955.10173@neon.Stanford.EDU> torrie@cs.stanford.edu (Evan Torrie) writes:
>rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes:
>>A lot of people refer to these
>>as 24bit because they have a 16M color palette. 
>
>  Actually I've never heard anyone refer to the 8 bit graphics as 24 bit
>graphics.  People mention a 16 million colour PALETTE, but they always say
>8 bit graphics [i.e. only 256 of those 16 million on screen at one time].
>At least, this is my experience from reading MacWorld, MacUser etc...

Nor in my experience as a graphics hardware designer. 8bit is 8bit no matter
what fancy pallete tricks are played.
%~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~%
%      `       '        Mark Thompson                 CONCURRENT COMPUTER  %
% --==* RADIANT *==--   mark@westford.ccur.com        Principal Graphics   %
%      ' Image `        ...!uunet!masscomp!mark       Hardware Architect   %
%     Productions       (508)392-2480 (603)424-1829   & General Nuisance   %
%                                                                          %
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

rjc@geech.gnu.ai.mit.edu (Ray Cromwell) (04/27/91)

In article <61931@masscomp.westford.ccur.com> mark@calvin.westford.ccur.com (Mark Thompson) writes:
>In article <1991Apr22.064955.10173@neon.Stanford.EDU> torrie@cs.stanford.edu (Evan Torrie) writes:
>>rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes:
>>>A lot of people refer to these
>>>as 24bit because they have a 16M color palette. 
>>
>>  Actually I've never heard anyone refer to the 8 bit graphics as 24 bit
>>graphics.  People mention a 16 million colour PALETTE, but they always say
>>8 bit graphics [i.e. only 256 of those 16 million on screen at one time].
>>At least, this is my experience from reading MacWorld, MacUser etc...
>
>Nor in my experience as a graphics hardware designer. 8bit is 8bit no matter
>what fancy pallete tricks are played.

  
   I wasn't talking about professionals, I'm talking about computer novices.
For instance, I have seen people recently refer to DCTV as '24bit'.
From what I've seen via local bbses 24bit seems to be a buzzword people
are tossing around without knowing what it truly means. Also, saying
HAM is 12bit or HAM-E 18bits is incorrect. I would call HAM a pseudo
12bit, or '12bits per 3 pixels' since it takes three pixels to peform
a complete color change in the worst case.


>%~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~%
>%      `       '        Mark Thompson                 CONCURRENT COMPUTER  %
>% --==* RADIANT *==--   mark@westford.ccur.com        Principal Graphics   %
>%      ' Image `        ...!uunet!masscomp!mark       Hardware Architect   %
>%     Productions       (508)392-2480 (603)424-1829   & General Nuisance   %
>%                                                                          %
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


--
/ INET:rjc@gnu.ai.mit.edu     *   // The opinions expressed here do not      \
| INET:r_cromwe@upr2.clu.net  | \X/  in any way reflect the views of my self.|
\ UUCP:uunet!tnc!m0023        *                                              /