comp.lang.ada
 help / color / mirror / Atom feed
From: "Robert I. Eachus" <rieachus@comcast.net>
Subject: Re: Color components and fixed point numbers
Date: Tue, 02 Mar 2004 11:39:41 -0500
Date: 2004-03-02T11:39:41-05:00	[thread overview]
Message-ID: <mvmdnUWeza9TJdndRVn-sw@comcast.com> (raw)
In-Reply-To: <fc19748c.0403020258.603103da@posting.google.com>

Pat wrote:

> I'm very new to Ada, so what is rep clause?

Ada shorthand for representation clause, see RM 13.1 through 13.6, and 
elsewhere throughout the reference manual.  Different rep clauses handle 
different aspects of a type's representation.  In the case of 
fixed-point types, 'Small and 'Delta can both be set by rep clauses (see 
  RM 3.5.10 http://www.adaic.org/standards/95lrm/html/RM-3-5-10.html for 
the attributes of a fixed-point type.  The key here is 'Small which can 
be set by a rep clauses. (Technically by an attribute definition clause, 
but you can see why everyone uses the shorthand.)

Why it matters is that, by default, the compiler will choose a power of 
two (or ten for decimal fixed-point types) as the 'Small of a type. 
With a rep clause you can require that the small for the type be exactly 
the delta for the type. Compilers can reject rep clauses that they don't 
support.  But for 'Small compilers have gotten pretty good over the 
years.  I have used Pi/10_000, and 1.0/1_296_000 for angle measures. 
(Tenth of a milliradian, and arc seconds respectively.)  The Ada 95 
rules made it much easier than in Ada 83 for a compiler to support such 
a rep clause.

> Yes, this is the reason why I used 255 and 65535 as denominator. I am
> not a expert on color conversion or representation, but I think 0.0
> should represent the darkest and 1.0 the brigthest color independent
> from the representation as integers. So 255 and 65535 should be the
> same brightness.

Maybe they should, and if they did, you could write the rep clauses to 
force such a representation.  But as I say, in all current computer 
hardware that I am aware of, FFFFFF is equal to FF00FF00FF00 not 
FFFFFFFFFFFF.  Don't let that worry you though, if you look at the 
'real' specifications for displays (or the NTSC or PAL broadcast rules) 
you will find that the actual representable color range for most 
monitors is much less than that.

For example, if a monitor is specified as having a 500:1 constrast 
ratio--which is pretty good--that means that the darkest black is 
1/500th of the brightest white.  That means that all 24-bit colors can 
be distinguished (at least with measuring equipment), but usually you 
will run into saturation above FF80FF80FF80, and blacks below 
008000800080 will not be distinguishable.  (Actually you have to have a 
very good eye to be able to see a brightness difference of less than 5%. 
  You might think that would make 24-bit color no different from 16-bit 
color (actually 15-bit color), but there are low-light levels where the 
differences are noticable to a trained eye.

I have an Amiga that can generate an NTSC (broadcast) display signal. 
But if you do that you have to be aware that the brightest NTSC color is 
technically C0C0C0, and blacks below around 191919 should also not be 
used.  The computer will generate those colors in NTSC mode, but 
technically it violates the broadcast standard.  (And the NTSC signal 
will violate broadcast standards.) Most NTSC monitors will start having 
some trouble with color saturations above D0 or so. Computer monitors, 
though will support all the way up to FF without blooming or tearing, 
even if they saturate well before then.  Of course they do this by 
clipping the analog signals.

-- 
                                           Robert I. Eachus

"The only thing necessary for the triumph of evil is for good men to do 
nothing." --Edmund Burke




  reply	other threads:[~2004-03-02 16:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-01 11:49 Color components and fixed point numbers Pat
2004-03-01 16:24 ` Robert I. Eachus
2004-03-02 10:58   ` Pat
2004-03-02 16:39     ` Robert I. Eachus [this message]
2004-03-02 22:23     ` tmoran
2004-03-04 13:31       ` Pat
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox