ruby-****@sourc*****
ruby-****@sourc*****
2013年 4月 23日 (火) 05:31:50 JST
-------------------------
REMOTE_ADDR = 70.49.50.179
REMOTE_HOST =
URL = http://ruby-gnome2.sourceforge.jp/hiki.cgi?tut-gtk2-appdx-clrtheory
-------------------------
@@ -13,7 +13,7 @@
{{br}}
== Digital Colour Theory For Computer Professionals
-(A12.1){{br}}
+(A12.3.1){{br}}
If you need to manipulate colours programmatically and have trouble understanding how colours mutate, transfer and flow from one into another, this chapter is for you. For all others, a warning is in order. Namely, what I describe here is limited only to those colours that map to the basic eight colours (black, red, green, blue, turquoise, yellow, white and brown), we humans understand as the most basic colour set.
@@ -21,11 +21,12 @@
Therefore, in this chapter we deal just with a small subset of the entire digital colour theory, however, this treatment of the subject is complete enough to satisfy most any computer professional, except perhaps those that need to design applications for use in visual arts and alike. The image here on the left is a good example to show you how you should be able to manipulate colours programmatically (it was made by a program, we develop in this chapter.)
+
Throughout our existence we learned that all existing colours in nature can be created from three (red, green, and blue) basic natural (or better, elementary) colours. This sets the ground to define eight (actually eleven) basic colours (000=black, 001=blue, 010=green, 100=red, 011=turquoise,101=magenta, 110=yellow and 111=white) /note, orange, brown and grey colours are missing because there are only seven combinations in this 'binary' code with three bits only/. However, depending on the amount/intensity of any of the three (rgb) colours, we can create different shades of these basic colours, some of which, we humans, named as different colours. For instance by changing the intensity of the two components that naturally give us either orange or yellow, we can make a colour we named "brown". Note, that we are not even mentioning colour names with exotic prefixes, postfixes and odd colour compositions such as light-olive-green, yellowish-brown, bluish-magenta, etc.
Rather than totally reinventing the colour naming schemes, let's concentrate on the elementary colours a child can name in any language. First, we can identify three categories of colours which we should be then able to map into digital colour language, maps and charts.
-{{br}}
+
:The three categories of colours:
* a) The three elementary colours (red, green, and blue).
@@ -39,7 +40,7 @@
Actually, for all practical purposes, to define all basic, a.k.a.((*defining,*))colour shades, we would only need each byte to represent four different colour defining values (full (f), half (h), quarter (q), and empty (e)), which are then used to define ((*the defining rgb colours.*)) Because each rgb component in cybernetics contains 256 possible values computer graphics scientists reserved three values out of this range to represent full=255 (hex:FF), half=128 (hex:80), quarter=64 (hex:40) and empty=0 (hex:00). With this schema we could then represent all eleven natural colours that map to digital defining colours exactly. For example we could then write "000=black, 001=blue, 010=green, 011=turquoise, 100=red, 110=yellow, 101=magenta, 111=white, 8) orange, 9) brown, 10) grey" as:
-
:Eleven basic colours
Table
1) e,e,e = black, 5) f,f,e = yellow, 9) h,q,e = brown,
@@ -49,34 +49,32 @@
-{{br}}
+
=== The Defining RGB Colours.
+(A12.3.1.1){{br}}
-
-
The three colour values FF (255), 80 (128) and (0), we just learned computer graphic engineers reserved for "full, half and empty" markers, are used to define all easy recognizable colours, a.k.a. defining colours.
-:Complementary
+
Note that reserving these three values from the total of 256 values a byte can hold, still lives us 252 unused values to define all the different colour shades. The first 126 values can therefor be used to quantify the strength/quantity or intensity for colours represented with the "full (hex:FF)" designation, that is, those colours we metaphorically identified as "full brush" and which are digitally defined in the range from 254 (xFE) to 127 (x7A), and 126 values to quantify the strength for the colours defined in the range from 128 (x80) to 1 (x01), that is the colours defined below the value 128 (x80). (Indeed, the reserved value for empty need not be quantified, since it means no colour /zero means no quantity/).
:The Three Categories Of Defining Colours.
-
* DEFINING COLOURS (defined as FF(s).
* DEFINING COLOURS WITH SHADES (defined as FF & 80 in any order.)
* DEFINING COLOURS COMPOSED ONLY OF SHADES (defined as halves, i.e. 80s and lower).
+ {{image_right("color-codes-s1.png")}}
+ The image on the right should give you an idea how to interpret the numbers in the above three categories.
- {{br}}
- {{image_right("color-codes-s2.png")}}
- The image on the right should give you an idea how to interpret the numbers in the above three categories.
-
Please note, that though in the title for for the last row you can see, that the pertinent defining colours should be defined only with x80 values, you may find also values above and below the "half (128/x80) marker". There is no mistake here. The keyword is the ((*"defining"*)) colours. Those are only the middle colours in the exact middle of each row, and the accompanying codes are in yellow boxes!
{{br}}
:Possible Value Combinations For All Three Groups Of Defining Colours
+# seeA: ~/work/01-pgmLearn/00allPgmDOC/00-generic-prg-eg:HEX/color-analysis.txt
+
Table
. Hexadecimal Decimal In Percents
-- -- -- --- --- --- ---- ---- ----
@@ -97,7 +95,5 @@
-- -- -- --- --- --- ---- ---- ----
| b.1) orange ff 80 00 255 128 0 1 0.5 0
| b.2) yellowish-green 80 ff 00 128 255 0 0.5 1 0
- | b.3) magentish-blue 80 00 ff 128 0 255 0.5 0 1
+ | b.3) magentaish-blue 80 00 ff 128 0 255 0.5 0 1
|
| b.4) greenish-yellow ff 80 00 128 255 0 1 0.5 0
| o o o
@@ -126,36 +124,41 @@
# byte values. If we would count all possible shades, there are over 16.7M
# (million) combinations possible.
-
-
(Since colours are listed in ascending order, do not be confused with the rows "a.1" and "a.8" in the last group. They are repeated for clarity, and also because they do belong to this last special group where all components have the same value. The smaller the value the darker grey we get, black being the darkest, and on the other side white - the brightest.)
:Note
In the above table, we consistently use FF and 80 rather than FA and 7F (even when this is incorrect - i.e. the darkest orange or brown colours should have codes "ff fa 00" and "fa 7f 00" rather than "ff ff 00" and "ff 80 00", respectively) because they are easier to distinguish for human reader (easier for eyes), and the error (overlap) is tolerable. (FF, 80 only cause the overlap at the colour brake, which for human eye is unrecognizable, anyway.)
-
:Group (c), Composed Only From Colour Shades, Deserves Extra Attention
This group is special in many respects, but the most important distinction from the other groups above is, that only one code in this group is used to define a single ((*defining colour,*)) that maps to the basic natural colours all people who are not "colour-blind" can identify, namely, the((*brown (804000)*)) colour. It gets even more confusing if you wish to define different shades of brown, particularly on the darker side of the spectrum, because the red component of brown can go all the way up to xFF.
All that was just said is also true for all other possible (digital) colours from the group (c) in above table. For instance dark-turquoise or, as some call it, dark-cyan colour (004080), which for most people is not another colour all together, is actually just a darker version of regular 'turquoise' (00ffff). This, really is not unlike brown which is actually a very dark shade of orange, which in turn is the yellow shade of red. The difference is that, ((*brown*)) for most humans is a distinct colour, just like the orange, but unlike, for instance, a "seagreen" or "stealblue" which are considered shaded "green" or "blue", perhaps even in any order!?
+
You should also notice that, while some colours for human eye are very hard to correctly identify, digitally they can be defined with absolute certainty, which may have some significance for a scientist but is rather useless for an artist or an art lover.
-
+
Also note that the groups (1), (6) and (7) are a special case that actually create a very distinct "non-colour" (black and white) group. On top of that, groups (1) "white" and (7) "black" mark the beginning and end of the digital spectrum, which for human eye translates into a characteristic called brightness, that runs from the darkest colour to the brightest one.
+
+
{{br}}
{{br}}
-=== The rules that define relationships between RGB colour components
-# -----------------------------------------------------------------
-(A12.2){{br}}
-When reading the rules about relationships between the rgb components in codes for the defining colours, make sure you have absolutely no doubts what a particular term means. So let's look at the terminology first.
+=== The rules that define relationships between the RGB colour components
+# ---------------------------------------------------------------------
+(A12.3.2){{br}}
+# THE RULES ABOUT RELATIONSHIPS BETWEEN THE RGB COLOUR COMPONENTS :
+# =======================================================
+# When either b || m are zero all three (t,b,m) are irrelevant and have to be
+# set from rules:
+
+When reading the rules about relationships between the rgb components in codes for the defining colours, make sure you have absolutely no doubts what a particular term means. So let's look at the terminology first.
+
+
:Terminology used when explaining composition of defining colour codes
# --------------------------------------------------------------------
@@ -163,7 +168,12 @@
First, we introduce the terms that will help us understand how the defining eight colours are formed, and what exactly are the components from which their colour code tuples are formed. Next, we will expose terms that will be used to manipulate the defining colour codes in order to provide us with a reasonable subset of shades these for this eight defining colour. For instance, we will need a few brighter shades and at least that many darker ones. Our goal is that these colour shades would be computer generated. For this, we will need to define upper and lower boundaries or limits at which one colour turns into another, hence, in the second part of this introduction to our colour processing terminology limits like the maximum and minimum possible colour value will be defined.
- :(1) Defining colour
+ :(1) Defining colour codes
{{br}}
The term ((*defining colour*)) is used for a code that uniquely identifies any one of the the eight basic colours (black=000000, blue=0000ff, green=00ff00, turquoise=00ffff, red=ff0000, magenta=ff00ff, yellow=ffff00, brown=808000, and white=ffffff).
@@ -173,6 +178,12 @@
{{br}}
Only after we understand that in order to include the brown colour, we need more than just zeros (0s) and ones (1s) or hexadecimal zeros (00s) and fifteens (FFs) we can fully appreciate the complexity of the term ((*defining colour,*)) which now in addition to hexadecimal zeros (00s) and fifteens (FFs), includes also values below hexadecimal 80 inclusively. Namely, the true defining colour code for((*brown*)) (i.e. not light brown or dark brown - just the plain brown) is((*(80-40-00).*)) So keep all this in mind when reading the rules about relationships between the rgb components in codes for the defining colours.
+
:(2) Colour Tuple Component Columns
{{br}}
Any complete colour code, a.k.a. color tuple, is composed of three component elements or columns, each of which holds a value in the range 0-255. However, since there are only eight 'defining colours', we need only three or at the most four (see the code for brown colour) of these values to form these eight colours, the remaining values from the byte range (0-255) can then be used to represent all other 16.7M (million) colour combinations or shades. Hence, out of the 256 values that a byte can hold computer scientists reserved three (actually, four) special values from which we build defining colour tuples (codes). Because we are going to talk about all other colours in terms of the defining colours and their component elements it would be convenient to name these special values, used to compose the eight defining colours.
@@ -199,7 +205,12 @@
white ......... full full full ff ff ff
-
:(3) A defining (FF|1) component or column
{{br}}
A defining (FF|1) column is any column in a defining colour code tuple which contains value ((*FF*)), which in painting corresponds to a full can or a brush full of paint, hence we named these components ((*full.*)) For example this term applies to the first and the last columns in the code for defining magenta colour (ff 00 ff), or only the first column in the code for defining orange colour (ff,80,00).
@@ -220,6 +225,14 @@
+
+
+
:The Rules
The rules here that define relationships between RGB colour components are set up somewhat arbitrarily, as a result of observations of a small group of people who tried to determine when a particular colour becomes indistinguishable from another or turns into the other colour all together. Another observation under different circumstances or if a different group of people were to perform these observation experiments, the results may differ ever so slightly, but these differences should prove to be insignificant for all our the intents and purposes, which are to build algorithms and computer model that would allow programmatically alter the((*defining colours*))into a range of different shades of a selected colour, short of turning that particular colour into a different one.
@@ -234,7 +242,15 @@
- Following are the rules we talked about above in the introduction:
+Following are the rules we talked about above in the introduction:
:Note
When in the following rules we talk about colour code components ether on the left or on the right side within any colour row, we always mean left or right of the defining colour (see the ((<image above|tut-gtk2-appdx-clrtheory#The Three Categories Of Defining Colours.>))).
@@ -253,6 +261,15 @@
(a1.ff.R) The TOP for any defining (FF|1) column(s) on the right depends on the number of shades you wish to have, but must be below 98% (.98), i.e.: (hex:FA). The darker colours are realized by setting all FF components on the right side to identical modified values.
+
:A2 - MIN (minimum) for FF defining components
(a2.ff.L) The MIN for any defining (FF|1) column on the left side of the defining colour can not change, and must remain 1 (hex:FF) at all times.
@@ -302,10 +311,19 @@
.
####### ^ Do not remove the dot (.) above!!!!
-
# C) DEFINING COLOURS COMPOSED ONLY OF SHADES (defined as halves, i.e. 80s and lower).
# -----------------------------------------------------------------------------------
+
# {{br}} ### see: the dot (.) above is like NL
:C. The defining 80 and 40 colours (only brown colour)
@@ -365,13 +374,166 @@
(d3.grey) MIN values for grey colour components is .02, i.e.: 02% of full (FF) value, which is (hex:05). You must always change all three colour components.
+=== Putting the theory to work
+(A12.3.3){{br}}
+Let's start with the program, that displays a colour greed for all basic colours with an arbitrary depth (a number of desired colour shades), shown in the first image at the beginning of this appendix. This program is just an example using the colour generating methods, which really, we are interested in from the outset. Nevertheless, we factored out the colour altering methods from the example program, and created a generic reusable module, that can be used in many Gtk and cairo programming projects. The motivation behind the development of this colour management programming aid was to shield the developers from ever looking at the colour code tables, and colour schemes, allowing them to treat colours just like in all human languages, by using adjectives like, bright, brighter, darker ... and adverbs like more or less, etc. Similarly, one should not constantly think about colour transparency, a.k.a alpha channel, it should always be there as a reducible opacity. The use of
colour management methods should be self-explanatory, and the methods should implement sufficient error reporting, to eliminate a need for a programmer to constantly checking the API documentation, when an incorrect argument was used during a method invocation.
+
+# (A12.3.3.1)
+=== Complete 'display-color-shades.rb' Program Listing
+(A12.3.3.1){{br}}
+
+
+:Programmer's Note:
+ (A12.3.3.1.1){{br}}
+ To run this program example you need to upgrade the 'hiki2-gtk-w-cairo.rb' module file to at least the ((*release 1.3*)). This file contains the required HikiGtk module. HikiGtk modules can be viewed and copied from section: 10.2.1.1 [((<Time To Start Using Object-Oriented Programming Paradigm|tut-gtk2-dnd-intro#Time To Start Using Object-Oriented Programming Paradigm>))]. For all required files see section A12.3.5 (The required files) below.
+
+
+
+
+
+((*display-color-shades.rb*))
+
+
+
+# FILE: gtk+/myHk-FundGtk+Dvlp/ch12/rb_12/1203-p10-setsrcgradient/wk-rgb-mgmt/
+# 10-8000-03-display-color-shades-dpl01.rb
+
+
+
+
+ #!/usr/bin/env ruby
+ # Testing ColorBrightnessMgmt module from file 'color-brightness-mgmt.rb'
+
+ $: << '~/work/HikiLib'
+ require 'hiki2-gtk-w-cairo.rb'
+ include HikiGtk
+
+ class DrwAreaToImg < CairoWindow
+ include CairoHelper
+
+ def initialize(title=nil, n=4)
+ super(title)
+ @number_of_shades_on_one_side=n
+ @unit = 1.0
+ @step = @unit/n
+ @color_box_w = @unit * 0.65
+ @color_box_h = @unit / 3
+ @hgap = (@unit - @color_box_w) / 7
+ @vgap = 3*@hgap
+ # @cr ... instance variable is initialized only after {{ draw }} method is called.
+ end
+
+ def draw(cr, drawing_area)
+ # NOTE the peculiarity here, cairo context instance variable can be
+ # initialized, only after 'draw' method is called with the context
+ # parameter (cr).
+ @cr = cr
+ cr.scale(100, 100) # (100, 100) # Examples are in 1x1 coordinate space
+ cr.line_width = 0.01
+ # Display the color grid.
+ base_color_names.each_with_index do |color, line|
+ display_line_of_shades_for_color(color, line)
+ end
+ end
+
+ def display_line_of_shades_for_color(color, line)
+ n = @number_of_shades_on_one_side
+ cr = @cr # @cr ... is initialized only after {{ draw }} method is called.
+ w = @color_box_w
+ h = @color_box_h
+ nx = x = y = @hgap
+ ny = line * (@vgap + h) + @hgap
+
+ 0.step(2*@unit, @step).each do |v|
+ brightness = v - @unit
+ cr.save # Save original cairo context environment.
+ cr.translate(nx, ny) # Change all coordinates in cr for the following step pass.
+
+ cr.set_source_rgba(mk_cairo_acolor(color, brightness))
+ draw_closed_paths(cr, [x, y], [w, y], [w, h], [x, h], :c)
+ cr.fill
+ cr.set_source_rgba(mk_cairo_acolor(:black)) # Change font colour for defining colour code.
+ draw_closed_paths(cr, [x, y], [w, y], [w, h], [x, h], :c)
+ cr.stroke
+ if v == 0 # Write color name only into the brightest colour-xox.
+ cr.set_font_size(0.1)
+ cr.set_source_rgba(mk_cairo_acolor(:black))
+ cr.move_to(x+ ＠ hgap, y+4*@hgap)
+ cr.show_text(color.to_s)
+ end
+ # Display colour code underneath each colour box.
+ color_code = mk_rgb_color(color, brightness).upcase
+ cr.set_font_size(0.15)
+ cr.set_source_rgba(mk_cairo_acolor(brightness==0 ? :red : :black))
+ cr.move_to(@hgap, @vgap + h)
+ cr.show_text(color_code)
+ cr.restore # Restore the original cairo context envirionment, preventing
+ # accumulative effect, when setting coordinates for next
+ # color-box {{ see: cr.save & cr.translate(nx, ny) }} above.
+ nx += w + 2*@hgap
+ end # end-step-loop
+ end
+
+ # Convenience method to dynamicaly size the main Gtk window. Returns window
+ # 'width' and 'height' parameters after window object is created and after users
+ # request for number of colours is taken into account during instatiation process.
+ def get_dimensions
+ [
+ ((@number_of_shades_on_one_side * 2.0 + 1) * (@color_box_w + @vgap) - @vgap) * 100,
+ ((@color_box_h + @hgap + @vgap) * base_color_names.size - @hgap) * 100
+ ]
+ end
+ end
+
+ # Allow setting the number of colour shades from the command line.
+ num_of_shades = ARGV.size == 1 ? ARGV[0].to_f : 4
+
+ title = "Display a colour grid"
+ w=DrwAreaToImg.new(title, num_of_shades)
+ w.set_size_request(*w.get_dimensions)
+ w.show_all
+ Gtk.main
+
+
+
+
+:Hiki Colour Management Module Explained
+ (A12.3.3.2){{br}}
+
+
+
+
+
{{br}}
{{br}}
{{br}}
-:Some Convenient Values You Will Need If Working With Colours Extensively
+=== Some convenient colour code schemes and tables.
+(A12.3.4){{br}}
+You have seen colour codes can be expressed in many different notations. I find the most interesting those that can be are directly mapped to your programs.
+
+:Eleven basic colours
+
Table
+ 1) e,e,e = black, 5) f,f,e = yellow, 9) h,q,e = brown,
+ 2) f,e,e = red, 6) f,e,f = magenta, 10) h,h,h = grey,
+ 3) e,f,e = green, 7) e,f,f = turquoise, 11) f,f,f = white.
+ 4) e,e,f = blue, 8) f,h,e = orange,
+
+
+:The table of different values colour components can be expressed in
+
+ Table
Dec. Hex. Dec.Ratio Dec.Diff. Hex. Dec. Ratio
Val. Val. Val/255 255-Val Diff 255/Diff
-----------------------------------------------------
@@ -409,21 +562,201 @@
5 5 .02 250 FA 1.02 = 1/.98
255 FF 1.0 255 FF 1.0 = 1/1
- :Note
- In first row above you will see "statement" 0=255. This is true if you pretend the above table behaves like a ring in mathematics, where the first and the last values are the same.
+ :Note
+ In first row above you will see "statement" 0=255. This is true if you pretend the above table behaves like a ring in mathematics, where the first and the last values are the same.
+
+{{br}}
+{{br}}
+{{br}}
+
+
# {{image_right("")}}
# ((<|URL:http://...>))
# ((<|>))
# dialog-warning.png
+# ------- REQUIRED FILES: -----------
{{br}}
{{br}}
-This article is conveniently included for those who do not find sufficient information on pages describing cairo Gradient Sources, and followed links there to jump here.
+=== The required files
+(A12.3.5){{br}}
+
+To run the examples in this article download the following files into your program directory:
+
+:You need:
+
+ * (A12.3.5.1) 'hiki2-gtk-w-cairo.rb' .......... module file (((*release 1.3*)) or greater ); see section 12.3.0.3 ((<Hiki Gtk With Cairo Module Download File|tut-gtk2-dancr-rbcatut-intro#Hiki Gtk With Cairo Module Download File>)).
+
+ NOTE: Should you experience any problems running programs utilizing cairo library, make sure you have the latest release of 'hiki2-gtk-w-cairo.rb' module. Programs here require 'hiki2-gtk-w-cairo.rb'((*release 1.3*)) or greater.
+
+ * (A12.3.5.2) 'hiki2-cairo-helper.rb' .......... module file; see section 12.3.7 ((<Hiki Cairo Helper Module Download File|tut-gtk2-dancr-rbcatut-intro#Hiki Cairo Helper Module Download File>)).
+
+ * (A12.3.5.3) 'hiki2-color-brightness-mgmt.rb' .......... module file; see section 12.3.7 ((<Hiki Colour Management Module Download File|tut-gtk2-dancr-rbcatut-intro#Hiki Colour Management Module Download File>)). Incidentally this file is extensively covered and explained above under section A12.3.3.
+
+
+
+{{br}}
+{{br}}
+
+This article is conveniently included for those who do not find sufficient information on pages describing cairo Gradient Sources, and followed links there to jump here.
:Return point: