Interest in color library.
Upsss... I pressed "send" to fast... :) I am gathering materials and working on a library (originaly I wanted one class, but it seems now that it wont be that easy) dealing with colors, their representation (like ranges 0.0-1.0 and 0-255), models (like RGB, YUV, HSV and others). Any sugestions or needs? Adam Badura
Adam Badura wrote:
Upsss... I pressed "send" to fast... :)
I am gathering materials and working on a library (originaly I wanted one class, but it seems now that it wont be that easy) dealing with colors, their representation (like ranges 0.0-1.0 and 0-255), models (like RGB, YUV, HSV and others). Any sugestions or needs?
Adam Badura
I would be interested in such a library. One of the prime requirements I have on a color class is that the storage format fits commonly used ones like RGBA 8:8:8:8 or YUV 4:2:2, etc... This makes it possible to interact with legacy libs (X, OpenGL, OpenCV, imagemagic, ...), which often use raw image buffers, efficiently. I would also like to see easy conversions between the types (YUV a = color_cast<YUV>(RGB(0x411468)); or something simmilar) I don't know exactly how Ranges fit in. Regards Fabio
Fabio Fracassi wrote:
Adam Badura wrote:
Upsss... I pressed "send" to fast... :)
I am gathering materials and working on a library (originaly I
wanted
one class, but it seems now that it wont be that easy) dealing with colors, their representation (like ranges 0.0-1.0 and 0-255), models (like RGB, YUV, HSV and others). Any sugestions or needs?
Adam Badura
I would be interested in such a library. One of the prime requirements I have on a color class is that the storage format fits commonly used ones like RGBA 8:8:8:8 or YUV 4:2:2, etc... This makes it possible to interact with legacy libs (X, OpenGL, OpenCV, imagemagic, ...), which often use raw image buffers, efficiently.
I would also like to see easy conversions between the types (YUV a = color_cast<YUV>(RGB(0x411468)); or something simmilar) I don't know exactly how Ranges fit in.
Windows stores RGB(A) values in a DWORD with values in the range 0..255. However, Mac (and presumably others) uses a data structure equivalent to float[4]. I think this is what is meant by Ranges. It should be possible to cast to the native type: namespace c = boost::color; dc.Plot( 10, 10, color_cast< c::native_color >( c::rgba( 128, 128, 128 ))); Don't forget that RGB is a define on Windows! - Reece
like RGBA 8:8:8:8 or YUV 4:2:2, etc...
What "etc.."? I need to know such things... :) Or do you have any sugestions for a "general foramt specification"? Why do you use colors in format in which components are integers in range 0...255 and not floats in range 0.0...1.0? I want to know to better understand the task? (I know that WIndows uses such a format and that as I suppose ale the data that is received be devices is finally in this format but do you have any other reasons). Thanks. Adam Badura
Adam Badura wrote:
like RGBA 8:8:8:8 or YUV 4:2:2, etc...
What "etc.."? I need to know such things... :) Or do you have any sugestions for a "general foramt specification"?
I was just giving a few examples of common color encodings, using a rather common scheme, the names of the Channels, and the number of bytes to encode each. http://www.fourcc.org/rgb.php and http://www.fourcc.org/yuv.php give an overview of several common pixel formats.
Why do you use colors in format in which components are integers in range 0...255 and not floats in range 0.0...1.0? I want to know to better understand the task? (I know that WIndows uses such a format and that as I suppose ale the data that is received be devices is finally in this format but do you have any other reasons).
No, no other reasons. Most algorithms which work on images need to be as efficient as possible, so I only convert colors to float if I need to (i.e. repeated subsampling, etc.) Of course I also like to have the matching float colors. OpenGL can use them, at least as a drawing color, I haven't checked if it can use them as texture, too. Unless you need extra high color fidelity (e.g. HDR-Images, Photo post-production) the additional space which is required to store floats is overkill. My main concern is that the color library supports common pixel storage formats so that I can handle raw image buffers without copying them first in a typesafe way, or even more importantly to pass a data structures of consecutive color library pixels as a a raw buffer, like for example (it should demonstrate how such a library might be used, its not meant as a syntax proposal): std::vector<color_library_pixel> img; load_from_file("test.png", img, width, height); legacy_function_which_expects_someptr_to_raw_buffer(&img[0]); color_library_pixel p = img[10 * width + 5] // returns pixel at (5, 10) This makes it possible to write high level image classes, with minimal storage and an efficient interface to lower level code. regards Fabio
Thanks.
Adam Badura
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Adam Badura wrote:
like RGBA 8:8:8:8 or YUV 4:2:2, etc...
What "etc.."? I need to know such things... :) Or do you have any sugestions for a "general foramt specification"?
you need to separate out the concepts: numerical representation; integer, floating point, fixed point, signed/unsigned variations range of representation; 1/8/10/12/15/16 bit integer, 16/32/64 bit floats encoding/transfer characteristics; gamma corrected, log encoded, linear, relative/absolute values storage format; packed/unpacked, interleaved/planar, strided/unstrided dimensionality; 1D, 2D, 3D, 6D (and other printer ink counts), 31 and other spectral data What is the meaning of the composition/separation of the separate data channels As indicated above, the sampling of the multiple channels can be variable between channels, reconstructing regular spacing needs filters these need to work across similar dimensions as the data, probably have a functor syle interface. this then needs the spacial arangement to be navigatable in a multi-dimensional manner (N-D segmented iterators?) Type conversion is an interesting property, what does it mean to do add RGB(0.5, 0.5, 0.5) to YUV(0.5,0,0) Are they different to each other? Is YUV == Y'CbCr, does RGB (sRGB) == RGB (Adobe RGB). Pesonally I'd like strict typing so that if I assign Adobe RGB to sRGB I get an error, also the equality test should also fail, to me they are totally different, in particular Adobe RGB colour space is a 'larger type'. You may find it difficult to separate the colour aspects from what it is to be an image, especially in the video style representations. Colour manipulations should not be constrained to 0.0-1.0 no matter what the underlying representation. (see for instance www.openexr.org, ITU-R BT.709, etc) How do you handle conversion from one bit depth to another - you may need a policy/trait to cover rounding, bit depth extension e.g. valueIn12Bit = (valueIn8Bit * (pow(2, 12) -1)) / (pow(2, 8) -1) valueIn12Bit = (valueIn8Bit / (pow(2, 8) -1)) * (pow(2, 12) -1) valueIn12Bit = (valueIn8Bit << (12 - 8)) | (valueIn8Bit >> (12 - 8)) valueIn12Bit = (valueIn8Bit << (12 - 8)) But what about the intermediate values... should it really be valueIn12Bit = static_cast<typeFor12Bit>(double(valueIn8Bit * (pow(2, 12) -1)) / (pow(2, 8) -1)) or valueIn12Bit = static_cast<typeFor12Bit>((double(valueIn8Bit * (pow(2, 12) -1)) / (pow(2, 8) -1)) + 0.5) Quite common assumptions are to convert everything to float and work like that until going to an external interface. All of this is not trivial and this is before you consider ICC or similar. I suggest trying to constrain yourself to one or two uses first and see what can be generalised/simplified, otherwise it may take some time... Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |
For now I think taht template representation would be best. What i mean is for example struct rgb_8888 { unsigned char r : 8; unsigned char g : 8; unsigned char b : 8; unsigned char : 8; }; struct yuv_422 { unsigned char y : 4; unsigned char u : 2; unsigned char v : 2; }; template<typename Components> class color { private: Components mComponents; }; A few typical "structs" will be defined and if user has a special need (perhabs becouse his program has a special memory representation) than he defines his own struct. Structs would also provide a standarized functions to manipulate on components without knwoing their real representation (perheps get_component(i) set_component(i) - ore something like this). I am also considerating to give something like color_traits, but it is a project now and i don't know if this would be realy needed. color class would give functions for manipulating on color, but no additional data members. I am now working on this but i think it can be good aspecialy because of templates which allows inlining simple functions and produce fas code, what is neede in such class to be realy used in graphic manipulation. Also using templates, as I hope, produces high extensibility (user may add his own format). Adam Badura
Adam Badura wrote:
struct yuv_422 { unsigned char y : 4; unsigned char u : 2; unsigned char v : 2; };
hmm this is not at all what I would call 422, so be wary of using that term in conjunction with YUV, nor 8888. Normally this means that the u and v planes are sampled at a reduced rate see http://en.wikipedia.org/wiki/YUV_4:2:2 for example Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |
"Kevin Wheatley" <hxpro@cinesite.co.uk> wrote in message news:432FD45A.33E8E799@cinesite.co.uk...
Adam Badura wrote:
struct yuv_422 { unsigned char y : 4; unsigned char u : 2; unsigned char v : 2; };
hmm this is not at all what I would call 422, so be wary of using that term in conjunction with YUV, nor 8888. Normally this means that the u and v planes are sampled at a reduced rate see http://en.wikipedia.org/wiki/YUV_4:2:2 for example
OK. I meant only number of bits for each component and this was the simplest name I thought of. Adam Badura
From: "Adam Badura" <abadura@o2.pl>
For now I think taht template representation would be best. What i mean is for example
struct rgb_8888 { unsigned char r : 8; unsigned char g : 8; unsigned char b : 8; unsigned char : 8; };
struct yuv_422 { unsigned char y : 4; unsigned char u : 2; unsigned char v : 2; };
template<typename Components> class color { private: Components mComponents; };
I haven't been following your discussion but this looks suspect. First, you'd need to specialize color for each color structure type so the color member functions know how to do the right thing. That obviates what I think you're trying to do with the template. Second, all code using colors must be either templated on color type or will only work with one type. That is, including the representation in the type (color<yuv_422>) means that functions must be written in terms of color<something> and can't work with color<something_else_entirely>. To fix the former problem, you might consider that the color template can provide higher level functionality from primitives supplied by a policy type. Thus, your Components type would have to provide represention plus primitives. To fix the latter problem, you would need an ABC from which color<T> derives. HTH -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Actually, to be mor acurate I do something like this: struct rgb_8888 { unsigned char _r : 8; unsigned char _g : 8; unsigned char _b : 8; unsigned char : 8; unsigned char red() const {/*...*/} void red(unsigned char r) {/*...*/} unsigned char green() const {/*...*/} void green(unsigned char r) {/*...*/} unsigned char blue() const {/*...*/} void blue(unsigned char r) {/*...*/} unsigned char component(unsigned int index) const {{/*...*/} unsigned char& component(unsigned int index) {/*...*/} }; template<typename Components> class component_traits { public: typedef ? component_type; static const int components; static const int indexes[components]; static const component_type min[components]; static const component_type max[components]; }; and than specialization could look like this: component_traits<rgb_8888>::component_type === usnigned char component_traits<rgb_8888>::min === [0, 0, 0] component_traits<rgb_8888>::max === [255, 255, 255] component_traits<rgb_double>::component_type === double component_traits<rgb_8888>::min === [0.0, 0.0, 0.0] component_traits<rgb_8888>::max === [1.0, 1.0, 1.0] and so on... The base concept is that "color" class (like for example "color_rgb", "color_yuv") akes car of color model or color space things, and therefore must be a template (polymorphism could be used as well, but code speed is here very important [graphic manipulation!] so I decidet: templates) parametrized with "components type". This "component type" takes care for serving color data lika values of channels. "components type" knows exact types and palcement in memory. So if you want to use your own format in wich all channels have 10 bits size and all is stored in double word you just write simple components type: struct your_rgb { unsigned int _r : 10; unsigned int _g : 10; unsigned int _b : 10; unsigned int : 2; unsigned int red() const { return _r;} void red(unsigned int r) {_r = r;} unsigned int green() const {return _g;} void green(unsigned int r) {_g = g;} unsigned int blue() const {return _b;} void blue(unsigned int r) {_b = b;} unsigned int component(unsigned int index) const {/*...*/} unsigned int& component(unsigned int index) {/*...*/} }; component_traits<your_rgb>::component_type === usnigned int component_traits<your_rgb>::indexes === [0, 1, 2] component_traits<your_rgb>::min === [0, 0, 0] component_traits<your_rgb>::max === [2^10, 2^10, 2^10] in this case writing "component" could be a little difficult however youy can be sure taht "color class" will not call your functions with improper arguments by it self (actually to speed up code control can be turned of and the user may give wrong arguments, but if someone wants to spoild program he will do it anyway). Also you dont have to actualy retrun type "component_traits<your_rgb>::component_type" but type that behaves like it were this type. (component_traits::indexes is to allow another order of data not only RGB but for example also BGR, "color class" always [to ease using] uses index 0 for R, 1 for G and 3 for B, this is problem for "compoinent" function, to avoid using "swich" in this function, what would make its execution longer, indexes are staticly mapped, so for BGR this array would look like: component_traits<bgr>::indexes === [2, 1, 0] and "color class" still uses its indexes, but in calls to components "component" maps them (staticly) to right indexes. Hope everything is understandable... :) But now I encountered another problem, which I post in differen message. Adam Badura "Rob Stewart" <stewart@sig.com> wrote in message news:200509201642.j8KGgYci010670@shannonhoon.balstatdev.susq.com...
From: "Adam Badura" <abadura@o2.pl>
For now I think taht template representation would be best. What i
mean
is for example
struct rgb_8888 { unsigned char r : 8; unsigned char g : 8; unsigned char b : 8; unsigned char : 8; };
struct yuv_422 { unsigned char y : 4; unsigned char u : 2; unsigned char v : 2; };
template<typename Components> class color { private: Components mComponents; };
I haven't been following your discussion but this looks suspect.
First, you'd need to specialize color for each color structure type so the color member functions know how to do the right thing. That obviates what I think you're trying to do with the template.
Second, all code using colors must be either templated on color type or will only work with one type. That is, including the representation in the type (color<yuv_422>) means that functions must be written in terms of color<something> and can't work with color<something_else_entirely>.
To fix the former problem, you might consider that the color template can provide higher level functionality from primitives supplied by a policy type. Thus, your Components type would have to provide represention plus primitives.
To fix the latter problem, you would need an ABC from which color<T> derives.
HTH
-- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer; _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I have a question about this approach: what is the purpose of using templates? What operations do you see as being performed on colors polymorphically? In other words, the only advantage I see to this templated approach would be to allow clients to write templated functions/classes which could operate on arbitrary color types, but I can't think of any interesting functions that would work with your approach. (P.S. sorry if this has been addressed earlier in the thread; I only just joined the list) On 9/25/05, Adam Badura <abadura@o2.pl> wrote:
Actually, to be mor acurate I do something like this:
struct rgb_8888 { unsigned char _r : 8; unsigned char _g : 8; unsigned char _b : 8; unsigned char : 8; unsigned char red() const {/*...*/} void red(unsigned char r) {/*...*/} unsigned char green() const {/*...*/} void green(unsigned char r) {/*...*/} unsigned char blue() const {/*...*/} void blue(unsigned char r) {/*...*/} unsigned char component(unsigned int index) const {{/*...*/} unsigned char& component(unsigned int index) {/*...*/} };
template<typename Components> class component_traits { public: typedef ? component_type; static const int components; static const int indexes[components]; static const component_type min[components]; static const component_type max[components]; };
and than specialization could look like this:
component_traits<rgb_8888>::component_type === usnigned char component_traits<rgb_8888>::min === [0, 0, 0] component_traits<rgb_8888>::max === [255, 255, 255]
component_traits<rgb_double>::component_type === double component_traits<rgb_8888>::min === [0.0, 0.0, 0.0] component_traits<rgb_8888>::max === [1.0, 1.0, 1.0]
and so on...
The base concept is that "color" class (like for example "color_rgb", "color_yuv") akes car of color model or color space things, and therefore must be a template (polymorphism could be used as well, but code speed is here very important [graphic manipulation!] so I decidet: templates) parametrized with "components type". This "component type" takes care for serving color data lika values of channels. "components type" knows exact types and palcement in memory. So if you want to use your own format in wich all channels have 10 bits size and all is stored in double word you just write simple components type:
struct your_rgb { unsigned int _r : 10; unsigned int _g : 10; unsigned int _b : 10; unsigned int : 2; unsigned int red() const { return _r;} void red(unsigned int r) {_r = r;} unsigned int green() const {return _g;} void green(unsigned int r) {_g = g;} unsigned int blue() const {return _b;} void blue(unsigned int r) {_b = b;} unsigned int component(unsigned int index) const {/*...*/} unsigned int& component(unsigned int index) {/*...*/} };
component_traits<your_rgb>::component_type === usnigned int component_traits<your_rgb>::indexes === [0, 1, 2] component_traits<your_rgb>::min === [0, 0, 0] component_traits<your_rgb>::max === [2^10, 2^10, 2^10]
in this case writing "component" could be a little difficult however youy can be sure taht "color class" will not call your functions with improper arguments by it self (actually to speed up code control can be turned of and the user may give wrong arguments, but if someone wants to spoild program he will do it anyway). Also you dont have to actualy retrun type "component_traits<your_rgb>::component_type" but type that behaves like it were this type. (component_traits::indexes is to allow another order of data not only RGB but for example also BGR, "color class" always [to ease using] uses index 0 for R, 1 for G and 3 for B, this is problem for "compoinent" function, to avoid using "swich" in this function, what would make its execution longer, indexes are staticly mapped, so for BGR this array would look like:
component_traits<bgr>::indexes === [2, 1, 0]
and "color class" still uses its indexes, but in calls to components "component" maps them (staticly) to right indexes. Hope everything is understandable... :)
But now I encountered another problem, which I post in differen message.
Adam Badura
"Rob Stewart" <stewart@sig.com> wrote in message news:200509201642.j8KGgYci010670@shannonhoon.balstatdev.susq.com...
From: "Adam Badura" <abadura@o2.pl>
For now I think taht template representation would be best. What i
mean
is for example
struct rgb_8888 { unsigned char r : 8; unsigned char g : 8; unsigned char b : 8; unsigned char : 8; };
struct yuv_422 { unsigned char y : 4; unsigned char u : 2; unsigned char v : 2; };
template<typename Components> class color { private: Components mComponents; };
I haven't been following your discussion but this looks suspect.
First, you'd need to specialize color for each color structure type so the color member functions know how to do the right thing. That obviates what I think you're trying to do with the template.
Second, all code using colors must be either templated on color type or will only work with one type. That is, including the representation in the type (color<yuv_422>) means that functions must be written in terms of color<something> and can't work with color<something_else_entirely>.
To fix the former problem, you might consider that the color template can provide higher level functionality from primitives supplied by a policy type. Thus, your Components type would have to provide represention plus primitives.
To fix the latter problem, you would need an ABC from which color<T> derives.
HTH
-- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer; _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I have a question about this approach: what is the purpose of using templates? What operations do you see as being performed on colors polymorphically?
In other words, the only advantage I see to this templated approach would be to allow clients to write templated functions/classes which could operate on arbitrary color types, but I can't think of any interesting functions that would work with your approach.
(P.S. sorry if this has been addressed earlier in the thread; I only just joined the list)
On 9/25/05, Adam Badura <abadura@o2.pl> wrote:
Actually, to be mor acurate I do something like this:
struct rgb_8888 { unsigned char _r : 8; unsigned char _g : 8; unsigned char _b : 8; unsigned char : 8; unsigned char red() const {/*...*/} void red(unsigned char r) {/*...*/} unsigned char green() const {/*...*/} void green(unsigned char r) {/*...*/} unsigned char blue() const {/*...*/} void blue(unsigned char r) {/*...*/} unsigned char component(unsigned int index) const {{/*...*/} unsigned char& component(unsigned int index) {/*...*/} };
template<typename Components> class component_traits { public: typedef ? component_type; static const int components; static const int indexes[components]; static const component_type min[components]; static const component_type max[components]; };
and than specialization could look like this:
component_traits<rgb_8888>::component_type === usnigned char component_traits<rgb_8888>::min === [0, 0, 0] component_traits<rgb_8888>::max === [255, 255, 255]
component_traits<rgb_double>::component_type === double component_traits<rgb_8888>::min === [0.0, 0.0, 0.0] component_traits<rgb_8888>::max === [1.0, 1.0, 1.0]
and so on...
The base concept is that "color" class (like for example
"color_rgb",
"color_yuv") akes car of color model or color space things, and
must be a template (polymorphism could be used as well, but code speed is here very important [graphic manipulation!] so I decidet: templates) parametrized with "components type". This "component type" takes care for serving color data lika values of channels. "components type" knows exact types and palcement in memory. So if you want to use your own format in wich all channels have 10 bits size and all is stored in double word you just write simple components type:
struct your_rgb { unsigned int _r : 10; unsigned int _g : 10; unsigned int _b : 10; unsigned int : 2; unsigned int red() const { return _r;} void red(unsigned int r) {_r = r;} unsigned int green() const {return _g;} void green(unsigned int r) {_g = g;} unsigned int blue() const {return _b;} void blue(unsigned int r) {_b = b;} unsigned int component(unsigned int index) const {/*...*/} unsigned int& component(unsigned int index) {/*...*/} };
component_traits<your_rgb>::component_type === usnigned int component_traits<your_rgb>::indexes === [0, 1, 2] component_traits<your_rgb>::min === [0, 0, 0] component_traits<your_rgb>::max === [2^10, 2^10, 2^10]
in this case writing "component" could be a little difficult however youy can be sure taht "color class" will not call your functions with improper arguments by it self (actually to speed up code control can be turned of and the user may give wrong arguments, but if someone wants to spoild
Polymorphism would clearly make difference beetwean color representation and its model. This difference could be nicely checked at complie time without genereting "tamplate errors" which are usually hard to understand aspecially when nested or when you are not author of the code in which error is signaled and would like not even look at this code. If I could use polymorphism (I cannot because of code speed) I would have somethinkg like this. class rgb_representation { public: /* ... */ virtual double red() const = 0; virtual void red(double) = 0; virtual double green() const = 0; virtual void green(double) = 0; virtual double blue() const = 0; virtual void blue(double) = 0; /* ... */ }; class color_rgb { public: color_rgb(rgb_representation& data); /* ... */ }; Naturally this sollution still has cons (beside speed). For easing dealing with different component types (int, float, ...) templates probably would be still needed. And this makes it harder to use "color_rgb" in code like this: color_rgb image_buffer[width][height]; But it would be easier to make a "statement" on what does "rgb_representation" need and enforce using only right classes in more pleasent (error messages...) way. And again. Using polymorphism could lead to quite another project. The model could be actualy implemented in abstract base class, but only functions like "red", "green", "blue" would have to be added by user (naturelly common model would be implemented in lib) this would solve the "image_buffer" problem and few others in this kind... Adam Badura "Geoffrey Romer" <geoff.romer@gmail.com> wrote in message news:301730110509250954e16f7d0@mail.gmail.com... therefore program he
will do it anyway). Also you dont have to actualy retrun type "component_traits<your_rgb>::component_type" but type that behaves like it were this type. (component_traits::indexes is to allow another order of data not only RGB but for example also BGR, "color class" always [to ease using] uses index 0 for R, 1 for G and 3 for B, this is problem for "compoinent" function, to avoid using "swich" in this function, what would make its execution longer, indexes are staticly mapped, so for BGR this array would look like:
component_traits<bgr>::indexes === [2, 1, 0]
and "color class" still uses its indexes, but in calls to components "component" maps them (staticly) to right indexes. Hope everything is understandable... :)
But now I encountered another problem, which I post in differen message.
Adam Badura
"Rob Stewart" <stewart@sig.com> wrote in message news:200509201642.j8KGgYci010670@shannonhoon.balstatdev.susq.com...
From: "Adam Badura" <abadura@o2.pl>
For now I think taht template representation would be best. What
i mean
is for example
struct rgb_8888 { unsigned char r : 8; unsigned char g : 8; unsigned char b : 8; unsigned char : 8; };
struct yuv_422 { unsigned char y : 4; unsigned char u : 2; unsigned char v : 2; };
template<typename Components> class color { private: Components mComponents; };
I haven't been following your discussion but this looks suspect.
First, you'd need to specialize color for each color structure type so the color member functions know how to do the right thing. That obviates what I think you're trying to do with the template.
Second, all code using colors must be either templated on color type or will only work with one type. That is, including the representation in the type (color<yuv_422>) means that functions must be written in terms of color<something> and can't work with color<something_else_entirely>.
To fix the former problem, you might consider that the color template can provide higher level functionality from primitives supplied by a policy type. Thus, your Components type would have to provide represention plus primitives.
To fix the latter problem, you would need an ABC from which color<T> derives.
HTH
-- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer; _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I think you're assuming that when I said "polymorphism", I meant "inheritance and virtual functions", but "polymorphism" just means having one piece of code operate on different kinds of data. Templates are a kind of polymorphism, and that's what I'm referring to. My question, rephrased, is just "why use templates?" What does this templated structure give you that you wouldn't get from just having a bunch of unrelated classes (rgb_color, cymk_color, etc.)? How would a programmer take advantage of your templated structure? In other words, can you give an example of how you see this library being used, in a way that wouldn't be possible (or easy) without templates? On 9/25/05, Adam Badura <abadura@o2.pl> wrote:
Polymorphism would clearly make difference beetwean color representation and its model. This difference could be nicely checked at complie time without genereting "tamplate errors" which are usually hard to understand aspecially when nested or when you are not author of the code in which error is signaled and would like not even look at this code.
If I could use polymorphism (I cannot because of code speed) I would have somethinkg like this.
class rgb_representation { public: /* ... */ virtual double red() const = 0; virtual void red(double) = 0; virtual double green() const = 0; virtual void green(double) = 0; virtual double blue() const = 0; virtual void blue(double) = 0; /* ... */ };
class color_rgb { public: color_rgb(rgb_representation& data); /* ... */ };
Naturally this sollution still has cons (beside speed). For easing dealing with different component types (int, float, ...) templates probably would be still needed. And this makes it harder to use "color_rgb" in code like this:
color_rgb image_buffer[width][height];
But it would be easier to make a "statement" on what does "rgb_representation" need and enforce using only right classes in more pleasent (error messages...) way.
And again. Using polymorphism could lead to quite another project. The model could be actualy implemented in abstract base class, but only functions like "red", "green", "blue" would have to be added by user (naturelly common model would be implemented in lib) this would solve the "image_buffer" problem and few others in this kind...
Adam Badura
I have a question about this approach: what is the purpose of using templates? What operations do you see as being performed on colors polymorphically?
In other words, the only advantage I see to this templated approach would be to allow clients to write templated functions/classes which could operate on arbitrary color types, but I can't think of any interesting functions that would work with your approach.
(P.S. sorry if this has been addressed earlier in the thread; I only just joined the list)
On 9/25/05, Adam Badura <abadura@o2.pl> wrote:
Actually, to be mor acurate I do something like this:
struct rgb_8888 { unsigned char _r : 8; unsigned char _g : 8; unsigned char _b : 8; unsigned char : 8; unsigned char red() const {/*...*/} void red(unsigned char r) {/*...*/} unsigned char green() const {/*...*/} void green(unsigned char r) {/*...*/} unsigned char blue() const {/*...*/} void blue(unsigned char r) {/*...*/} unsigned char component(unsigned int index) const {{/*...*/} unsigned char& component(unsigned int index) {/*...*/} };
template<typename Components> class component_traits { public: typedef ? component_type; static const int components; static const int indexes[components]; static const component_type min[components]; static const component_type max[components]; };
and than specialization could look like this:
component_traits<rgb_8888>::component_type === usnigned char component_traits<rgb_8888>::min === [0, 0, 0] component_traits<rgb_8888>::max === [255, 255, 255]
component_traits<rgb_double>::component_type === double component_traits<rgb_8888>::min === [0.0, 0.0, 0.0] component_traits<rgb_8888>::max === [1.0, 1.0, 1.0]
and so on...
The base concept is that "color" class (like for example
"color_rgb",
"color_yuv") akes car of color model or color space things, and
must be a template (polymorphism could be used as well, but code speed is here very important [graphic manipulation!] so I decidet: templates) parametrized with "components type". This "component type" takes care for serving color data lika values of channels. "components type" knows exact types and palcement in memory. So if you want to use your own format in wich all channels have 10 bits size and all is stored in double word you just write simple components type:
struct your_rgb { unsigned int _r : 10; unsigned int _g : 10; unsigned int _b : 10; unsigned int : 2; unsigned int red() const { return _r;} void red(unsigned int r) {_r = r;} unsigned int green() const {return _g;} void green(unsigned int r) {_g = g;} unsigned int blue() const {return _b;} void blue(unsigned int r) {_b = b;} unsigned int component(unsigned int index) const {/*...*/} unsigned int& component(unsigned int index) {/*...*/} };
component_traits<your_rgb>::component_type === usnigned int component_traits<your_rgb>::indexes === [0, 1, 2] component_traits<your_rgb>::min === [0, 0, 0] component_traits<your_rgb>::max === [2^10, 2^10, 2^10]
in this case writing "component" could be a little difficult however youy can be sure taht "color class" will not call your functions with improper arguments by it self (actually to speed up code control can be turned of and the user may give wrong arguments, but if someone wants to spoild
"Geoffrey Romer" <geoff.romer@gmail.com> wrote in message news:301730110509250954e16f7d0@mail.gmail.com... therefore program he
will do it anyway). Also you dont have to actualy retrun type "component_traits<your_rgb>::component_type" but type that behaves like it were this type. (component_traits::indexes is to allow another order of data not only RGB but for example also BGR, "color class" always [to ease using] uses index 0 for R, 1 for G and 3 for B, this is problem for "compoinent" function, to avoid using "swich" in this function, what would make its execution longer, indexes are staticly mapped, so for BGR this array would look like:
component_traits<bgr>::indexes === [2, 1, 0]
and "color class" still uses its indexes, but in calls to components "component" maps them (staticly) to right indexes. Hope everything is understandable... :)
But now I encountered another problem, which I post in differen message.
Adam Badura
"Rob Stewart" <stewart@sig.com> wrote in message news:200509201642.j8KGgYci010670@shannonhoon.balstatdev.susq.com...
From: "Adam Badura" <abadura@o2.pl>
For now I think taht template representation would be best. What
i mean
is for example
struct rgb_8888 { unsigned char r : 8; unsigned char g : 8; unsigned char b : 8; unsigned char : 8; };
struct yuv_422 { unsigned char y : 4; unsigned char u : 2; unsigned char v : 2; };
template<typename Components> class color { private: Components mComponents; };
I haven't been following your discussion but this looks suspect.
First, you'd need to specialize color for each color structure type so the color member functions know how to do the right thing. That obviates what I think you're trying to do with the template.
Second, all code using colors must be either templated on color type or will only work with one type. That is, including the representation in the type (color<yuv_422>) means that functions must be written in terms of color<something> and can't work with color<something_else_entirely>.
To fix the former problem, you might consider that the color template can provide higher level functionality from primitives supplied by a policy type. Thus, your Components type would have to provide represention plus primitives.
To fix the latter problem, you would need an ABC from which color<T> derives.
HTH
-- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer; _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Geoffrey Romer wrote:
I think you're assuming that when I said "polymorphism", I meant "inheritance and virtual functions", but "polymorphism" just means having one piece of code operate on different kinds of data. Templates are a kind of polymorphism, and that's what I'm referring to.
In the general C++ community, there is a sharp distinction between run-time and compile-time polymorphism, due to the 'zero-overhead' philosophy of C++, (ie. you don't pay for what you don't absolutely _have_ to pay for). Therefore, unqualified use of the term 'polymorphism' is normally assumed to mean run-time polymophism (simply because that was added to C++ first), although you are correct in your usage of it otherwise. The 'safe' term to use in this case is 'generic' code. Just FYI.
My question, rephrased, is just "why use templates?" What does this templated structure give you that you wouldn't get from just having a bunch of unrelated classes (rgb_color, cymk_color, etc.)? How would a programmer take advantage of your templated structure?
The idea is to write code that can operate on graphical data without assuming anything about the representation of said data. To do that efficiently in C++ is practicly a description of what templates are for.
In other words, can you give an example of how you see this library being used, in a way that wouldn't be possible (or easy) without templates?
consider a function that *someone* will need to use, that doesn't depend on the representation of the data: // where GraphContext is a TwoDimContainer with a value_type // convertable to PixelRepr template <class PixelRepr, class GraphContext> void resample(const GraphContext& from, GraphContext& to) { // ... // Dumb aliasing resampling to[x][y] = from[x*x_scale][y*y_scale]; // ... } <snip gargantuan quote placed below replies>
I think you're assuming that when I said "polymorphism", I meant "inheritance and virtual functions", but "polymorphism" just means having one piece of code operate on different kinds of data. Templates are a kind of polymorphism, and that's what I'm referring to.
In the general C++ community, there is a sharp distinction between run-time and compile-time polymorphism, due to the 'zero-overhead' philosophy of C++, (ie. you don't pay for what you don't absolutely _have_ to pay for). Therefore, unqualified use of the term 'polymorphism' is normally assumed to mean run-time polymophism (simply because that was added to C++ first), although you are correct in your usage of it otherwise. The 'safe' term to use in this case is 'generic' code. Just FYI.
I'm fully aware of the distinction between compile-time and run-time polymorphism, but the notion that 'polymorphism' is assumed to mean 'run-time' is new to me (FWIW, Stroustrup suggests 'polymorphism' as a general term for both kinds). In what sense is 'generic' a safe term? I had always thought 'generic' referred specifically to compile-time polymorphism (Googling for C++ generic programming seems to back this up), but I was trying to talk about polymorphism as a general concept, apart from whether it was implemented at compile-time or run-time. If you're not saying 'generic' fills that need, what word should I have used?
In other words, can you give an example of how you see this library being used, in a way that wouldn't be possible (or easy) without templates?
consider a function that *someone* will need to use, that doesn't depend on the representation of the data:
// where GraphContext is a TwoDimContainer with a value_type // convertable to PixelRepr template <class PixelRepr, class GraphContext> void resample(const GraphContext& from, GraphContext& to) { // ... // Dumb aliasing resampling to[x][y] = from[x*x_scale][y*y_scale]; // ... }
But this function doesn't really use the proposed library, or need it. All it requires is that PixelRepr be assignable; it doesn't even have to be a color, much less a color answering to the proposed interface.
Geoffrey Romer wrote:
I think you're assuming that when I said "polymorphism", I meant "inheritance and virtual functions", but "polymorphism" just means having one piece of code operate on different kinds of data. Templates are a kind of polymorphism, and that's what I'm referring to.
In the general C++ community, there is a sharp distinction between run-time and compile-time polymorphism, due to the 'zero-overhead' philosophy of C++, (ie. you don't pay for what you don't absolutely _have_ to pay for). Therefore, unqualified use of the term 'polymorphism' is normally assumed to mean run-time polymophism (simply because that was added to C++ first), although you are correct in your usage of it otherwise. The 'safe' term to use in this case is 'generic' code. Just FYI.
I'm fully aware of the distinction between compile-time and run-time polymorphism, but the notion that 'polymorphism' is assumed to mean 'run-time' is new to me (FWIW, Stroustrup suggests 'polymorphism' as a general term for both kinds). In what sense is 'generic' a safe term? I had always thought 'generic' referred specifically to compile-time polymorphism (Googling for C++ generic programming seems to back this up), but I was trying to talk about polymorphism as a general concept, apart from whether it was implemented at compile-time or run-time. If you're not saying 'generic' fills that need, what word should I have used?
Yes, polymorphic is the 'correct' term, but it's (over?) use by the OO crowd has 'tainted' it for a lot of developers. I catch myself out with this, even. 'Generic' is 'safe', because although it hides the idea that you don't care about implementation, it isn't suspect to the 'implict cast' to run-time polymorphic. I agree that it isn't perfect, but we don't have a neat term for _just_ run-time polymorphism either. ("operations performed virtually?" I could deal with that)
In other words, can you give an example of how you see this library being used, in a way that wouldn't be possible (or easy) without templates?
consider a function that *someone* will need to use, that doesn't depend on the representation of the data:
// where GraphContext is a TwoDimContainer with a value_type // convertable to PixelRepr template <class PixelRepr, class GraphContext> void resample(const GraphContext& from, GraphContext& to) { // ... // Dumb aliasing resampling to[x][y] = from[x*x_scale][y*y_scale]; // ... }
But this function doesn't really use the proposed library, or need it. All it requires is that PixelRepr be assignable; it doesn't even have to be a color, much less a color answering to the proposed interface.
Yes I'm a moron. Sorry about that. It's not even a very good generic function, PixelRepr isn't needed as a template param, and the two GC's don't need to be the same. I suppose something more usefull would be a colour gamut conversion or something. template <class Gamut, class Repr> bool inGamut(Gamut g, rgb_color<Repr> c)? and inGamut(Gamut g, yuv_color<Repr> c), etc... . Would that work?
I suppose something more usefull would be a colour gamut conversion or something.
template <class Gamut, class Repr> bool inGamut(Gamut g, rgb_color<Repr> c)?
and inGamut(Gamut g, yuv_color<Repr> c), etc... . Would that work?
Yes, that makes sense. Let me be devil's advocate for a moment, though, because I think this example raises some interesting issues. I assume the idea here is to convert a color so that it's within the given gamut. In practice I think there would need to be more parameters because there's no single right way to map colors into a given color gamut (it all depends on what sorts of image features you want to preserve), but I'll bypass that for now. This example implies the existence of a Gamut concept, which inGamut presumably uses to determine the mapping. The thing is, I can't think of any way to define a color gamut that isn't in terms of a specific color space (e.g. as a polyhedral region in XYZ). So really, the example would need to be more like template <class Gamut_rgb, class Repr> bool inGamut(Gamut_rgb g, rgb_color<Repr> c) template <class Gamut_yuv, class Repr> bool inGamut(Gamut_yuv g, yuv_color<Repr> c) If you have to deal with gamuts or colors in more than one space, this could kind of suck. What I'm getting at, of course, is that it would be very nice to be able to write code which is generic not only with respect to color representation, but also with respect to the color model. That way one could write a single bool inGamut() template that would work anywhere. More generally, there are many operations one could imagine wanting to apply to colors, which don't require the colors to be represented in a particular model.. Off the top of my head, I can think of two ways of implementing this. One would be to choose a single color space as canonical, and define all generic operations in terms of that space. Then, each new color space just needs to define conversion operations. This has several drawbacks, most obviously the problem of performance (conversion might not be cheap). In addition, there may be subtle correctness issues associated with the convert-compute-convert model. Finally, this would restrict the system to perceptual (as opposed to physical) color models, so that (for example) spectral color models would be disallowed (this is because the canonical model would have to be a perceptual model for performance reasons, and conversion from physical to perceptual color is an information-losing operation) The alternative would be to try to decompose all "interesting" operations on colors into some fixed set of primitive operations, which each color space template would be expected to implement. More complex operations could then be defined generically in terms of those primitives. This would be elegant and efficient, but I have my doubts as to whether it's possible. Of course, my bias in this area is for more abstraction, because I'm more used to thinking of colors as abstract phenomena, without really getting my hands dirty with bits and bytes, so this may not be a practical idea. At any rate, some sort of attention to the issue of conversion between color models would be worthwhile.
Geoffrey Romer wrote:
I suppose something more usefull would be a colour gamut conversion or something.
template <class Gamut, class Repr> bool inGamut(Gamut g, rgb_color<Repr> c)?
and inGamut(Gamut g, yuv_color<Repr> c), etc... . Would that work?
Yes, that makes sense. Let me be devil's advocate for a moment, though, because I think this example raises some interesting issues. I assume the idea here is to convert a color so that it's within the given gamut. In practice I think there would need to be more parameters because there's no single right way to map colors into a given color gamut (it all depends on what sorts of image features you want to preserve), but I'll bypass that for now.
I think a lot of the time, you simply want the closest possible colour that can be represented.
This example implies the existence of a Gamut concept, which inGamut presumably uses to determine the mapping. The thing is, I can't think of any way to define a color gamut that isn't in terms of a specific color space (e.g. as a polyhedral region in XYZ). So really, the example would need to be more like
template <class Gamut_rgb, class Repr> bool inGamut(Gamut_rgb g, rgb_color<Repr> c)
template <class Gamut_yuv, class Repr> bool inGamut(Gamut_yuv g, yuv_color<Repr> c)
If you have to deal with gamuts or colors in more than one space, this could kind of suck.
What I'm getting at, of course, is that it would be very nice to be able to write code which is generic not only with respect to color representation, but also with respect to the color model. That way one could write a single bool inGamut() template that would work anywhere. More generally, there are many operations one could imagine wanting to apply to colors, which don't require the colors to be represented in a particular model..
Why do you think I didn't give a body :D
Off the top of my head, I can think of two ways of implementing this. One would be to choose a single color space as canonical, and define all generic operations in terms of that space. Then, each new color space just needs to define conversion operations. This has several drawbacks, most obviously the problem of performance (conversion might not be cheap). In addition, there may be subtle correctness issues associated with the convert-compute-convert model. Finally, this would restrict the system to perceptual (as opposed to physical) color models, so that (for example) spectral color models would be disallowed (this is because the canonical model would have to be a perceptual model for performance reasons, and conversion from physical to perceptual color is an information-losing operation)
Interesting. Actually, now that I think about it, not very many representations are even perceptual (ie. have a colour profile associated with them, and thus a single real-world colour to map to.) I would therefore have to say, use the ICC Lxy (? the 'tongue' shaped one) physical colourspace as the canonical, require all colours to be a part of a colourspace (ie: sRGB<rbg_color<int> >. uggh. Defaults? Common types?) and simply declare gamut conversions expensive. (They are already lossy, so noone should be trying to do this a lot) There is actually room for optimisation here, most gamut conversions will be on large amounts of different colours at once with a single conversion, therefore some sort of palleted conversion could be possible. I'm not an expert here, so take all this with a grain of salt.
The alternative would be to try to decompose all "interesting" operations on colors into some fixed set of primitive operations, which each color space template would be expected to implement. More complex operations could then be defined generically in terms of those primitives. This would be elegant and efficient, but I have my doubts as to whether it's possible.
That _would_ be cool, but it does seem to be improbable.
Of course, my bias in this area is for more abstraction, because I'm more used to thinking of colors as abstract phenomena, without really getting my hands dirty with bits and bytes, so this may not be a practical idea.
At any rate, some sort of attention to the issue of conversion between color models would be worthwhile.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
True. But all this is somewhat off the original point (but still important).
Off the top of my head, I can think of two ways of implementing this. One would be to choose a single color space as canonical, and define all generic operations in terms of that space. Then, each new color space just needs to define conversion operations. This has several drawbacks, most obviously the problem of performance (conversion might not be cheap). In addition, there may be subtle correctness issues associated with the convert-compute-convert model. Finally, this would restrict the system to perceptual (as opposed to physical) color models, so that (for example) spectral color models would be disallowed (this is because the canonical model would have to be a perceptual model for performance reasons, and conversion from physical to perceptual color is an information-losing operation)
Interesting. Actually, now that I think about it, not very many representations are even perceptual (ie. have a colour profile associated with them, and thus a single real-world colour to map to.) I would therefore have to say, use the ICC Lxy (? the 'tongue' shaped one) physical colourspace as the canonical, require all colours to be a part of a colourspace (ie: sRGB<rbg_color<int> >. uggh. Defaults? Common types?) and simply declare gamut conversions expensive. (They are already lossy, so noone should be trying to do this a lot) There is actually room for optimisation here, most gamut conversions will be on large amounts of different colours at once with a single conversion, therefore some sort of palleted conversion could be possible. I'm not an expert here, so take all this with a grain of salt.
I meant "perceptual" in a more general sense, meaning any color space which is designed to represent perceptually distinct colors. Essentially all commonly-used color spaces fit that criterion, because they're all based (in one way or another) around the trichromatic generalization, which is a perceptual phenomenon. A "physical" color space would be one designed to represent all physically distinct colors, i.e. all colors with distinct spectra (typically by sampling, since physical colors contain a theoretically near-infinite amount of information). RGB is unique in that it does double duty as a representation of perceptual colors and as a (very poor) representation of physical spectra. I was thinking CIE XYZ would be a sensible choice of a 'canonical' color space, because it's so common and well-understood (color gamuts are usually depicted as polygons in a slice of XYZ), and it has nice features like having all real colors in the +X +Y +Z octant. Wikipedia tells me that CIE Lab is usually considered the "standard" color space, so that might also be a good choice, except that it's expensive to convert to spaces like RGB because it's been distorted in order to be "perceptually uniform". Lab is defined in terms of XYZ, so XYZ seems like a sensible next-best, and conversion between XYZ and RGB is a linear transform (i.e. about as cheap as it gets). I'm having trouble finding references on Lxy, so I can't really comment on how good a choice it would be, but I've come across references to it that suggest it's a relative of Lab.
The alternative would be to try to decompose all "interesting" operations on colors into some fixed set of primitive operations, which each color space template would be expected to implement. More complex operations could then be defined generically in terms of those primitives. This would be elegant and efficient, but I have my doubts as to whether it's possible.
This better describes what I try to do...
Of course, my bias in this area is for more abstraction, because I'm more used to thinking of colors as abstract phenomena, without really getting my hands dirty with bits and bytes, so this may not be a practical idea.
As. I like abstraction the same. But I want this library to be really useful wich means it as to be useful in graphic manipulation and therefor code mus be as fast (or almost as fast) as hand written... Adam Badura
I think you're assuming that when I said "polymorphism", I meant "inheritance and virtual functions", but "polymorphism" just means having one piece of code operate on different kinds of data. Templates are a kind of polymorphism, and that's what I'm referring to.
My question, rephrased, is just "why use templates?" What does this templated structure give you that you wouldn't get from just having a bunch of unrelated classes (rgb_color, cymk_color, etc.)? How would a programmer take advantage of your templated structure?
In other words, can you give an example of how you see this library being used, in a way that wouldn't be possible (or easy) without templates?
On 9/25/05, Adam Badura <abadura@o2.pl> wrote:
Polymorphism would clearly make difference beetwean color
representation
and its model. This difference could be nicely checked at complie time without genereting "tamplate errors" which are usually hard to understand aspecially when nested or when you are not author of the code in which error is signaled and would like not even look at this code.
If I could use polymorphism (I cannot because of code speed) I would have somethinkg like this.
class rgb_representation { public: /* ... */ virtual double red() const = 0; virtual void red(double) = 0; virtual double green() const = 0; virtual void green(double) = 0; virtual double blue() const = 0; virtual void blue(double) = 0; /* ... */ };
class color_rgb { public: color_rgb(rgb_representation& data); /* ... */ };
Naturally this sollution still has cons (beside speed). For easing dealing with different component types (int, float, ...) templates
would be still needed. And this makes it harder to use "color_rgb" in code like this:
color_rgb image_buffer[width][height];
But it would be easier to make a "statement" on what does "rgb_representation" need and enforce using only right classes in more pleasent (error messages...) way.
And again. Using polymorphism could lead to quite another project. The model could be actualy implemented in abstract base class, but only functions like "red", "green", "blue" would have to be added by user (naturelly common model would be implemented in lib) this would solve
"image_buffer" problem and few others in this kind...
Adam Badura
I have a question about this approach: what is the purpose of using templates? What operations do you see as being performed on colors polymorphically?
In other words, the only advantage I see to this templated approach would be to allow clients to write templated functions/classes which could operate on arbitrary color types, but I can't think of any interesting functions that would work with your approach.
(P.S. sorry if this has been addressed earlier in the thread; I only just joined the list)
On 9/25/05, Adam Badura <abadura@o2.pl> wrote:
Actually, to be mor acurate I do something like this:
struct rgb_8888 { unsigned char _r : 8; unsigned char _g : 8; unsigned char _b : 8; unsigned char : 8; unsigned char red() const {/*...*/} void red(unsigned char r) {/*...*/} unsigned char green() const {/*...*/} void green(unsigned char r) {/*...*/} unsigned char blue() const {/*...*/} void blue(unsigned char r) {/*...*/} unsigned char component(unsigned int index) const {{/*...*/} unsigned char& component(unsigned int index) {/*...*/} };
template<typename Components> class component_traits { public: typedef ? component_type; static const int components; static const int indexes[components]; static const component_type min[components]; static const component_type max[components]; };
and than specialization could look like this:
component_traits<rgb_8888>::component_type === usnigned char component_traits<rgb_8888>::min === [0, 0, 0] component_traits<rgb_8888>::max === [255, 255, 255]
component_traits<rgb_double>::component_type === double component_traits<rgb_8888>::min === [0.0, 0.0, 0.0] component_traits<rgb_8888>::max === [1.0, 1.0, 1.0]
and so on...
The base concept is that "color" class (like for example
"color_rgb",
"color_yuv") akes car of color model or color space things, and
must be a template (polymorphism could be used as well, but code speed is here very important [graphic manipulation!] so I decidet: templates) parametrized with "components type". This "component type" takes care for serving color data lika values of channels. "components type" knows exact types and palcement in memory. So if you want to use your own format in wich all channels have 10 bits size and all is stored in double word you just write simple components type:
struct your_rgb { unsigned int _r : 10; unsigned int _g : 10; unsigned int _b : 10; unsigned int : 2; unsigned int red() const { return _r;} void red(unsigned int r) {_r = r;} unsigned int green() const {return _g;} void green(unsigned int r) {_g = g;} unsigned int blue() const {return _b;} void blue(unsigned int r) {_b = b;} unsigned int component(unsigned int index) const {/*...*/} unsigned int& component(unsigned int index) {/*...*/} };
component_traits<your_rgb>::component_type === usnigned int component_traits<your_rgb>::indexes === [0, 1, 2] component_traits<your_rgb>::min === [0, 0, 0] component_traits<your_rgb>::max === [2^10, 2^10, 2^10]
in this case writing "component" could be a little difficult however youy can be sure taht "color class" will not call your functions with improper arguments by it self (actually to speed up code control can be turned of and the user may give wrong arguments, but if someone wants to spoild
"Geoffrey Romer" <geoff.romer@gmail.com> wrote in message news:301730110509250954e16f7d0@mail.gmail.com... therefore program he
will do it anyway). Also you dont have to actualy retrun type "component_traits<your_rgb>::component_type" but type that behaves
I use tamplates to allow user to have on class (class name to be honest, because templates de facto create many classes) with fixed interface to manipulate on color data (for example color_rgb, color_cmyk, color_yuv) with abilyty to have many underlying representations. You could than wrtie simple function: template<typename color> vertex<color> get_middle(vertex<color> p1, vertex<color> p2) { vertex<color> result; result.color.red((p1.red()+p2.red())/2); result.color.red((p1.green()+p2.green())/2); result.color.red((p1.blue()+p2.blue())/2); result.point = (p1.point+p2.point)/2; return result; } without carying if RGB used by application will be [unsigned char, unsigned char, unsigned char], or [float, float, float] or somthing like DirectX uses, or OpenGL or anything else. You are just sure what color_rgb gives you and if you don't need to manipulate on actual representation (and usually beside reading adn writing data you don't have to as I suppose) you can yous its interface and it will take care on actual underlying representation. This as I mentioned in previous post could be done by inheritance and virtual functions. But this would make this class useles in many cases due to runtime overhead caused by virtual calls (but has many advantages as i mentioned). So another way is to have templates (yes, indeed this proves what you say about polymorphism) which a bit less comfortable in use will however generate fas code (I hope so... :)). Adam Badura "Geoffrey Romer" <geoff.romer@gmail.com> wrote in message news:3017301105092521196e6cef15@mail.gmail.com... probably the like
it
were this type. (component_traits::indexes is to allow another order of data not only RGB but for example also BGR, "color class" always [to ease using] uses index 0 for R, 1 for G and 3 for B, this is problem for "compoinent" function, to avoid using "swich" in this function, what would make its execution longer, indexes are staticly mapped, so for BGR this array would look like:
component_traits<bgr>::indexes === [2, 1, 0]
and "color class" still uses its indexes, but in calls to components "component" maps them (staticly) to right indexes. Hope everything is understandable... :)
But now I encountered another problem, which I post in differen message.
Adam Badura
"Rob Stewart" <stewart@sig.com> wrote in message news:200509201642.j8KGgYci010670@shannonhoon.balstatdev.susq.com...
From: "Adam Badura" <abadura@o2.pl>
For now I think taht template representation would be best.
What i mean
is for example
struct rgb_8888 { unsigned char r : 8; unsigned char g : 8; unsigned char b : 8; unsigned char : 8; };
struct yuv_422 { unsigned char y : 4; unsigned char u : 2; unsigned char v : 2; };
template<typename Components> class color { private: Components mComponents; };
I haven't been following your discussion but this looks suspect.
First, you'd need to specialize color for each color structure type so the color member functions know how to do the right thing. That obviates what I think you're trying to do with the template.
Second, all code using colors must be either templated on color type or will only work with one type. That is, including the representation in the type (color<yuv_422>) means that functions must be written in terms of color<something> and can't work with color<something_else_entirely>.
To fix the former problem, you might consider that the color template can provide higher level functionality from primitives supplied by a policy type. Thus, your Components type would have to provide represention plus primitives.
To fix the latter problem, you would need an ABC from which color<T> derives.
HTH
-- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer; _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Adam Badura wrote:
I use tamplates to allow user to have on class (class name to be honest, because templates de facto create many classes) with fixed interface to manipulate on color data (for example color_rgb, color_cmyk, color_yuv) with abilyty to have many underlying representations. You could than wrtie simple function:
template<typename color> vertex<color> get_middle(vertex<color> p1, vertex<color> p2) { vertex<color> result; result.color.red((p1.red()+p2.red())/2); result.color.red((p1.green()+p2.green())/2); result.color.red((p1.blue()+p2.blue())/2); result.point = (p1.point+p2.point)/2; return result; }
I get suspicious about the idea of using templated functions to work on image data, because - you can get slow compile times for non-trivial - it will be harder to provide image manipulation plugins (as dynamic libraries) It was already noted that YUV typically has different sizes for components, so it is not exactly usable with the above function. In fact, I think your proposal lacks concrete goals and real-world examples. Are you trying to get somethink like QColor (http://doc.trolltech.com/4.0/qcolor.html) with BSL license? Or color library that can handle any color model on earth? If the latter, how about taking look at existing open-source drawing applications written in C++ 1. Inkscape (http://inkscape.org) (Vector drawing tool) 2. Krita (http://www.koffice.org/krita/) (Pixel drawining tool) The latter is especially interesting because it supports CMYK, and 16-bit color depth. Maybe, you can study their code and describe how your library can benefit those projects? And then contact them to find their opinion? Or ask them what they'd like to have?
I think you're assuming that when I said "polymorphism", I meant "inheritance and virtual functions", but "polymorphism" just means
[ snip 300 lines of quoted messages ] - Volodya
I get suspicious about the idea of using templated functions to work on image data, because - you can get slow compile times for non-trivial
Yes. This can be hard. But I preffer that then have to write each class by myself (those would also take time to compile) and to maintaint them by myself.
- it will be harder to provide image manipulation plugins (as dynamic libraries)
Here I thik I don't understnad what you mean. STL is also templet based and is widely used...
It was already noted that YUV typically has different sizes for components, so it is not exactly usable with the above function.
Why?
In fact, I think your proposal lacks concrete goals and real-world examples. Are you trying to get somethink like QColor (http://doc.trolltech.com/4.0/qcolor.html) with BSL license? Or color library that can handle any color model on earth?
I took a look on QColor and this is not what I want to do. To be honest at first I wanted something like this, but than chagedn my mind. I think a better solution can be achived when library serves one class for each color model (say it would be color_rgb, color_yuv, color_hsv, ...). Those classes would serve basic functionality on manipulating on color components in to manners: representation dependent and representation independent. Plus naturally features like constants for some set of colors, reading colors from string, or writing as a string, converting beetwean models (where possible), darkening, lightening of a color and so like... Also I would like to make controled functions and uncontroled (contorled would correct uncorect data for example if R in RGB is unsigned 8 bit and user gives 257 it would round it to correct 255 or throw an error - but this should be easy to turn on or of, so I'm still not sure how best to achive it). Another (larger) set of classes would take care of color representation. Take RGB as an example. You can store it as just 3x8-bit, or 32 bit (with different byte order possibilites!), or 3xfloat, or 3xdouble, or... or... And this is only RGB! what with other formats. What with other libraries (like DirectX or OpenGL - they too have their formats). All this are stil RGB colors with theri properties but are stored differently in memory. So I thought that it would be best to make a small class responisble for this memory storage and serving of data (few simple functions like set and get for each component). This would be easy to implement and library would have its implementations for most common formats. And with such a class would be parametrized color model class (you would have something like color_rgb<rgb_8888> or color_rgb<rgb_float>). This would ease writing representation independend but due to template use sill speed effective functions manipuleting on colors (for example interpolating color one a triangle or something like this...). It would also ease the task of color conversions. You would not have to have a conversion for each representation, but only for each model. So I thought...
If the latter, how about taking look at existing open-source drawing applications written in C++
1. Inkscape (http://inkscape.org) (Vector drawing tool) 2. Krita (http://www.koffice.org/krita/) (Pixel drawining tool)
The latter is especially interesting because it supports CMYK, and 16-bit color depth.
Maybe, you can study their code and describe how your library can benefit those projects? And then contact them to find their opinion? Or ask them what they'd like to have?
Thanks. I will do this... I still have no good enough solution to some problems so this would certenly help... Adam Badura
Adam Badura wrote:
I get suspicious about the idea of using templated functions to work on image data, because - you can get slow compile times for non-trivial
Yes. This can be hard. But I preffer that then have to write each class by myself (those would also take time to compile) and to maintaint them by myself.
It is not clear that you'll need really many classes. Specifically, do you know of any use case where you need to manipulate HSV color format directly? Say, scale an image in that format? I don't, but I'm not graphics expert.
- it will be harder to provide image manipulation plugins (as dynamic libraries)
Here I thik I don't understnad what you mean. STL is also templet based and is widely used...
STL analogy is not right. Say you want to implement "add rain drops to image" functionality for image editor. That functionality should be in form of dynamic library. So, you can just write template function. You need to instantiate it so that the library has certain binary interface. And the question is whether you better code against the binary interface and don't bother with templates.
It was already noted that YUV typically has different sizes for components, so it is not exactly usable with the above function.
Why?
Because you seem to associate a color object with each point. For YUV, the number of points for U and V and smaller than for Y. So, if I have color_yuv c = ...; c.u(); what happens if the given point of image has no 'u' component? - Volodya
It is not clear that you'll need really many classes. Specifically, do you know of any use case where you need to manipulate HSV color format directly? Say, scale an image in that format? I don't, but I'm not graphics expert.
STL analogy is not right. Say you want to implement "add rain drops to image" functionality for image editor. That functionality should be in
I'm not either. And if you judge by the grade which I have on my graphic curse then I'm not good at all... :) I don't know any such uses. But I think that EVEN if there are NON it is no cause to not allow (or ease) writting such a code, because someone might whant to do something like this. Besides there is a lot of thingks I have never seen to be used but know supporting libraries... form
of dynamic library. So, you can just write template function. You need to instantiate it so that the library has certain binary interface. And the question is whether you better code against the binary interface and don't bother with templates.
Yes. With templates you want be able to do binary. But why would you like that much? Note that with tamplates you actually can do the same what you would do withouth them. You can write binary in form color_rgb<rgb_float> interpolate(vertex vertex1, vertex vertex2, vertex vertex3) {/*...*/} instead of my template<typename color> color interpolate(vertex vertex1, vertex vertex2, vertex vertex3) {/*...*/} Naturally. You will have to write one function per color representation you want to support but without templates you would need this as well, so you don't loos anything here... Additionally, you can even gain. In your library you write ON template function and to have a binary you just parametrize it with few representations you find most useful...
Because you seem to associate a color object with each point. For YUV, the number of points for U and V and smaller than for Y. So, if I have
color_yuv c = ...; c.u();
what happens if the given point of image has no 'u' component?
I must still find solution to problems like this. I think that an exception would be OK alongside a function that tells whether u and v are available. But this could be to much overhead for release version of a program, so I would like to rovide a function that returns a value redgless of actual color point state, but perhabs undefined when ther is no wanted component or someting like this. Also it would be very useful to easy swich beetwean those types of functions. So I'm still think here... Adam Badura
Vladimir Prus wrote:
Adam Badura wrote:
I get suspicious about the idea of using templated functions to work on image data, because - you can get slow compile times for non-trivial
Yes. This can be hard. But I preffer that then have to write each class by myself (those would also take time to compile) and to maintaint them by myself.
It is not clear that you'll need really many classes. Specifically, do you know of any use case where you need to manipulate HSV color format directly? Say, scale an image in that format? I don't, but I'm not graphics expert.
In Image processing you might use it. Depending on what you are doing with the image different color models might be more appropriate than others. For example Luminance is generally better suited for feature detection than RGB. Depending on the algorithm it might be more efficient to convert the Image once to the best suited color model and perform all manipulations on the converted images. IMO a generic Image processing library (to which the color library which is discussed here is a first step) would be a great asset, especially for research.
It was already noted that YUV typically has different sizes for components, so it is not exactly usable with the above function.
Why?
Because you seem to associate a color object with each point. For YUV, the number of points for U and V and smaller than for Y. So, if I have
color_yuv c = ...; c.u();
what happens if the given point of image has no 'u' component?
Could you expand on what you mean here? I don't know much about different image (or video) formates, so I might be wrong here, but I always assumed that "different sizes for components" meant that in for example YUV844 an 16 bit pixel there are 8 bit Y and 4 bit for each U and V. But from what you write it sounds more like: Only every second pixel carries U and V data. If this is the case the class that holds the color representation will probably be more complex, and depend on a class that represents Image or Video. Manipulation of Images that are represented in this way might be slow, but it might still be faster than convert -> manipulate -> convert back, if the image (or video) is big and only a few pixels are manipulated. Whats more this is the only way to manipulate such an entity in-place. Fabio
OK, I think I understand- the idea is to be generic across representations of a single color model, not to be generic across color models. And yes, I certainly agree that inheritance/virtual functions are not the way to go in this case.
"Adam Badura" wrote:
I am gathering materials and working on a library (originaly I wanted one class, but it seems now that it wont be that easy) dealing with colors, their representation (like ranges 0.0-1.0 and 0-255), models (like RGB, YUV, HSV and others). Any sugestions or needs?
Current color models vary /a lot/, not to mention transparency. Do you plan to support all (most of) them? Apart from simple transformations a lot of work could be done with colors, for example ability to convert palette into Web safe one (http://www.btplc.com/age_disability/ClearerInformation/Colours/background.ht...). /Pavel
Current color models vary /a lot/, not to mention transparency. Do you plan to support all (most of) them?
I would like, but don't know if I will manage. That is what i planed. I think, that if library implements some domain it should do it nearly completly if it has to be reused. Adam Badura
Were you also planning for it to read ICC color profiles and handle transformations between them? There's some existing work along these lines that you may be able to integrate into your library: http://sourceforge.net/projects/sampleicc http://sourceforge.net/projects/lcms Adam Badura wrote:
Upsss... I pressed "send" to fast... :)
I am gathering materials and working on a library (originaly I wanted one class, but it seems now that it wont be that easy) dealing with colors, their representation (like ranges 0.0-1.0 and 0-255), models (like RGB, YUV, HSV and others). Any sugestions or needs?
Adam Badura
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Adam, For some idea of useful color functionality in the OpenGL context: GltColor C++ class for RGB color representation http://www.nigels.com/glt/doc/class_glt_color.html Open Scene Graph RGBA color representation http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/clas... OpenGL pixel image formats and types http://developer.3dlabs.com/documents/GLmanpages/glreadpixels.htm Qt QColor class for GUI color representation http://doc.trolltech.com/3.3/qcolor.html Wish list: * Flexible representation RGB, RGBA, YUV, HSV and conversions between * Machine level-representation RGBA, BGRA, etc * Conversion to and from HTML std::string #rrggbb * Interpolating between colors in various color spaces (HSV is cylindrical!) * Named colors: boost::black, boost::white, etc * Operations such as brighten, darken, gamma adjustment, etc Suggestions: * Leave image processing out of scope, image processing could layer on top. Cheers, Nigel Stewart
It should maybe also support the CIE's L*a*b* and XYZ models as well as require discretized color values to be specified in terms of a color space so as to avoid ambiguity. Adam Badura wrote:
Upsss... I pressed "send" to fast... :)
I am gathering materials and working on a library (originaly I wanted one class, but it seems now that it wont be that easy) dealing with colors, their representation (like ranges 0.0-1.0 and 0-255), models (like RGB, YUV, HSV and others). Any sugestions or needs?
Adam Badura
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
...
I am gathering materials and working on a library (originaly I wanted one class, but it seems now that it wont be that easy) dealing with colors, their representation (like ranges 0.0-1.0 and 0-255), models (like RGB, YUV, HSV and others). Any sugestions or needs?
Some people might be interested in a capability to map image colors to color separation values usable in printing. -- Alec Ross
I would be much interested. Here are my needs. I need converting from compressed (with compressed formats I mean downsampled formats such as YUV 4:2:2) to uncompressed formats, or viceversa. The uncompressed formats I use are BW, RGB, BGR, YUV, with or without alpha channel. In the uncompressed formats I need to store color s as 8 bit unsigned (0-255), 16 bits signed or unsigned, or float (0.0-1.0). The compressed formats I use (or would like to use) are YUYV, UYVY, I420 (planar), and YV12 (planar), RGB555 (16bit), RGB565 (16bit). Other formats needed are D3DFMT_A2R10G10B10 and D3DFMT_A2B10G10R10 (DirectX formats, 10 bits for each color and 2 bits for alpha). I'd like to be able to work on images from other libraries (in particular Intel IPP or OpenCV). In some cases I'd like to be able to work inplace (when the image size does not change, e.g. RGB => YUV or RGB=>BGR). The non inplace case should be always available. Finally, I'd like to be able to convert from compressed to compressed formats without having to through the "nearest" uncompressed one (which is what I have to do now using Intel IPP). E.g., I'd like to be able to convert directly from YUYV to RGB555 (same for all other possible combinations). Paolo Coletta Adam Badura wrote:
Upsss... I pressed "send" to fast... :)
I am gathering materials and working on a library (originaly I wanted one class, but it seems now that it wont be that easy) dealing with colors, their representation (like ranges 0.0-1.0 and 0-255), models (like RGB, YUV, HSV and others). Any sugestions or needs?
Adam Badura
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Adam Badura" <abadura@o2.pl> wrote in message news:dgbkob$ssq$1@sea.gmane.org...
Upsss... I pressed "send" to fast... :)
I am gathering materials and working on a library (originaly I wanted one class, but it seems now that it wont be that easy) dealing with colors, their representation (like ranges 0.0-1.0 and 0-255), models (like RGB, YUV, HSV and others). Any sugestions or needs?
FWIW In programming I have only ever used the RGB ones. color<T>(T r,T g, T b); where T is float or int8, int16,int32 etc. I believe these are in use in eg VRML, HTML/CSS, SVG, XWindows etc.. I know that in VRML the transparency attribute in (RGBA) is used but in some cases is separate from the RGB information (e.g Material node), so it might be worth keeping the distinction between a color and a colour with transparency. As far as the other color types go... Can they be converted to or from RGB / RGBA without loss of information?. (I think most of them can). If so then obviously they are equivalent., however my inclination would be to concentrate on the RGB types rather than the others because of their wide use in the above standards/specifications. (unless you can find compelling evidence for similar use of any of the others mentioned in langauge specifications, though I suspect that they are more hardware than software oriented) FWIW Some interesting information regarding color at : http://www.iec.ch/zone/colourmgmt/cm_entry.htm regards Andy Little
As I rewrite some parts of code for color library I noticed silent assumption I made. Namely I assumed that all color components are the same type. But must it be this way? Does anyone use types like: struct rgb { float r; unsigned char b; signed char g; }; I think adding such a feature (enabling use of such components) will not be hard, but it will make code a littl longer (but as fast in execution) and harder to maintain. Also writing own component class would be a little bit longer (for those who use all components of the same type). However I plann to make ready implementations for common component models. I know thet soem types can be simulated by others. For example: struct rgb { usnigned int r : 16; unsigned int b : 8; unsigned int g : 8; }; all components have here the same type even if "r" and "g" could really use "unsigned char". But when there is difference signed/usnigned or integer/float nothing (as I think) can be done. So? Allow diffrent types or not? Adam Badura
Adam Badura wrote:
As I rewrite some parts of code for color library I noticed silent assumption I made. Namely I assumed that all color components are the same type. But must it be this way? Does anyone use types like:
struct rgb { float r; unsigned char b; signed char g; };
<snip>
So? Allow diffrent types or not?
Although it wouldn't be terribly useful for RGB, other representations may (will?) benifit from this, as a simple example, L*a*b* is represented as an /unsigned/ Lightness, and two /signed/ components, a and b. Someone may wish to represent (or is forced to represent) HSV values with floating Hue, but integral Saturation and Value. Perhaps a specialised graphics application would wish to use (custom?) fixed point types and floating point types in the same value (If consistancy of calculations for Saturation and Value are needed, but accuracy is more important for Hue, for example) In short, I say yea!
But this in deed does have some disadvantages. Previous I had functions like component_type component(const int index) const; component_type& component(const int index); or simple [] operator for getting components. This allows to easy write code which preforms the same operation on each color component (for example interpolates color by interpolating R than G than B...). Now (when components could have different types) writing such a function is almost impossible because you must return one specific type (inheritance is imposibble due to speed overhead and use of basic types). You can still write somethink like this union types { red_type red; green_type green; blue_type blue; }; types component(const int index) const; void component(const int index, const types value); but also this would produce worse (in readablity) code becouse instead of color.component(0) = 128; you will have to write color.component(0).red = 128; which is not intuitiv (someone not knownin library would by puzzeld by 0 in argument if you specify "red"). Not mentioning lack of safty and eleganc caused by unions... So to sum up I am considarating whether to add feature of different types or at least in RGB which as I think, is not used in this way, besause this feature has to high cost. Adam Badura
Adam Badura wrote:
As I rewrite some parts of code for color library I noticed silent assumption I made. Namely I assumed that all color components are the
same
type. But must it be this way? Does anyone use types like:
struct rgb { float r; unsigned char b; signed char g; }; <snip> So? Allow diffrent types or not? Although it wouldn't be terribly useful for RGB, other representations may (will?) benifit from this, as a simple example, L*a*b* is represented as an /unsigned/ Lightness, and two /signed/ components, a and b. Someone may wish to represent (or is forced to represent) HSV values with floating Hue, but integral Saturation and Value. Perhaps a specialised graphics application would wish to use (custom?) fixed point types and floating point types in the same value (If consistancy of calculations for Saturation and Value are needed, but accuracy is more important for Hue, for example) In short, I say yea!
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 9/27/05, Adam Badura <abadura@o2.pl> wrote:
But this in deed does have some disadvantages. Previous I had functions like
component_type component(const int index) const; component_type& component(const int index);
or simple [] operator for getting components. This allows to easy write code which preforms the same operation on each color component (for example interpolates color by interpolating R than G than B...). Now (when components could have different types) writing such a function is almost impossible because you must return one specific type (inheritance is imposibble due to speed overhead and use of basic types).
I don't see this as a big loss. It's still easy to write code which does the same thing to each component, you just have to do it explicitly with three separate calls instead of a loop. I don't think you should be restricting the functionality of the library this much (since it sounds like components with different types will be a relatively common case) just to avoid the minor inconvenience of not being able to be generic over components. In any event, the color models in which it makes sense to have different types for the different components are probably models in which it doesn't make sense to perform the same operation on all three components. Performing the exact same operation on all three components only really makes sense in RGB, CYM, and their close relatives, which model colors as mixtures of semi-arbitrary primaries; it's not something you're likely to want to do in HSV, LAB, etc, where the different components are conceptually distinct concepts. So, it seems like an ideal design would be to allow color classes to specialize depending on whether their components are in some sense equivalent. Those that are could offer a component() method, and would require the same type for all 3 components. Those that aren't would not offer a component() method, and consequently would have the freedom to use different types for the different components.
So, it seems like an ideal design would be to allow color classes to specialize depending on whether their components are in some sense equivalent. Those that are could offer a component() method, and would require the same type for all 3 components. Those that aren't would not offer a component() method, and consequently would have the freedom to use different types for the different components.
Yes. Indeed. I heard of looping over RGB components but never heared of RGB representations with different types (even size is usually the same). So I thought to disallow different types for RGB (and CMYK probably also) and to allow this where it is realy suitable. Its no problem to wrtie classes thet serv "red", "green" and "blue" instead of "component". But giving both solutions for RGB for example would require (in my opinion) ~double code. I think that large parts of code would have to be writen once for "generic" (component()) and once for "not generic". This would probably be realized by a specialization of color_rgb (model) class for components that suport component and those which do not. But because I dont wand to use any inhertiance to be maxiamly sure about memory representation and speed I would have to write to separate (but giving athe same functions) implementations. So I'm not quite sure if its worth in case of RGB. Or do you have any proposal of easy solution? Adam Badura
Adam Badura wrote:
So, it seems like an ideal design would be to allow color classes to specialize depending on whether their components are in some sense equivalent. Those that are could offer a component() method, and would require the same type for all 3 components. Those that aren't would not offer a component() method, and consequently would have the freedom to use different types for the different components.
Yes. Indeed. I heard of looping over RGB components but never heared of RGB representations with different types (even size is usually the same). So I thought to disallow different types for RGB (and CMYK probably also) and to allow this where it is realy suitable. Its no problem to wrtie classes thet serv "red", "green" and "blue" instead of "component". But giving both solutions for RGB for example would require (in my opinion) ~double code. I think that large parts of code would have to be writen once for "generic" (component()) and once for "not generic". This would probably be realized by a specialization of color_rgb (model) class for components that suport component and those which do not. But because I dont wand to use any inhertiance to be maxiamly sure about memory representation and speed I would have to write to separate (but giving athe same functions) implementations. So I'm not quite sure if its worth in case of RGB. Or do you have any proposal of easy solution?
Could I just ask if something like: for(int i = 0; i < 3; ++i) if(col[i]*1.2 < col.max) col[i] *= 1.2; else col[i] = col.max; is what you mean? Something like this is the only time doing something to every component over a loop makes sense to me (simpler ops could be applied directly to the colour), and here you can just assume that the colour ops are by default clipping (since that makes sense). therefore: col *= 1.2; is equivalent. Presumably, there would be non-clipping colours as well?
Could I just ask if something like:
for(int i = 0; i < 3; ++i) if(col[i]*1.2 < col.max) col[i] *= 1.2; else col[i] = col.max;
is what you mean? Something like this is the only time doing something to every component over a loop makes sense to me (simpler ops could be applied directly to the colour), and here you can just assume that the colour ops are by default clipping (since that makes sense).
therefore: col *= 1.2; is equivalent.
Presumably, there would be non-clipping colours as well?
Yes. I thought about something like this. But there is a lot of work (for example interpolating) which is the same for each component. Naturally you can write thre pices of code for each component, but it is simpler, nicer and safer to have only one code... I want to include clipping. In fact I am considerating 3 versions of this type operations. One would give exception if value out of range (for debug), one wich would clip (to eas some parts of code in which this is needed) and on which does nothing (for speed when operation is certain to be OK). But i still am thinkig how to do it to allow additionaly to easy change betwean kinds of calls (when changing from debug to release). Actually the best from what i thought is 3 functions for example "component" (clear), "component_e" (exception), "component_c" (clip). But perhabs some good solution may be found using templates... Adam Badura
So, is any code written for this? Raw code is easier to critique, even if it's just proof-of-concept stuff. Of course, I'd be happy to do some work for this, if we ever agree what to do :D
Umm.. what are you refering to? On 9/28/05, Simon Buchan <simon@hand-multimedia.co.nz> wrote:
So, is any code written for this? Raw code is easier to critique, even if it's just proof-of-concept stuff. Of course, I'd be happy to do some work for this, if we ever agree what to do :D
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Cory Nelson http://www.int64.org
Cory Nelson wrote:
Umm.. what are you refering to?
On 9/28/05, Simon Buchan <simon@hand-multimedia.co.nz> wrote:
So, is any code written for this? Raw code is easier to critique, even if it's just proof-of-concept stuff. Of course, I'd be happy to do some work for this, if we ever agree what to do :D
The topic above? With all those responses about small details of a (presumably) unwritten library?
A: Because it's hard to read Q: Why shouldn't I reply above a message?
Simon Buchan wrote:
Cory Nelson wrote:
Umm.. what are you refering to?
On 9/28/05, Simon Buchan <simon@hand-multimedia.co.nz> wrote:
So, is any code written for this? Raw code is easier to critique, even if it's just proof-of-concept stuff. Of course, I'd be happy to do some work for this, if we ever agree what to do :D
The topic above? With all those responses about small details of a (presumably) unwritten library?
A: Because it's hard to read Q: Why shouldn't I reply above a message?
Because you removed all traces on the subject and in the content to give others any idea of what you are talking about. This is an email forum and many people don't see the thread context, and hence can't tell that you replied to a particular message. Next time it would be wise to include some context if you want to increase the likelihood of sensible responses. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Rene Rivera wrote:
Simon Buchan wrote:
Cory Nelson wrote:
Umm.. what are you refering to?
On 9/28/05, Simon Buchan <simon@hand-multimedia.co.nz> wrote:
So, is any code written for this? Raw code is easier to critique, even if it's just proof-of-concept stuff. Of course, I'd be happy to do some work for this, if we ever agree what to do :D
The topic above? With all those responses about small details of a (presumably) unwritten library?
A: Because it's hard to read Q: Why shouldn't I reply above a message?
Because you removed all traces on the subject and in the content to give others any idea of what you are talking about. This is an email forum and many people don't see the thread context, and hence can't tell that you replied to a particular message. Next time it would be wise to include some context if you want to increase the likelihood of sensible responses.
Right. I didn't realise that this was how threadless views did this. Sorry, won't happen again. Since I replied to the initial colour lib (since it wasn't related to the rest of the discussion), and it was empty by a OP mistake, I didn't have anything to quote. So, more on topic: is an actual implementation of the proposed color lib in development? ie. is there any code that I can compile and take a look at the decisions being made in context?
So, more on topic: is an actual implementation of the proposed color lib in development? ie. is there any code that I can compile and take a look at the decisions being made in context?
Yes. When you posted I just started 3rd version of my code (I had to rewrite to include ability of differet types). Now I just want to add a few functions and write one or to exemple codes and some brief description. I hoped I would manage yesterday but as you see I didn/y but this gives big chance that I will post code today.... Adam Badura
So, more on topic: is an actual implementation of the proposed color lib in development? ie. is there any code that I can compile and take a look at the decisions being made in context?
I have included only one example (rather simple just to check if everything compiles) because you were hurrying me so much... :) I compiled on Microsoft Visual C++ Toolkit 2003 and Borland C++ 5.5 both compiled without errors. So what do the files containt? Almost everything is in color.hpp because almost everything is template or inline. Now only RGB model is implemented - I wanted to get clear idea what to do and how do it. Then write CMYK or YUV (they should be almost the same) and project conversions. Then write the rest. Actual project looks like this: 1) We have classes for color data representations (in color.hpp components_rgb, components_32b, components_32b_inv). They are responsible for storing and serving "raw" data. This is done because for a color class (see 3) it does not matter wheather color components have all 8 or 16 bits or how are they placed in memory. Color class (see 3) must know only some details given in components_traits (see 2). Color representation class must serve 6 functions: TYPE_OF_R r() const; // return R value void r(TYPE_OF_R value); // set R value TYPE_OF_G g() const; // return G value void g(TYPE_OF_G value); // set G value TYPE_OF_B b() const; // return B value void b(TYPE_OF_B value); // set B value They should be as fast as only possible. No error checking - color class (see 3) will do it when needed. Also a copy constructor and copy operator should be available but this usually is no problem because default compiler generated one will do. All this is introduced to allow use of library with other libraries (DirectX, OpenGL, native WinAPI, ...) and formats of color storing. I declared all this classes actually as structures to emphasise on importance of memory model. This classes have to be allocated in memory exactyl as they have data memers to allow worinkg with buffers for and from other devices and libraries. 2) We have template class components_traits which has to be specialized for every representation class (see 1). It serves basic static data of the component: typedef TYPE_OF_R r_type; typedef TYPE_OF_G g_type; typedef TYPE_OF_B b_type; static const r_type r_min; static const r_type r_max; static const g_type g_min; static const g_type g_max; static const b_type b_min; static const b_type b_max; this is used be color class (see 3) in conversions correcting values and defining interface. r_type, g_type and b_type must be convertable to long double and must construct from long double. This is no problem in case of standard types. And because this types must (or at least should to be functional) behave like number so requirement is quite natural... 3) We have color class. It is parametrized by representation class (see 1) and its traits (see 2). This class gives 2 way access to color data. First one is unified by type long double. Components are of type long double in range [0; 1]. Actually the can be in any representation but they color class takes care of conversion to long double. Conversion form long double to actual representation is done by the representation (by the type of component) so kind of rounding is determined there and in usual case it will be rounding to nearest representable color (or it should be like this). This is added to allow writing of generic functions taht do not care about actual representation and its limits. But it should be remembered that this is not the fastes access (aspecially in writng) because it requires conversions and mathematical operations. Second is by actual component type (all functions postfixed with _o). This is as fast as possible but not as generic... All (write) functions come in few versions. Version without postfix makes no error chcecking (to be used in releas version of program to make it faster). Version ending in _c corrects values. If value given for component is smaller the minimum for that component minimum is writen instead, if value is larger then maximum then maximum is writen instead. This is aspecially useful for generic functions because rounding in floating point operations can actually take value beyond accepted range. Version ending in _e throws an exception when component value is out of range (or when component is out of range see further remarks). This is intended to be used in debuging application and then in release to replace by non-checking calls. I writed an indexed function where index 0 gives (or sets) R, 1 is for G and 2 is for B. But they only are available in long double version because actual component tpyes me be different. So I think its all by now. What do I want to do futher? 1) add "nice features" like functions "darker", "brighter" and so on... 2) add comparing with or without "toleration range" (colors [0.00000001, 0.0, 0.0] and [0.0, 0.0, 0.0] really do not differ that much aspecially converted to integer based representation... 3) add and test useful representations 4) add reading and writing form a string and all web-color as predefined, but this will I do perhabs after completting everything else (actually there is an << operator defined but only to ease testing) 5) add other models and convertions betwean them So what you think? Adam Badura begin 666 functions.cpp M(VEN8VQU9&4@(F-O;&]R+FAP<"(-"B-I;F-L=61E(#QE>&-E<'1I;VX^#0HC M:6YC;'5D92 \:6]S=')E86T^#0H-"@T*=7-I;F<@;F%M97-P86-E(&)O;W-T M.CIC;VQO<CHZ<F=B.PT*=7-I;F<@;F%M97-P86-E('-T9#L-"@T*#0IT96UP M;&%T93P^('-T9#HZ;W-T<F5A;28@8F]O<W0Z.F-O;&]R.CIR9V(Z.F]P97)A M=&]R(#P\*'-T9#HZ;W-T<F5A;28@<W1R96%M+"!C;VYS="!C;VQO<CQC;VUP M;VYE;G1S7W)G8CQU;G-I9VYE9"!C:&%R/BP@8V]M<&]N96YT<U]T<F%I=',\ M8V]M<&]N96YT<U]R9V(\=6YS:6=N960@8VAA<CX@/B ^(&,I('L-"@ER971U M<FX@<W1R96%M(#P\(")21T(Z6R(@/#P@<W1A=&EC7V-A<W0\:6YT/BAC+G)? M;R@I*2 \/" B.R B(#P\('-T871I8U]C87-T/&EN=#XH8RYG7V\H*2D@/#P@ M(CL@(B \/"!S=&%T:6-?8V%S=#QI;G0^*&,N8E]O*"DI(#P\(")=(CL-"GT- M"@T*#0II;G0@;6%I;B@I('L-"@EC;W5T(#P\(")497-T:6YG(&)O;W-T.CIC M;VQO<CHZ<F=B.CIC;VQO<CPB(#P\(&5N9&P@/#P@(B!B;V]S=#HZ8V]L;W(Z M.G)G8CHZ8V]M<&]N96YT<U]R9V(\;&]N9R!D;W5B;&4^+"(@/#P@96YD;" \ M/" B(&)O;W-T.CIC;VQO<CHZ<F=B.CIC;VUP;VYE;G1S7W1R86ET<SQB;V]S M=#HZ8V]L;W(Z.G)G8CHZ8V]M<&]N96YT<U]R9V(\;&]N9R!D;W5B;&4^(#XB M(#P\(&5N9&P@/#P@)SXG(#P\(&5N9&P[#0H)=')Y('L-"@D)8V]L;W(\8V]M M<&]N96YT<U]R9V(\;&]N9R!D;W5B;&4^+"!C;VUP;VYE;G1S7W1R86ET<SQC M;VUP;VYE;G1S7W)G8CQL;VYG(&1O=6)L93X@/B ^(&,[#0H)"6-O=70@/#P@ M8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8V]M<&]N96YT<R@P M+C0L(# N-"P@,"XT*2(@/#P@96YD;#L-"@D)8RYC;VUP;VYE;G1S*# N-"P@ M,"XT+" P+C0I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B M7'1D;VEN9R!C+F-O;7!O;F5N='-?8R@P+C4L(# N-2P@,"XU*2(@/#P@96YD M;#L-"@D)8RYC;VUP;VYE;G1S7V,H,"XU+" P+C4L(# N-2D[#0H)"6-O=70@ M/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8V]M<&]N96YT M<U]E*# N-BP@,"XV+" P+C8I(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N='-? M92@P+C8L(# N-BP@,"XV*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)?2!C M871C:"AC;VYS="!E>&-E<'1I;VXF(&4I('L-"@D)8V5R<B \/" B15A#15!4 M24]..B B(#P\(&4N=VAA="@I(#P\(&5N9&P[#0H)?0T*"71R>2![#0H)"6-O M;&]R/&-O;7!O;F5N='-?<F=B/&QO;F<@9&]U8FQE/BP@8V]M<&]N96YT<U]T M<F%I=',\8V]M<&]N96YT<U]R9V(\;&]N9R!D;W5B;&4^(#X@/B!C.PT*"0EC M;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+F-O;7!O M;F5N=',H,2XT+" Q+C0L(#$N-"DB(#P\(&5N9&P[#0H)"6,N8V]M<&]N96YT M<R@Q+C0L(#$N-"P@,2XT*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O M=70@/#P@(EQT9&]I;F<@8RYC;VUP;VYE;G1S7V,H,2XU+" Q+C4L(#$N-2DB M(#P\(&5N9&P[#0H)"6,N8V]M<&]N96YT<U]C*#$N-2P@,2XU+" Q+C4I.PT* M"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+F-O M;7!O;F5N='-?92@Q+C8L(#$N-BP@,2XV*2(@/#P@96YD;#L-"@D)8RYC;VUP M;VYE;G1S7V4H,2XV+" Q+C8L(#$N-BD[#0H)"6-O=70@/#P@8R \/"!E;F1L M.PT*"7T@8V%T8V@H8V]N<W0@97AC97!T:6]N)B!E*2![#0H)"6-E<G(@/#P@ M(D580T505$E/3CH@(B \/"!E+G=H870H*2 \/"!E;F1L.PT*"7T-"@ET<GD@ M>PT*"0EC;VQO<CQC;VUP;VYE;G1S7W)G8CQL;VYG(&1O=6)L93XL(&-O;7!O M;F5N='-?=')A:71S/&-O;7!O;F5N='-?<F=B/&QO;F<@9&]U8FQE/B ^(#X@ M8SL-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@ M8RYC;VUP;VYE;G1S*"TP+C0L("TP+C0L("TP+C0I(B \/"!E;F1L.PT*"0EC M+F-O;7!O;F5N=',H+3 N-"P@+3 N-"P@+3 N-"D[#0H)"6-O=70@/#P@8R \ M/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8V]M<&]N96YT<U]C*"TP M+C4L("TP+C4L("TP+C4I(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N='-?8R@M M,"XU+" M,"XU+" M,"XU*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O M=70@/#P@(EQT9&]I;F<@8RYC;VUP;VYE;G1S7V4H+3 N-BP@+3 N-BP@+3 N M-BDB(#P\(&5N9&P[#0H)"6,N8V]M<&]N96YT<U]E*"TP+C8L("TP+C8L("TP M+C8I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@E](&-A=&-H*&-O;G-T(&5X M8V5P=&EO;B8@92D@>PT*"0EC97)R(#P\(")%6$-%4%1)3TXZ("(@/#P@92YW M:&%T*"D@/#P@96YD;#L-"@E]#0H)=')Y('L-"@D)8V]L;W(\8V]M<&]N96YT M<U]R9V(\;&]N9R!D;W5B;&4^+"!C;VUP;VYE;G1S7W1R86ET<SQC;VUP;VYE M;G1S7W)G8CQL;VYG(&1O=6)L93X@/B ^(&,[#0H)"6-O=70@/#P@8R \/"!E M;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N<B@P+C0I(B \/"!E;F1L.PT* M"0EC+G(H,"XT*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@ M(EQT9&]I;F<@8RYR7V,H,"XU*2(@/#P@96YD;#L-"@D)8RYR7V,H,"XU*3L- M"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYR M7V4H,"XV*2(@/#P@96YD;#L-"@D)8RYR7V4H,"XV*3L-"@D)8V]U=" \/"!C M(#P\(&5N9&P[#0H)?2!C871C:"AC;VYS="!E>&-E<'1I;VXF(&4I('L-"@D) M8V5R<B \/" B15A#15!424]..B B(#P\(&4N=VAA="@I(#P\(&5N9&P[#0H) M?0T*"71R>2![#0H)"6-O;&]R/&-O;7!O;F5N='-?<F=B/&QO;F<@9&]U8FQE M/BP@8V]M<&]N96YT<U]T<F%I=',\8V]M<&]N96YT<U]R9V(\;&]N9R!D;W5B M;&4^(#X@/B!C.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B M7'1D;VEN9R!C+G(H,2XT*2(@/#P@96YD;#L-"@D)8RYR*#$N-"D[#0H)"6-O M=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N<E]C*#$N M-2DB(#P\(&5N9&P[#0H)"6,N<E]C*#$N-2D[#0H)"6-O=70@/#P@8R \/"!E M;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N<E]E*#$N-BDB(#P\(&5N9&P[ M#0H)"6,N<E]E*#$N-BD[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"7T@8V%T M8V@H8V]N<W0@97AC97!T:6]N)B!E*2![#0H)"6-E<G(@/#P@(D580T505$E/ M3CH@(B \/"!E+G=H870H*2 \/"!E;F1L.PT*"7T-"@ET<GD@>PT*"0EC;VQO M<CQC;VUP;VYE;G1S7W)G8CQL;VYG(&1O=6)L93XL(&-O;7!O;F5N='-?=')A M:71S/&-O;7!O;F5N='-?<F=B/&QO;F<@9&]U8FQE/B ^(#X@8SL-"@D)8V]U M=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYR*"TP+C0I M(B \/"!E;F1L.PT*"0EC+G(H+3 N-"D[#0H)"6-O=70@/#P@8R \/"!E;F1L M.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N<E]C*"TP+C4I(B \/"!E;F1L.PT* M"0EC+G)?8R@M,"XU*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@ M/#P@(EQT9&]I;F<@8RYR7V4H+3 N-BDB(#P\(&5N9&P[#0H)"6,N<E]E*"TP M+C8I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@E](&-A=&-H*&-O;G-T(&5X M8V5P=&EO;B8@92D@>PT*"0EC97)R(#P\(")%6$-%4%1)3TXZ("(@/#P@92YW M:&%T*"D@/#P@96YD;#L-"@E]#0H)=')Y('L-"@D)8V]L;W(\8V]M<&]N96YT M<U]R9V(\;&]N9R!D;W5B;&4^+"!C;VUP;VYE;G1S7W1R86ET<SQC;VUP;VYE M;G1S7W)G8CQL;VYG(&1O=6)L93X@/B ^(&,[#0H)"6-O=70@/#P@8R \/"!E M;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N9R@P+C0I(B \/"!E;F1L.PT* M"0EC+F<H,"XT*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@ M(EQT9&]I;F<@8RYG7V,H,"XU*2(@/#P@96YD;#L-"@D)8RYG7V,H,"XU*3L- M"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYG M7V4H,"XV*2(@/#P@96YD;#L-"@D)8RYG7V4H,"XV*3L-"@D)8V]U=" \/"!C M(#P\(&5N9&P[#0H)?2!C871C:"AC;VYS="!E>&-E<'1I;VXF(&4I('L-"@D) M8V5R<B \/" B15A#15!424]..B B(#P\(&4N=VAA="@I(#P\(&5N9&P[#0H) M?0T*"71R>2![#0H)"6-O;&]R/&-O;7!O;F5N='-?<F=B/&QO;F<@9&]U8FQE M/BP@8V]M<&]N96YT<U]T<F%I=',\8V]M<&]N96YT<U]R9V(\;&]N9R!D;W5B M;&4^(#X@/B!C.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B M7'1D;VEN9R!C+F<H,2XT*2(@/#P@96YD;#L-"@D)8RYG*#$N-"D[#0H)"6-O M=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N9U]C*#$N M-2DB(#P\(&5N9&P[#0H)"6,N9U]C*#$N-2D[#0H)"6-O=70@/#P@8R \/"!E M;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N9U]E*#$N-BDB(#P\(&5N9&P[ M#0H)"6,N9U]E*#$N-BD[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"7T@8V%T M8V@H8V]N<W0@97AC97!T:6]N)B!E*2![#0H)"6-E<G(@/#P@(D580T505$E/ M3CH@(B \/"!E+G=H870H*2 \/"!E;F1L.PT*"7T-"@ET<GD@>PT*"0EC;VQO M<CQC;VUP;VYE;G1S7W)G8CQL;VYG(&1O=6)L93XL(&-O;7!O;F5N='-?=')A M:71S/&-O;7!O;F5N='-?<F=B/&QO;F<@9&]U8FQE/B ^(#X@8SL-"@D)8V]U M=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYG*"TP+C0I M(B \/"!E;F1L.PT*"0EC+F<H+3 N-"D[#0H)"6-O=70@/#P@8R \/"!E;F1L M.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N9U]C*"TP+C4I(B \/"!E;F1L.PT* M"0EC+F=?8R@M,"XU*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@ M/#P@(EQT9&]I;F<@8RYG7V4H+3 N-BDB(#P\(&5N9&P[#0H)"6,N9U]E*"TP M+C8I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@E](&-A=&-H*&-O;G-T(&5X M8V5P=&EO;B8@92D@>PT*"0EC97)R(#P\(")%6$-%4%1)3TXZ("(@/#P@92YW M:&%T*"D@/#P@96YD;#L-"@E]#0H)=')Y('L-"@D)8V]L;W(\8V]M<&]N96YT M<U]R9V(\;&]N9R!D;W5B;&4^+"!C;VUP;VYE;G1S7W1R86ET<SQC;VUP;VYE M;G1S7W)G8CQL;VYG(&1O=6)L93X@/B ^(&,[#0H)"6-O=70@/#P@8R \/"!E M;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8B@P+C0I(B \/"!E;F1L.PT* M"0EC+F(H,"XT*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@ M(EQT9&]I;F<@8RYB7V,H,"XU*2(@/#P@96YD;#L-"@D)8RYB7V,H,"XU*3L- M"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYB M7V4H,"XV*2(@/#P@96YD;#L-"@D)8RYB7V4H,"XV*3L-"@D)8V]U=" \/"!C M(#P\(&5N9&P[#0H)?2!C871C:"AC;VYS="!E>&-E<'1I;VXF(&4I('L-"@D) M8V5R<B \/" B15A#15!424]..B B(#P\(&4N=VAA="@I(#P\(&5N9&P[#0H) M?0T*"71R>2![#0H)"6-O;&]R/&-O;7!O;F5N='-?<F=B/&QO;F<@9&]U8FQE M/BP@8V]M<&]N96YT<U]T<F%I=',\8V]M<&]N96YT<U]R9V(\;&]N9R!D;W5B M;&4^(#X@/B!C.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B M7'1D;VEN9R!C+F(H,2XT*2(@/#P@96YD;#L-"@D)8RYB*#$N-"D[#0H)"6-O M=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8E]C*#$N M-2DB(#P\(&5N9&P[#0H)"6,N8E]C*#$N-2D[#0H)"6-O=70@/#P@8R \/"!E M;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8E]E*#$N-BDB(#P\(&5N9&P[ M#0H)"6,N8E]E*#$N-BD[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"7T@8V%T M8V@H8V]N<W0@97AC97!T:6]N)B!E*2![#0H)"6-E<G(@/#P@(D580T505$E/ M3CH@(B \/"!E+G=H870H*2 \/"!E;F1L.PT*"7T-"@ET<GD@>PT*"0EC;VQO M<CQC;VUP;VYE;G1S7W)G8CQL;VYG(&1O=6)L93XL(&-O;7!O;F5N='-?=')A M:71S/&-O;7!O;F5N='-?<F=B/&QO;F<@9&]U8FQE/B ^(#X@8SL-"@D)8V]U M=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYB*"TP+C0I M(B \/"!E;F1L.PT*"0EC+F(H+3 N-"D[#0H)"6-O=70@/#P@8R \/"!E;F1L M.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8E]C*"TP+C4I(B \/"!E;F1L.PT* M"0EC+F)?8R@M,"XU*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@ M/#P@(EQT9&]I;F<@8RYB7V4H+3 N-BDB(#P\(&5N9&P[#0H)"6,N8E]E*"TP M+C8I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@E](&-A=&-H*&-O;G-T(&5X M8V5P=&EO;B8@92D@>PT*"0EC97)R(#P\(")%6$-%4%1)3TXZ("(@/#P@92YW M:&%T*"D@/#P@96YD;#L-"@E]#0H)=')Y('L-"@D)8V]L;W(\8V]M<&]N96YT M<U]R9V(\;&]N9R!D;W5B;&4^+"!C;VUP;VYE;G1S7W1R86ET<SQC;VUP;VYE M;G1S7W)G8CQL;VYG(&1O=6)L93X@/B ^(&,[#0H)"6-O=70@/#P@8R \/"!E M;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8V]M<&]N96YT*# L(# N-"DB M(#P\(&5N9&P[#0H)"6,N8V]M<&]N96YT*# L(# N-"D[#0H)"6-O=70@/#P@ M8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8V]M<&]N96YT7V,H M,"P@,"XU*2(@/#P@96YD;#L-"@D)8RYC;VUP;VYE;G1?8R@P+" P+C4I.PT* M"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+F-O M;7!O;F5N=%]C92@P+" P+C8I(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N=%]C M92@P+" P+C8I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B M7'1D;VEN9R!C+F-O;7!O;F5N=%]E*# L(# N-RDB(#P\(&5N9&P[#0H)"6,N M8V]M<&]N96YT7V4H,"P@,"XW*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H) M?2!C871C:"AC;VYS="!E>&-E<'1I;VXF(&4I('L-"@D)8V5R<B \/" B15A# M15!424]..B B(#P\(&4N=VAA="@I(#P\(&5N9&P[#0H)?0T*"71R>2![#0H) M"6-O;&]R/&-O;7!O;F5N='-?<F=B/&QO;F<@9&]U8FQE/BP@8V]M<&]N96YT M<U]T<F%I=',\8V]M<&]N96YT<U]R9V(\;&]N9R!D;W5B;&4^(#X@/B!C.PT* M"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+F-O M;7!O;F5N="@P+" Q+C0I(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N="@P+" Q M+C0I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN M9R!C+F-O;7!O;F5N=%]C*# L(#$N-2DB(#P\(&5N9&P[#0H)"6,N8V]M<&]N M96YT7V,H,"P@,2XU*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@ M/#P@(EQT9&]I;F<@8RYC;VUP;VYE;G1?8V4H,"P@,2XV*2(@/#P@96YD;#L- M"@D)8RYC;VUP;VYE;G1?8V4H,"P@,2XV*3L-"@D)8V]U=" \/"!C(#P\(&5N M9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYC;VUP;VYE;G1?92@P+" Q+C<I M(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N=%]E*# L(#$N-RD[#0H)"6-O=70@ M/#P@8R \/"!E;F1L.PT*"7T@8V%T8V@H8V]N<W0@97AC97!T:6]N)B!E*2![ M#0H)"6-E<G(@/#P@(D580T505$E/3CH@(B \/"!E+G=H870H*2 \/"!E;F1L M.PT*"7T-"@ET<GD@>PT*"0EC;VQO<CQC;VUP;VYE;G1S7W)G8CQL;VYG(&1O M=6)L93XL(&-O;7!O;F5N='-?=')A:71S/&-O;7!O;F5N='-?<F=B/&QO;F<@ M9&]U8FQE/B ^(#X@8SL-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@ M/#P@(EQT9&]I;F<@8RYC;VUP;VYE;G0H,"P@+3 N-"DB(#P\(&5N9&P[#0H) M"6,N8V]M<&]N96YT*# L("TP+C0I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L- M"@D)8V]U=" \/" B7'1D;VEN9R!C+F-O;7!O;F5N=%]C*# L("TP+C4I(B \ M/"!E;F1L.PT*"0EC+F-O;7!O;F5N=%]C*# L("TP+C4I.PT*"0EC;W5T(#P\ M(&,@/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+F-O;7!O;F5N=%]C M92@P+" M,"XV*2(@/#P@96YD;#L-"@D)8RYC;VUP;VYE;G1?8V4H,"P@+3 N M-BD[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG M(&,N8V]M<&]N96YT7V4H,"P@+3 N-RDB(#P\(&5N9&P[#0H)"6,N8V]M<&]N M96YT7V4H,"P@+3 N-RD[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"7T@8V%T M8V@H8V]N<W0@97AC97!T:6]N)B!E*2![#0H)"6-E<G(@/#P@(D580T505$E/ M3CH@(B \/"!E+G=H870H*2 \/"!E;F1L.PT*"7T-"@ET<GD@>PT*"0EC;VQO M<CQC;VUP;VYE;G1S7W)G8CQL;VYG(&1O=6)L93XL(&-O;7!O;F5N='-?=')A M:71S/&-O;7!O;F5N='-?<F=B/&QO;F<@9&]U8FQE/B ^(#X@8SL-"@D)8V]U M=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYC;VUP;VYE M;G0H,2P@,"XT*2(@/#P@96YD;#L-"@D)8RYC;VUP;VYE;G0H,2P@,"XT*3L- M"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYC M;VUP;VYE;G1?8R@Q+" P+C4I(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N=%]C M*#$L(# N-2D[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")< M=&1O:6YG(&,N8V]M<&]N96YT7V-E*#$L(# N-BDB(#P\(&5N9&P[#0H)"6,N M8V]M<&]N96YT7V-E*#$L(# N-BD[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT* M"0EC;W5T(#P\(")<=&1O:6YG(&,N8V]M<&]N96YT7V4H,2P@,"XW*2(@/#P@ M96YD;#L-"@D)8RYC;VUP;VYE;G1?92@Q+" P+C<I.PT*"0EC;W5T(#P\(&,@ M/#P@96YD;#L-"@E](&-A=&-H*&-O;G-T(&5X8V5P=&EO;B8@92D@>PT*"0EC M97)R(#P\(")%6$-%4%1)3TXZ("(@/#P@92YW:&%T*"D@/#P@96YD;#L-"@E] M#0H)=')Y('L-"@D)8V]L;W(\8V]M<&]N96YT<U]R9V(\;&]N9R!D;W5B;&4^ M+"!C;VUP;VYE;G1S7W1R86ET<SQC;VUP;VYE;G1S7W)G8CQL;VYG(&1O=6)L M93X@/B ^(&,[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")< M=&1O:6YG(&,N8V]M<&]N96YT*#$L(#$N-"DB(#P\(&5N9&P[#0H)"6,N8V]M M<&]N96YT*#$L(#$N-"D[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T M(#P\(")<=&1O:6YG(&,N8V]M<&]N96YT7V,H,2P@,2XU*2(@/#P@96YD;#L- M"@D)8RYC;VUP;VYE;G1?8R@Q+" Q+C4I.PT*"0EC;W5T(#P\(&,@/#P@96YD M;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+F-O;7!O;F5N=%]C92@Q+" Q+C8I M(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N=%]C92@Q+" Q+C8I.PT*"0EC;W5T M(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+F-O;7!O;F5N M=%]E*#$L(#$N-RDB(#P\(&5N9&P[#0H)"6,N8V]M<&]N96YT7V4H,2P@,2XW M*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)?2!C871C:"AC;VYS="!E>&-E M<'1I;VXF(&4I('L-"@D)8V5R<B \/" B15A#15!424]..B B(#P\(&4N=VAA M="@I(#P\(&5N9&P[#0H)?0T*"71R>2![#0H)"6-O;&]R/&-O;7!O;F5N='-? M<F=B/&QO;F<@9&]U8FQE/BP@8V]M<&]N96YT<U]T<F%I=',\8V]M<&]N96YT M<U]R9V(\;&]N9R!D;W5B;&4^(#X@/B!C.PT*"0EC;W5T(#P\(&,@/#P@96YD M;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+F-O;7!O;F5N="@Q+" M,"XT*2(@ M/#P@96YD;#L-"@D)8RYC;VUP;VYE;G0H,2P@+3 N-"D[#0H)"6-O=70@/#P@ M8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8V]M<&]N96YT7V,H M,2P@+3 N-2DB(#P\(&5N9&P[#0H)"6,N8V]M<&]N96YT7V,H,2P@+3 N-2D[ M#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N M8V]M<&]N96YT7V-E*#$L("TP+C8I(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N M=%]C92@Q+" M,"XV*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@ M/#P@(EQT9&]I;F<@8RYC;VUP;VYE;G1?92@Q+" M,"XW*2(@/#P@96YD;#L- M"@D)8RYC;VUP;VYE;G1?92@Q+" M,"XW*3L-"@D)8V]U=" \/"!C(#P\(&5N M9&P[#0H)?2!C871C:"AC;VYS="!E>&-E<'1I;VXF(&4I('L-"@D)8V5R<B \ M/" B15A#15!424]..B B(#P\(&4N=VAA="@I(#P\(&5N9&P[#0H)?0T*"71R M>2![#0H)"6-O;&]R/&-O;7!O;F5N='-?<F=B/&QO;F<@9&]U8FQE/BP@8V]M M<&]N96YT<U]T<F%I=',\8V]M<&]N96YT<U]R9V(\;&]N9R!D;W5B;&4^(#X@ M/B!C.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN M9R!C+F-O;7!O;F5N="@R+" P+C0I(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N M="@R+" P+C0I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B M7'1D;VEN9R!C+F-O;7!O;F5N=%]C*#(L(# N-2DB(#P\(&5N9&P[#0H)"6,N M8V]M<&]N96YT7V,H,BP@,"XU*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H) M"6-O=70@/#P@(EQT9&]I;F<@8RYC;VUP;VYE;G1?8V4H,BP@,"XV*2(@/#P@ M96YD;#L-"@D)8RYC;VUP;VYE;G1?8V4H,BP@,"XV*3L-"@D)8V]U=" \/"!C M(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYC;VUP;VYE;G1?92@R M+" P+C<I(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N=%]E*#(L(# N-RD[#0H) M"6-O=70@/#P@8R \/"!E;F1L.PT*"7T@8V%T8V@H8V]N<W0@97AC97!T:6]N M)B!E*2![#0H)"6-E<G(@/#P@(D580T505$E/3CH@(B \/"!E+G=H870H*2 \ M/"!E;F1L.PT*"7T-"@ET<GD@>PT*"0EC;VQO<CQC;VUP;VYE;G1S7W)G8CQL M;VYG(&1O=6)L93XL(&-O;7!O;F5N='-?=')A:71S/&-O;7!O;F5N='-?<F=B M/&QO;F<@9&]U8FQE/B ^(#X@8SL-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H) M"6-O=70@/#P@(EQT9&]I;F<@8RYC;VUP;VYE;G0H,BP@,2XT*2(@/#P@96YD M;#L-"@D)8RYC;VUP;VYE;G0H,BP@,2XT*3L-"@D)8V]U=" \/"!C(#P\(&5N M9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYC;VUP;VYE;G1?8R@R+" Q+C4I M(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N=%]C*#(L(#$N-2D[#0H)"6-O=70@ M/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8V]M<&]N96YT M7V-E*#(L(#$N-BDB(#P\(&5N9&P[#0H)"6,N8V]M<&]N96YT7V-E*#(L(#$N M-BD[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG M(&,N8V]M<&]N96YT7V4H,BP@,2XW*2(@/#P@96YD;#L-"@D)8RYC;VUP;VYE M;G1?92@R+" Q+C<I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@E](&-A=&-H M*&-O;G-T(&5X8V5P=&EO;B8@92D@>PT*"0EC97)R(#P\(")%6$-%4%1)3TXZ M("(@/#P@92YW:&%T*"D@/#P@96YD;#L-"@E]#0H)=')Y('L-"@D)8V]L;W(\ M8V]M<&]N96YT<U]R9V(\;&]N9R!D;W5B;&4^+"!C;VUP;VYE;G1S7W1R86ET M<SQC;VUP;VYE;G1S7W)G8CQL;VYG(&1O=6)L93X@/B ^(&,[#0H)"6-O=70@ M/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8V]M<&]N96YT M*#(L("TP+C0I(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N="@R+" M,"XT*3L- M"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYC M;VUP;VYE;G1?8R@R+" M,"XU*2(@/#P@96YD;#L-"@D)8RYC;VUP;VYE;G1? M8R@R+" M,"XU*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@ M(EQT9&]I;F<@8RYC;VUP;VYE;G1?8V4H,BP@+3 N-BDB(#P\(&5N9&P[#0H) M"6,N8V]M<&]N96YT7V-E*#(L("TP+C8I.PT*"0EC;W5T(#P\(&,@/#P@96YD M;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+F-O;7!O;F5N=%]E*#(L("TP+C<I M(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N=%]E*#(L("TP+C<I.PT*"0EC;W5T M(#P\(&,@/#P@96YD;#L-"@E](&-A=&-H*&-O;G-T(&5X8V5P=&EO;B8@92D@ M>PT*"0EC97)R(#P\(")%6$-%4%1)3TXZ("(@/#P@92YW:&%T*"D@/#P@96YD M;#L-"@E]#0H)=')Y('L-"@D)8V]L;W(\8V]M<&]N96YT<U]R9V(\;&]N9R!D M;W5B;&4^+"!C;VUP;VYE;G1S7W1R86ET<SQC;VUP;VYE;G1S7W)G8CQL;VYG M(&1O=6)L93X@/B ^(&,[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T M(#P\(")<=&1O:6YG(&,N8V]M<&]N96YT*#,L(# N-"DB(#P\(&5N9&P[#0H) M"6,N8V]M<&]N96YT*#,L(# N-"D[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT* M"0EC;W5T(#P\(")<=&1O:6YG(&,N8V]M<&]N96YT7V,H,RP@,"XU*2(@/#P@ M96YD;#L-"@D)8RYC;VUP;VYE;G1?8R@S+" P+C4I.PT*"0EC;W5T(#P\(&,@ M/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+F-O;7!O;F5N=%]C92@S M+" P+C8I(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N=%]C92@S+" P+C8I.PT* M"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+F-O M;7!O;F5N=%]E*#,L(# N-RDB(#P\(&5N9&P[#0H)"6,N8V]M<&]N96YT7V4H M,RP@,"XW*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)?2!C871C:"AC;VYS M="!E>&-E<'1I;VXF(&4I('L-"@D)8V5R<B \/" B15A#15!424]..B B(#P\ M(&4N=VAA="@I(#P\(&5N9&P[#0H)?0T*"71R>2![#0H)"6-O;&]R/&-O;7!O M;F5N='-?<F=B/&QO;F<@9&]U8FQE/BP@8V]M<&]N96YT<U]T<F%I=',\8V]M M<&]N96YT<U]R9V(\;&]N9R!D;W5B;&4^(#X@/B!C.PT*"0EC;W5T(#P\(&,@ M/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+F-O;7!O;F5N="@S+" Q M+C0I(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N="@S+" Q+C0I.PT*"0EC;W5T M(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+F-O;7!O;F5N M=%]C*#,L(#$N-2DB(#P\(&5N9&P[#0H)"6,N8V]M<&]N96YT7V,H,RP@,2XU M*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@ M8RYC;VUP;VYE;G1?8V4H,RP@,2XV*2(@/#P@96YD;#L-"@D)8RYC;VUP;VYE M;G1?8V4H,RP@,2XV*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@ M/#P@(EQT9&]I;F<@8RYC;VUP;VYE;G1?92@S+" Q+C<I(B \/"!E;F1L.PT* M"0EC+F-O;7!O;F5N=%]E*#,L(#$N-RD[#0H)"6-O=70@/#P@8R \/"!E;F1L M.PT*"7T@8V%T8V@H8V]N<W0@97AC97!T:6]N)B!E*2![#0H)"6-E<G(@/#P@ M(D580T505$E/3CH@(B \/"!E+G=H870H*2 \/"!E;F1L.PT*"7T-"@ET<GD@ M>PT*"0EC;VQO<CQC;VUP;VYE;G1S7W)G8CQL;VYG(&1O=6)L93XL(&-O;7!O M;F5N='-?=')A:71S/&-O;7!O;F5N='-?<F=B/&QO;F<@9&]U8FQE/B ^(#X@ M8SL-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@ M8RYC;VUP;VYE;G0H,RP@+3 N-"DB(#P\(&5N9&P[#0H)"6,N8V]M<&]N96YT M*#$L("TP+C0I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B M7'1D;VEN9R!C+F-O;7!O;F5N=%]C*#,L("TP+C4I(B \/"!E;F1L.PT*"0EC M+F-O;7!O;F5N=%]C*#,L("TP+C4I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L- M"@D)8V]U=" \/" B7'1D;VEN9R!C+F-O;7!O;F5N=%]C92@S+" M,"XV*2(@ M/#P@96YD;#L-"@D)8RYC;VUP;VYE;G1?8V4H,RP@+3 N-BD[#0H)"6-O=70@ M/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8V]M<&]N96YT M7V4H,RP@+3 N-RDB(#P\(&5N9&P[#0H)"6,N8V]M<&]N96YT7V4H,RP@+3 N M-RD[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"7T@8V%T8V@H8V]N<W0@97AC M97!T:6]N)B!E*2![#0H)"6-E<G(@/#P@(D580T505$E/3CH@(B \/"!E+G=H M870H*2 \/"!E;F1L.PT*"7T-"@EC;W5T(#P\(")497-T:6YG(&)O;W-T.CIC M;VQO<CHZ<F=B.CIC;VQO<CPB(#P\(&5N9&P@/#P@(B!B;V]S=#HZ8V]L;W(Z M.G)G8CHZ8V]M<&]N96YT<U]R9V(\=6YS:6=N960@8VAA<CXL(B \/"!E;F1L M(#P\("(@8F]O<W0Z.F-O;&]R.CIR9V(Z.F-O;7!O;F5N='-?=')A:71S/&)O M;W-T.CIC;VQO<CHZ<F=B.CIC;VUP;VYE;G1S7W)G8CQU;G-I9VYE9"!C:&%R M/B ^(B \/"!E;F1L(#P\("<^)R \/"!E;F1L.PT*"71R>2![#0H)"6-O;&]R M/&-O;7!O;F5N='-?<F=B/'5N<VEG;F5D(&-H87(^+"!C;VUP;VYE;G1S7W1R M86ET<SQC;VUP;VYE;G1S7W)G8CQU;G-I9VYE9"!C:&%R/B ^(#X@8SL-"@D) M8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYC;VUP M;VYE;G1S*# N-"P@,"XT+" P+C0I(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N M=',H,"XT+" P+C0L(# N-"D[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC M;W5T(#P\(")<=&1O:6YG(&,N8V]M<&]N96YT<U]C*# N-2P@,"XU+" P+C4I M(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N='-?8R@P+C4L(# N-2P@,"XU*3L- M"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYC M;VUP;VYE;G1S7V4H,"XV+" P+C8L(# N-BDB(#P\(&5N9&P[#0H)"6,N8V]M M<&]N96YT<U]E*# N-BP@,"XV+" P+C8I.PT*"0EC;W5T(#P\(&,@/#P@96YD M;#L-"@E](&-A=&-H*&-O;G-T(&5X8V5P=&EO;B8@92D@>PT*"0EC97)R(#P\ M(")%6$-%4%1)3TXZ("(@/#P@92YW:&%T*"D@/#P@96YD;#L-"@E]#0H)=')Y M('L-"@D)8V]L;W(\8V]M<&]N96YT<U]R9V(\=6YS:6=N960@8VAA<CXL(&-O M;7!O;F5N='-?=')A:71S/&-O;7!O;F5N='-?<F=B/'5N<VEG;F5D(&-H87(^ M(#X@/B!C.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B7'1D M;VEN9R!C+F-O;7!O;F5N=',H,2XT+" Q+C0L(#$N-"DB(#P\(&5N9&P[#0H) M"6,N8V]M<&]N96YT<R@Q+C0L(#$N-"P@,2XT*3L-"@D)8V]U=" \/"!C(#P\ M(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYC;VUP;VYE;G1S7V,H,2XU M+" Q+C4L(#$N-2DB(#P\(&5N9&P[#0H)"6,N8V]M<&]N96YT<U]C*#$N-2P@ M,2XU+" Q+C4I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B M7'1D;VEN9R!C+F-O;7!O;F5N='-?92@Q+C8L(#$N-BP@,2XV*2(@/#P@96YD M;#L-"@D)8RYC;VUP;VYE;G1S7V4H,2XV+" Q+C8L(#$N-BD[#0H)"6-O=70@ M/#P@8R \/"!E;F1L.PT*"7T@8V%T8V@H8V]N<W0@97AC97!T:6]N)B!E*2![ M#0H)"6-E<G(@/#P@(D580T505$E/3CH@(B \/"!E+G=H870H*2 \/"!E;F1L M.PT*"7T-"@ET<GD@>PT*"0EC;VQO<CQC;VUP;VYE;G1S7W)G8CQU;G-I9VYE M9"!C:&%R/BP@8V]M<&]N96YT<U]T<F%I=',\8V]M<&]N96YT<U]R9V(\=6YS M:6=N960@8VAA<CX@/B ^(&,[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC M;W5T(#P\(")<=&1O:6YG(&,N8V]M<&]N96YT<R@M,"XT+" M,"XT+" M,"XT M*2(@/#P@96YD;#L-"@D)8RYC;VUP;VYE;G1S*"TP+C0L("TP+C0L("TP+C0I M.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C M+F-O;7!O;F5N='-?8R@M,"XU+" M,"XU+" M,"XU*2(@/#P@96YD;#L-"@D) M8RYC;VUP;VYE;G1S7V,H+3 N-2P@+3 N-2P@+3 N-2D[#0H)"6-O=70@/#P@ M8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8V]M<&]N96YT<U]E M*"TP+C8L("TP+C8L("TP+C8I(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N='-? M92@M,"XV+" M,"XV+" M,"XV*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H) M?2!C871C:"AC;VYS="!E>&-E<'1I;VXF(&4I('L-"@D)8V5R<B \/" B15A# M15!424]..B B(#P\(&4N=VAA="@I(#P\(&5N9&P[#0H)?0T*"71R>2![#0H) M"6-O;&]R/&-O;7!O;F5N='-?<F=B/'5N<VEG;F5D(&-H87(^+"!C;VUP;VYE M;G1S7W1R86ET<SQC;VUP;VYE;G1S7W)G8CQU;G-I9VYE9"!C:&%R/B ^(#X@ M8SL-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@ M8RYR*# N-"DB(#P\(&5N9&P[#0H)"6,N<B@P+C0I.PT*"0EC;W5T(#P\(&,@ M/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+G)?8R@P+C4I(B \/"!E M;F1L.PT*"0EC+G)?8R@P+C4I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D) M8V]U=" \/" B7'1D;VEN9R!C+G)?92@P+C8I(B \/"!E;F1L.PT*"0EC+G)? M92@P+C8I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@E](&-A=&-H*&-O;G-T M(&5X8V5P=&EO;B8@92D@>PT*"0EC97)R(#P\(")%6$-%4%1)3TXZ("(@/#P@ M92YW:&%T*"D@/#P@96YD;#L-"@E]#0H)=')Y('L-"@D)8V]L;W(\8V]M<&]N M96YT<U]R9V(\=6YS:6=N960@8VAA<CXL(&-O;7!O;F5N='-?=')A:71S/&-O M;7!O;F5N='-?<F=B/'5N<VEG;F5D(&-H87(^(#X@/B!C.PT*"0EC;W5T(#P\ M(&,@/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+G(H,2XT*2(@/#P@ M96YD;#L-"@D)8RYR*#$N-"D[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC M;W5T(#P\(")<=&1O:6YG(&,N<E]C*#$N-2DB(#P\(&5N9&P[#0H)"6,N<E]C M*#$N-2D[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O M:6YG(&,N<E]E*#$N-BDB(#P\(&5N9&P[#0H)"6,N<E]E*#$N-BD[#0H)"6-O M=70@/#P@8R \/"!E;F1L.PT*"7T@8V%T8V@H8V]N<W0@97AC97!T:6]N)B!E M*2![#0H)"6-E<G(@/#P@(D580T505$E/3CH@(B \/"!E+G=H870H*2 \/"!E M;F1L.PT*"7T-"@ET<GD@>PT*"0EC;VQO<CQC;VUP;VYE;G1S7W)G8CQU;G-I M9VYE9"!C:&%R/BP@8V]M<&]N96YT<U]T<F%I=',\8V]M<&]N96YT<U]R9V(\ M=6YS:6=N960@8VAA<CX@/B ^(&,[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT* M"0EC;W5T(#P\(")<=&1O:6YG(&,N<B@M,"XT*2(@/#P@96YD;#L-"@D)8RYR M*"TP+C0I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B7'1D M;VEN9R!C+G)?8R@M,"XU*2(@/#P@96YD;#L-"@D)8RYR7V,H+3 N-2D[#0H) M"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N<E]E M*"TP+C8I(B \/"!E;F1L.PT*"0EC+G)?92@M,"XV*3L-"@D)8V]U=" \/"!C M(#P\(&5N9&P[#0H)?2!C871C:"AC;VYS="!E>&-E<'1I;VXF(&4I('L-"@D) M8V5R<B \/" B15A#15!424]..B B(#P\(&4N=VAA="@I(#P\(&5N9&P[#0H) M?0T*"71R>2![#0H)"6-O;&]R/&-O;7!O;F5N='-?<F=B/'5N<VEG;F5D(&-H M87(^+"!C;VUP;VYE;G1S7W1R86ET<SQC;VUP;VYE;G1S7W)G8CQU;G-I9VYE M9"!C:&%R/B ^(#X@8SL-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@ M/#P@(EQT9&]I;F<@8RYG*# N-"DB(#P\(&5N9&P[#0H)"6,N9R@P+C0I.PT* M"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+F=? M8R@P+C4I(B \/"!E;F1L.PT*"0EC+F=?8R@P+C4I.PT*"0EC;W5T(#P\(&,@ M/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+F=?92@P+C8I(B \/"!E M;F1L.PT*"0EC+F=?92@P+C8I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@E] M(&-A=&-H*&-O;G-T(&5X8V5P=&EO;B8@92D@>PT*"0EC97)R(#P\(")%6$-% M4%1)3TXZ("(@/#P@92YW:&%T*"D@/#P@96YD;#L-"@E]#0H)=')Y('L-"@D) M8V]L;W(\8V]M<&]N96YT<U]R9V(\=6YS:6=N960@8VAA<CXL(&-O;7!O;F5N M='-?=')A:71S/&-O;7!O;F5N='-?<F=B/'5N<VEG;F5D(&-H87(^(#X@/B!C M.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C M+F<H,2XT*2(@/#P@96YD;#L-"@D)8RYG*#$N-"D[#0H)"6-O=70@/#P@8R \ M/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N9U]C*#$N-2DB(#P\(&5N M9&P[#0H)"6,N9U]C*#$N-2D[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC M;W5T(#P\(")<=&1O:6YG(&,N9U]E*#$N-BDB(#P\(&5N9&P[#0H)"6,N9U]E M*#$N-BD[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"7T@8V%T8V@H8V]N<W0@ M97AC97!T:6]N)B!E*2![#0H)"6-E<G(@/#P@(D580T505$E/3CH@(B \/"!E M+G=H870H*2 \/"!E;F1L.PT*"7T-"@ET<GD@>PT*"0EC;VQO<CQC;VUP;VYE M;G1S7W)G8CQU;G-I9VYE9"!C:&%R/BP@8V]M<&]N96YT<U]T<F%I=',\8V]M M<&]N96YT<U]R9V(\=6YS:6=N960@8VAA<CX@/B ^(&,[#0H)"6-O=70@/#P@ M8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N9R@M,"XT*2(@/#P@ M96YD;#L-"@D)8RYG*"TP+C0I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D) M8V]U=" \/" B7'1D;VEN9R!C+F=?8R@M,"XU*2(@/#P@96YD;#L-"@D)8RYG M7V,H+3 N-2D[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")< M=&1O:6YG(&,N9U]E*"TP+C8I(B \/"!E;F1L.PT*"0EC+F=?92@M,"XV*3L- M"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)?2!C871C:"AC;VYS="!E>&-E<'1I M;VXF(&4I('L-"@D)8V5R<B \/" B15A#15!424]..B B(#P\(&4N=VAA="@I M(#P\(&5N9&P[#0H)?0T*"71R>2![#0H)"6-O;&]R/&-O;7!O;F5N='-?<F=B M/'5N<VEG;F5D(&-H87(^+"!C;VUP;VYE;G1S7W1R86ET<SQC;VUP;VYE;G1S M7W)G8CQU;G-I9VYE9"!C:&%R/B ^(#X@8SL-"@D)8V]U=" \/"!C(#P\(&5N M9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYB*# N-"DB(#P\(&5N9&P[#0H) M"6,N8B@P+C0I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B M7'1D;VEN9R!C+F)?8R@P+C4I(B \/"!E;F1L.PT*"0EC+F)?8R@P+C4I.PT* M"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+F)? M92@P+C8I(B \/"!E;F1L.PT*"0EC+F)?92@P+C8I.PT*"0EC;W5T(#P\(&,@ M/#P@96YD;#L-"@E](&-A=&-H*&-O;G-T(&5X8V5P=&EO;B8@92D@>PT*"0EC M97)R(#P\(")%6$-%4%1)3TXZ("(@/#P@92YW:&%T*"D@/#P@96YD;#L-"@E] M#0H)=')Y('L-"@D)8V]L;W(\8V]M<&]N96YT<U]R9V(\=6YS:6=N960@8VAA M<CXL(&-O;7!O;F5N='-?=')A:71S/&-O;7!O;F5N='-?<F=B/'5N<VEG;F5D M(&-H87(^(#X@/B!C.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \ M/" B7'1D;VEN9R!C+F(H,2XT*2(@/#P@96YD;#L-"@D)8RYB*#$N-"D[#0H) M"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8E]C M*#$N-2DB(#P\(&5N9&P[#0H)"6,N8E]C*#$N-2D[#0H)"6-O=70@/#P@8R \ M/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8E]E*#$N-BDB(#P\(&5N M9&P[#0H)"6,N8E]E*#$N-BD[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"7T@ M8V%T8V@H8V]N<W0@97AC97!T:6]N)B!E*2![#0H)"6-E<G(@/#P@(D580T50 M5$E/3CH@(B \/"!E+G=H870H*2 \/"!E;F1L.PT*"7T-"@ET<GD@>PT*"0EC M;VQO<CQC;VUP;VYE;G1S7W)G8CQU;G-I9VYE9"!C:&%R/BP@8V]M<&]N96YT M<U]T<F%I=',\8V]M<&]N96YT<U]R9V(\=6YS:6=N960@8VAA<CX@/B ^(&,[ M#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N M8B@M,"XT*2(@/#P@96YD;#L-"@D)8RYB*"TP+C0I.PT*"0EC;W5T(#P\(&,@ M/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+F)?8R@M,"XU*2(@/#P@ M96YD;#L-"@D)8RYB7V,H+3 N-2D[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT* M"0EC;W5T(#P\(")<=&1O:6YG(&,N8E]E*"TP+C8I(B \/"!E;F1L.PT*"0EC M+F)?92@M,"XV*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)?2!C871C:"AC M;VYS="!E>&-E<'1I;VXF(&4I('L-"@D)8V5R<B \/" B15A#15!424]..B B M(#P\(&4N=VAA="@I(#P\(&5N9&P[#0H)?0T*"71R>2![#0H)"6-O;&]R/&-O M;7!O;F5N='-?<F=B/'5N<VEG;F5D(&-H87(^+"!C;VUP;VYE;G1S7W1R86ET M<SQC;VUP;VYE;G1S7W)G8CQU;G-I9VYE9"!C:&%R/B ^(#X@8SL-"@D)8V]U M=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYC;VUP;VYE M;G0H,"P@,"XT*2(@/#P@96YD;#L-"@D)8RYC;VUP;VYE;G0H,"P@,"XT*3L- M"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYC M;VUP;VYE;G1?8R@P+" P+C4I(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N=%]C M*# L(# N-2D[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")< M=&1O:6YG(&,N8V]M<&]N96YT7V-E*# L(# N-BDB(#P\(&5N9&P[#0H)"6,N M8V]M<&]N96YT7V-E*# L(# N-BD[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT* M"0EC;W5T(#P\(")<=&1O:6YG(&,N8V]M<&]N96YT7V4H,"P@,"XW*2(@/#P@ M96YD;#L-"@D)8RYC;VUP;VYE;G1?92@P+" P+C<I.PT*"0EC;W5T(#P\(&,@ M/#P@96YD;#L-"@E](&-A=&-H*&-O;G-T(&5X8V5P=&EO;B8@92D@>PT*"0EC M97)R(#P\(")%6$-%4%1)3TXZ("(@/#P@92YW:&%T*"D@/#P@96YD;#L-"@E] M#0H)=')Y('L-"@D)8V]L;W(\8V]M<&]N96YT<U]R9V(\=6YS:6=N960@8VAA M<CXL(&-O;7!O;F5N='-?=')A:71S/&-O;7!O;F5N='-?<F=B/'5N<VEG;F5D M(&-H87(^(#X@/B!C.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \ M/" B7'1D;VEN9R!C+F-O;7!O;F5N="@P+" Q+C0I(B \/"!E;F1L.PT*"0EC M+F-O;7!O;F5N="@P+" Q+C0I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D) M8V]U=" \/" B7'1D;VEN9R!C+F-O;7!O;F5N=%]C*# L(#$N-2DB(#P\(&5N M9&P[#0H)"6,N8V]M<&]N96YT7V,H,"P@,2XU*3L-"@D)8V]U=" \/"!C(#P\ M(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYC;VUP;VYE;G1?8V4H,"P@ M,2XV*2(@/#P@96YD;#L-"@D)8RYC;VUP;VYE;G1?8V4H,"P@,2XV*3L-"@D) M8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYC;VUP M;VYE;G1?92@P+" Q+C<I(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N=%]E*# L M(#$N-RD[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"7T@8V%T8V@H8V]N<W0@ M97AC97!T:6]N)B!E*2![#0H)"6-E<G(@/#P@(D580T505$E/3CH@(B \/"!E M+G=H870H*2 \/"!E;F1L.PT*"7T-"@ET<GD@>PT*"0EC;VQO<CQC;VUP;VYE M;G1S7W)G8CQU;G-I9VYE9"!C:&%R/BP@8V]M<&]N96YT<U]T<F%I=',\8V]M M<&]N96YT<U]R9V(\=6YS:6=N960@8VAA<CX@/B ^(&,[#0H)"6-O=70@/#P@ M8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8V]M<&]N96YT*# L M("TP+C0I(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N="@P+" M,"XT*3L-"@D) M8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYC;VUP M;VYE;G1?8R@P+" M,"XU*2(@/#P@96YD;#L-"@D)8RYC;VUP;VYE;G1?8R@P M+" M,"XU*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT M9&]I;F<@8RYC;VUP;VYE;G1?8V4H,"P@+3 N-BDB(#P\(&5N9&P[#0H)"6,N M8V]M<&]N96YT7V-E*# L("TP+C8I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L- M"@D)8V]U=" \/" B7'1D;VEN9R!C+F-O;7!O;F5N=%]E*# L("TP+C<I(B \ M/"!E;F1L.PT*"0EC+F-O;7!O;F5N=%]E*# L("TP+C<I.PT*"0EC;W5T(#P\ M(&,@/#P@96YD;#L-"@E](&-A=&-H*&-O;G-T(&5X8V5P=&EO;B8@92D@>PT* M"0EC97)R(#P\(")%6$-%4%1)3TXZ("(@/#P@92YW:&%T*"D@/#P@96YD;#L- M"@E]#0H)=')Y('L-"@D)8V]L;W(\8V]M<&]N96YT<U]R9V(\=6YS:6=N960@ M8VAA<CXL(&-O;7!O;F5N='-?=')A:71S/&-O;7!O;F5N='-?<F=B/'5N<VEG M;F5D(&-H87(^(#X@/B!C.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U M=" \/" B7'1D;VEN9R!C+F-O;7!O;F5N="@Q+" P+C0I(B \/"!E;F1L.PT* M"0EC+F-O;7!O;F5N="@Q+" P+C0I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L- M"@D)8V]U=" \/" B7'1D;VEN9R!C+F-O;7!O;F5N=%]C*#$L(# N-2DB(#P\ M(&5N9&P[#0H)"6,N8V]M<&]N96YT7V,H,2P@,"XU*3L-"@D)8V]U=" \/"!C M(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYC;VUP;VYE;G1?8V4H M,2P@,"XV*2(@/#P@96YD;#L-"@D)8RYC;VUP;VYE;G1?8V4H,2P@,"XV*3L- M"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYC M;VUP;VYE;G1?92@Q+" P+C<I(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N=%]E M*#$L(# N-RD[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"7T@8V%T8V@H8V]N M<W0@97AC97!T:6]N)B!E*2![#0H)"6-E<G(@/#P@(D580T505$E/3CH@(B \ M/"!E+G=H870H*2 \/"!E;F1L.PT*"7T-"@ET<GD@>PT*"0EC;VQO<CQC;VUP M;VYE;G1S7W)G8CQU;G-I9VYE9"!C:&%R/BP@8V]M<&]N96YT<U]T<F%I=',\ M8V]M<&]N96YT<U]R9V(\=6YS:6=N960@8VAA<CX@/B ^(&,[#0H)"6-O=70@ M/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8V]M<&]N96YT M*#$L(#$N-"DB(#P\(&5N9&P[#0H)"6,N8V]M<&]N96YT*#$L(#$N-"D[#0H) M"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8V]M M<&]N96YT7V,H,2P@,2XU*2(@/#P@96YD;#L-"@D)8RYC;VUP;VYE;G1?8R@Q M+" Q+C4I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B7'1D M;VEN9R!C+F-O;7!O;F5N=%]C92@Q+" Q+C8I(B \/"!E;F1L.PT*"0EC+F-O M;7!O;F5N=%]C92@Q+" Q+C8I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D) M8V]U=" \/" B7'1D;VEN9R!C+F-O;7!O;F5N=%]E*#$L(#$N-RDB(#P\(&5N M9&P[#0H)"6,N8V]M<&]N96YT7V4H,2P@,2XW*3L-"@D)8V]U=" \/"!C(#P\ M(&5N9&P[#0H)?2!C871C:"AC;VYS="!E>&-E<'1I;VXF(&4I('L-"@D)8V5R M<B \/" B15A#15!424]..B B(#P\(&4N=VAA="@I(#P\(&5N9&P[#0H)?0T* M"71R>2![#0H)"6-O;&]R/&-O;7!O;F5N='-?<F=B/'5N<VEG;F5D(&-H87(^ M+"!C;VUP;VYE;G1S7W1R86ET<SQC;VUP;VYE;G1S7W)G8CQU;G-I9VYE9"!C M:&%R/B ^(#X@8SL-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@ M(EQT9&]I;F<@8RYC;VUP;VYE;G0H,2P@+3 N-"DB(#P\(&5N9&P[#0H)"6,N M8V]M<&]N96YT*#$L("TP+C0I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D) M8V]U=" \/" B7'1D;VEN9R!C+F-O;7!O;F5N=%]C*#$L("TP+C4I(B \/"!E M;F1L.PT*"0EC+F-O;7!O;F5N=%]C*#$L("TP+C4I.PT*"0EC;W5T(#P\(&,@ M/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+F-O;7!O;F5N=%]C92@Q M+" M,"XV*2(@/#P@96YD;#L-"@D)8RYC;VUP;VYE;G1?8V4H,2P@+3 N-BD[ M#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N M8V]M<&]N96YT7V4H,2P@+3 N-RDB(#P\(&5N9&P[#0H)"6,N8V]M<&]N96YT M7V4H,2P@+3 N-RD[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"7T@8V%T8V@H M8V]N<W0@97AC97!T:6]N)B!E*2![#0H)"6-E<G(@/#P@(D580T505$E/3CH@ M(B \/"!E+G=H870H*2 \/"!E;F1L.PT*"7T-"@ET<GD@>PT*"0EC;VQO<CQC M;VUP;VYE;G1S7W)G8CQU;G-I9VYE9"!C:&%R/BP@8V]M<&]N96YT<U]T<F%I M=',\8V]M<&]N96YT<U]R9V(\=6YS:6=N960@8VAA<CX@/B ^(&,[#0H)"6-O M=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8V]M<&]N M96YT*#(L(# N-"DB(#P\(&5N9&P[#0H)"6,N8V]M<&]N96YT*#(L(# N-"D[ M#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N M8V]M<&]N96YT7V,H,BP@,"XU*2(@/#P@96YD;#L-"@D)8RYC;VUP;VYE;G1? M8R@R+" P+C4I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B M7'1D;VEN9R!C+F-O;7!O;F5N=%]C92@R+" P+C8I(B \/"!E;F1L.PT*"0EC M+F-O;7!O;F5N=%]C92@R+" P+C8I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L- M"@D)8V]U=" \/" B7'1D;VEN9R!C+F-O;7!O;F5N=%]E*#(L(# N-RDB(#P\ M(&5N9&P[#0H)"6,N8V]M<&]N96YT7V4H,BP@,"XW*3L-"@D)8V]U=" \/"!C M(#P\(&5N9&P[#0H)?2!C871C:"AC;VYS="!E>&-E<'1I;VXF(&4I('L-"@D) M8V5R<B \/" B15A#15!424]..B B(#P\(&4N=VAA="@I(#P\(&5N9&P[#0H) M?0T*"71R>2![#0H)"6-O;&]R/&-O;7!O;F5N='-?<F=B/'5N<VEG;F5D(&-H M87(^+"!C;VUP;VYE;G1S7W1R86ET<SQC;VUP;VYE;G1S7W)G8CQU;G-I9VYE M9"!C:&%R/B ^(#X@8SL-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@ M/#P@(EQT9&]I;F<@8RYC;VUP;VYE;G0H,BP@,2XT*2(@/#P@96YD;#L-"@D) M8RYC;VUP;VYE;G0H,BP@,2XT*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H) M"6-O=70@/#P@(EQT9&]I;F<@8RYC;VUP;VYE;G1?8R@R+" Q+C4I(B \/"!E M;F1L.PT*"0EC+F-O;7!O;F5N=%]C*#(L(#$N-2D[#0H)"6-O=70@/#P@8R \ M/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8V]M<&]N96YT7V-E*#(L M(#$N-BDB(#P\(&5N9&P[#0H)"6,N8V]M<&]N96YT7V-E*#(L(#$N-BD[#0H) M"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8V]M M<&]N96YT7V4H,BP@,2XW*2(@/#P@96YD;#L-"@D)8RYC;VUP;VYE;G1?92@R M+" Q+C<I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@E](&-A=&-H*&-O;G-T M(&5X8V5P=&EO;B8@92D@>PT*"0EC97)R(#P\(")%6$-%4%1)3TXZ("(@/#P@ M92YW:&%T*"D@/#P@96YD;#L-"@E]#0H)=')Y('L-"@D)8V]L;W(\8V]M<&]N M96YT<U]R9V(\=6YS:6=N960@8VAA<CXL(&-O;7!O;F5N='-?=')A:71S/&-O M;7!O;F5N='-?<F=B/'5N<VEG;F5D(&-H87(^(#X@/B!C.PT*"0EC;W5T(#P\ M(&,@/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+F-O;7!O;F5N="@R M+" M,"XT*2(@/#P@96YD;#L-"@D)8RYC;VUP;VYE;G0H,BP@+3 N-"D[#0H) M"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8V]M M<&]N96YT7V,H,BP@+3 N-2DB(#P\(&5N9&P[#0H)"6,N8V]M<&]N96YT7V,H M,BP@+3 N-2D[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")< M=&1O:6YG(&,N8V]M<&]N96YT7V-E*#(L("TP+C8I(B \/"!E;F1L.PT*"0EC M+F-O;7!O;F5N=%]C92@R+" M,"XV*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[ M#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYC;VUP;VYE;G1?92@R+" M,"XW*2(@ M/#P@96YD;#L-"@D)8RYC;VUP;VYE;G1?92@R+" M,"XW*3L-"@D)8V]U=" \ M/"!C(#P\(&5N9&P[#0H)?2!C871C:"AC;VYS="!E>&-E<'1I;VXF(&4I('L- M"@D)8V5R<B \/" B15A#15!424]..B B(#P\(&4N=VAA="@I(#P\(&5N9&P[ M#0H)?0T*"71R>2![#0H)"6-O;&]R/&-O;7!O;F5N='-?<F=B/'5N<VEG;F5D M(&-H87(^+"!C;VUP;VYE;G1S7W1R86ET<SQC;VUP;VYE;G1S7W)G8CQU;G-I M9VYE9"!C:&%R/B ^(#X@8SL-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O M=70@/#P@(EQT9&]I;F<@8RYC;VUP;VYE;G0H,RP@,"XT*2(@/#P@96YD;#L- M"@D)8RYC;VUP;VYE;G0H,RP@,"XT*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[ M#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYC;VUP;VYE;G1?8R@S+" P+C4I(B \ M/"!E;F1L.PT*"0EC+F-O;7!O;F5N=%]C*#,L(# N-2D[#0H)"6-O=70@/#P@ M8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N8V]M<&]N96YT7V-E M*#,L(# N-BDB(#P\(&5N9&P[#0H)"6,N8V]M<&]N96YT7V-E*#,L(# N-BD[ M#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\(")<=&1O:6YG(&,N M8V]M<&]N96YT7V4H,RP@,"XW*2(@/#P@96YD;#L-"@D)8RYC;VUP;VYE;G1? M92@S+" P+C<I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@E](&-A=&-H*&-O M;G-T(&5X8V5P=&EO;B8@92D@>PT*"0EC97)R(#P\(")%6$-%4%1)3TXZ("(@ M/#P@92YW:&%T*"D@/#P@96YD;#L-"@E]#0H)=')Y('L-"@D)8V]L;W(\8V]M M<&]N96YT<U]R9V(\=6YS:6=N960@8VAA<CXL(&-O;7!O;F5N='-?=')A:71S M/&-O;7!O;F5N='-?<F=B/'5N<VEG;F5D(&-H87(^(#X@/B!C.PT*"0EC;W5T M(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+F-O;7!O;F5N M="@S+" Q+C0I(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N="@S+" Q+C0I.PT* M"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C+F-O M;7!O;F5N=%]C*#,L(#$N-2DB(#P\(&5N9&P[#0H)"6,N8V]M<&]N96YT7V,H M,RP@,2XU*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT M9&]I;F<@8RYC;VUP;VYE;G1?8V4H,RP@,2XV*2(@/#P@96YD;#L-"@D)8RYC M;VUP;VYE;G1?8V4H,RP@,2XV*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H) M"6-O=70@/#P@(EQT9&]I;F<@8RYC;VUP;VYE;G1?92@S+" Q+C<I(B \/"!E M;F1L.PT*"0EC+F-O;7!O;F5N=%]E*#,L(#$N-RD[#0H)"6-O=70@/#P@8R \ M/"!E;F1L.PT*"7T@8V%T8V@H8V]N<W0@97AC97!T:6]N)B!E*2![#0H)"6-E M<G(@/#P@(D580T505$E/3CH@(B \/"!E+G=H870H*2 \/"!E;F1L.PT*"7T- M"@ET<GD@>PT*"0EC;VQO<CQC;VUP;VYE;G1S7W)G8CQU;G-I9VYE9"!C:&%R M/BP@8V]M<&]N96YT<U]T<F%I=',\8V]M<&]N96YT<U]R9V(\=6YS:6=N960@ M8VAA<CX@/B ^(&,[#0H)"6-O=70@/#P@8R \/"!E;F1L.PT*"0EC;W5T(#P\ M(")<=&1O:6YG(&,N8V]M<&]N96YT*#,L("TP+C0I(B \/"!E;F1L.PT*"0EC M+F-O;7!O;F5N="@Q+" M,"XT*3L-"@D)8V]U=" \/"!C(#P\(&5N9&P[#0H) M"6-O=70@/#P@(EQT9&]I;F<@8RYC;VUP;VYE;G1?8R@S+" M,"XU*2(@/#P@ M96YD;#L-"@D)8RYC;VUP;VYE;G1?8R@S+" M,"XU*3L-"@D)8V]U=" \/"!C M(#P\(&5N9&P[#0H)"6-O=70@/#P@(EQT9&]I;F<@8RYC;VUP;VYE;G1?8V4H M,RP@+3 N-BDB(#P\(&5N9&P[#0H)"6,N8V]M<&]N96YT7V-E*#,L("TP+C8I M.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@D)8V]U=" \/" B7'1D;VEN9R!C M+F-O;7!O;F5N=%]E*#,L("TP+C<I(B \/"!E;F1L.PT*"0EC+F-O;7!O;F5N M=%]E*#,L("TP+C<I.PT*"0EC;W5T(#P\(&,@/#P@96YD;#L-"@E](&-A=&-H M*&-O;G-T(&5X8V5P=&EO;B8@92D@>PT*"0EC97)R(#P\(")%6$-%4%1)3TXZ M("(@/#P@92YW:&%T*"D@/#P@96YD;#L-"@E]#0H)8V]U=" \/"!E;F1L(#P\ M(&5N9&P@/#P@(E!R97-S($5.5$52('1O(&5X:70N+BX@(CL-"@EC:6XN9V5T 2*"D[#0H)<F5T=7)N(# [#0I] ` end begin 666 color.hpp M+RH-"@E.3U1%.@T*"0DQ*0EB861?=F%L=64@9&]E<R!N;W0@=&%K92!A9&1I M=&EO;F%L(&%R9W5M96YT<R H9&5S8W)I8FEN9R!M;W)E#0H)"0EP<F5C:7-E M;'D@:VEN9"!O9B!E<G)O<BD@8F5C875S92!N=6UB97(@='EP92!O9B!V86QU M92!I<R!N;W0@:VYO=VX-"@D)"6%N9"!T86MI;F<@<W1R:6YG(&ES('!O:6YT M;&5S<R!B96-A<W5E(&ET('=O=6QD(')E<75I<F4@=7-E<B!T;PT*"0D)8V]N M=F5R="!A;F0@=V]U;&0@;6%K92!D;W5B=',@;V8@=VAO(&ES(')E<W!O;G-I M8FQE(&9O<B!D97-T<F]Y:6YG#0H)"0ET:&%T('-T<FEN9RX-"@D),BD)8V]L M;W(@8V]N<W1R=6-T;W)S(&%N9"!A<W-I9VX@;W!E<F%T;W)S(&-A;B!T86ME M(&%S(&$@<&%R86UE=&5R#0H)"0EA;GD@8V]L;W(@8VQA<W,@*'=I=&@@86QL M('!O<VEB;&4@=6YD97)L87EI;F<@<F5P<F5S96YT871I;VX-"@D)"6-L87-S M97,I(&)U="!I="!C86X@=&%K92!A<R!A('!A<F%M971E<B!O;FQY(&ET<R!R M97!R97-E;G1A=&EO;@T*"0D);V)J96-T+B!4:&ES(&ES(&)E8V%U<V4@;V8@ M8V]M<&]N96YT<U]T<F%I=',@=VAI8V@@87)E(&1E9FEN960@9F]R#0H)"0EC M;VQO<B!C;&%S<R!B=70@;F]T(&9O<B!A;&]N92!S=&%N9&EN9R!#;VUP;VYE M;G1S('1Y<&4@86YD('5S:6YG#0H)"0ED969A=6QT('9A;'5E('=O=6QD(&YO M="!B92!G;V]D+@T*"0DS*0ES=&%T:6,@;65M8F5R<R!A<F4@;F]T(&EN:71I M86QI>F5D(&EN(&-L87-S(&)U="!O=71S:61E(&)E8V%U<V4-"@D)"71H97)E M(&ES(&YO(&YE960@=&\@:6YI=&EA;&EZ92!T:&5M(&EN<VED92!A;F0@0F]R M;&%N9"!#*RL@-2XU(&1O97,-"@D)"6YO="!C;VUP:6QE(&EF(&EN:71I86QI M>F%T:6]N(&ES(&EN(&-L87-S(&-L86EM:6YG('1H870-"@D)"6EN:71I86QI M>F%T;W)S(&UU<W0@8F4@8V]N<W1A;G0N#0H)"30I"4UE;6)E<B!F=6YC=&EO M;G,@;6%N:7!U;&%T:6YG(&]N(&]R:6=I;F%L(')E<')E<V5N=&%T:6]N(&%N M9 T*"0D);W)I9VEN86P@='EP97,@87)E('!O<W1F:65X960@=VET:"!?;R!T M;R!A=F]I9"!P<F]B;&5M<R!W:&5N#0H)"0EO<FEG:6YA;"!T>7!E(&ES(&QO M;F<@9&]U8FQE('=H870@=V]U;&0@8V%S=64@97)R;W(@;V8@='=O(&1I9F9E M<F5N= T*"0D)9&5F:6YI=&EO;G,@;V8@9G5N8W1I;VYS+@T*"51/1$\Z#0H) M"3$I"4%D9"!I;F1E>"!O<&5R871O<B!F;W(@8V]M<&]N96YT<R!O9B!C;VQO M<BX@5&AI<R!W;W5L9"!R97%U:7)E('1O#0H)"0EW<FET92!A(&-L87-S('=H M:6-H(&)E:&%V97,@;&EK92!L;VYG(&1O=6)L92!B=70@;VX@=W)I=&4-"@D) M"2AO<&5R871O<B ]*2!W<FET97,@=&\@8V]R<F5C="!C;VUP;VYE;G0N#0HJ M+PT*(VEF;F1E9B!"3T]35%]#3TQ/4E](4% -"B-D969I;F4@0D]/4U1?0T], M3U)?2%!0#0H-"@T*(VEN8VQU9&4@/&EO<W1R96%M/@T*(VEN8VQU9&4@/&QI M;6ET<SX-"B-I;F-L=61E(#QS=&1E>&-E<'0^#0H-"@T*;F%M97-P86-E(&)O M;W-T('L-"@T*#0H);F%M97-P86-E(&-O;&]R('L-"@T*#0H)"6-L87-S(&)A M9%]C;VUP;VYE;G0@.B!P=6)L:6,@<W1D.CIO=71?;V9?<F%N9V4@>PT*"0EP M=6)L:6,Z#0H)"0EB861?8V]M<&]N96YT*&-O;G-T(&EN="!I*2 Z('-T9#HZ M;W5T7V]F7W)A;F=E*")B860@8V]L;W(@8V]M<&]N96YT(&EN9&5X(BDL(%]I M;F1E>"AI*2![?3L-"@D)"6EN="!I;F1E>"@I(&-O;G-T('L-"@D)"0ER971U M<FX@7VEN9&5X.PT*"0D)?0T*"0EP<FEV871E.@T*"0D):6YT(%]I;F1E>#L- M"@D)?3L-"@T*#0H)"2\O($Y/5$4@,2DN#0H)"6-L87-S(&)A9%]V86QU92 Z M('!U8FQI8R!S=&0Z.B!D;VUA:6Y?97)R;W(@>PT*"0EP=6)L:6,Z#0H)"0EB M861?=F%L=64H8V]N<W0@:6YT(&DI(#H@<W1D.CID;VUA:6Y?97)R;W(H(F)A M9"!C;VQO<B!C;VUP;VYE;G0@=F%L=64B*2P@7VEN9&5X*&DI('M].PT*"0D) M:6YT(&EN9&5X*"D@8V]N<W0@>PT*"0D)"7)E='5R;B!?:6YD97@[#0H)"0E] M#0H)"7!R:79A=&4Z#0H)"0EI;G0@7VEN9&5X.PT*"0E].PT*#0H-"@D);F%M M97-P86-E(')G8B![#0H-"@T*"0D)=&5M<&QA=&4\='EP96YA;64@0V]M<&]N M96YT<SX@8VQA<W,@8V]M<&]N96YT<U]T<F%I=',@>PT*"0D)<'5B;&EC.@T* M"0D)"71Y<&5D968@:6YT(')?='EP93L-"@D)"0ET>7!E9&5F(&EN="!G7W1Y M<&4[#0H)"0D)='EP961E9B!I;G0@8E]T>7!E.PT*"0D)"7-T871I8R!C;VYS M="!R7W1Y<&4@<E]M:6X@/2 P.PT*"0D)"7-T871I8R!C;VYS="!R7W1Y<&4@ M<E]M87@@/2 P.PT*"0D)"7-T871I8R!C;VYS="!G7W1Y<&4@9U]M:6X@/2 P M.PT*"0D)"7-T871I8R!C;VYS="!G7W1Y<&4@9U]M87@@/2 P.PT*"0D)"7-T M871I8R!C;VYS="!B7W1Y<&4@8E]M:6X@/2 P.PT*"0D)"7-T871I8R!C;VYS M="!B7W1Y<&4@8E]M87@@/2 P.PT*"0D)?3L-"@T*#0H)"0ET96UP;&%T93QT M>7!E;F%M92!.=6UB97)?='EP93X@<W1R=6-T(&-O;7!O;F5N='-?<F=B('L- M"@D)"7!U8FQI8SH-"@D)"0E.=6UB97)?='EP92!R*"D@8V]N<W0@>PT*"0D) M"0ER971U<FX@=&AI<RT^7V-O;7!O;F5N='-;,%T[#0H)"0D)?0T*"0D)"79O M:60@<BAC;VYS="!.=6UB97)?='EP92!V86QU92D@>PT*"0D)"0ET:&ES+3Y? M8V]M<&]N96YT<ULP72 ]('9A;'5E.PT*"0D)"7T-"@D)"0E.=6UB97)?='EP M92!G*"D@8V]N<W0@>PT*"0D)"0ER971U<FX@=&AI<RT^7V-O;7!O;F5N='-; M,5T[#0H)"0D)?0T*"0D)"79O:60@9RAC;VYS="!.=6UB97)?='EP92!V86QU M92D@>PT*"0D)"0ET:&ES+3Y?8V]M<&]N96YT<ULQ72 ]('9A;'5E.PT*"0D) M"7T-"@D)"0E.=6UB97)?='EP92!B*"D@8V]N<W0@>PT*"0D)"0ER971U<FX@ M=&AI<RT^7V-O;7!O;F5N='-;,ET[#0H)"0D)?0T*"0D)"79O:60@8BAC;VYS M="!.=6UB97)?='EP92!V86QU92D@>PT*"0D)"0ET:&ES+3Y?8V]M<&]N96YT M<ULR72 ]('9A;'5E.PT*"0D)"7T-"@D)"7!R:79A=&4Z#0H)"0D)3G5M8F5R M7W1Y<&4@7V-O;7!O;F5N='-;,UT[#0H)"0E].PT*#0H-"@D)"2\O($Y/5$4@ M,RDL(#0I#0H)"0ET96UP;&%T93QT>7!E;F%M92!.=6UB97)?='EP93X@8VQA M<W,@8V]M<&]N96YT<U]T<F%I=',\8V]M<&]N96YT<U]R9V(\3G5M8F5R7W1Y M<&4^(#X@>PT*"0D)<'5B;&EC.@T*"0D)"71Y<&5D968@3G5M8F5R7W1Y<&4@ M<E]T>7!E.PT*"0D)"71Y<&5D968@3G5M8F5R7W1Y<&4@9U]T>7!E.PT*"0D) M"71Y<&5D968@3G5M8F5R7W1Y<&4@8E]T>7!E.PT*"0D)"7-T871I8R!C;VYS M="!R7W1Y<&4@<E]M:6X[#0H)"0D)<W1A=&EC(&-O;G-T(')?='EP92!R7VUA M>#L-"@D)"0ES=&%T:6,@8V]N<W0@9U]T>7!E(&=?;6EN.PT*"0D)"7-T871I M8R!C;VYS="!G7W1Y<&4@9U]M87@[#0H)"0D)<W1A=&EC(&-O;G-T(&)?='EP M92!B7VUI;CL-"@D)"0ES=&%T:6,@8V]N<W0@8E]T>7!E(&)?;6%X.PT*"0D) M?3L-"@T*#0H)"0ET96UP;&%T93QT>7!E;F%M92!.=6UB97)?='EP93X@8V]N M<W0@='EP96YA;64@8V]M<&]N96YT<U]T<F%I=',\8V]M<&]N96YT<U]R9V(\ M3G5M8F5R7W1Y<&4^(#XZ.G)?='EP92!C;VUP;VYE;G1S7W1R86ET<SQC;VUP M;VYE;G1S7W)G8CQ.=6UB97)?='EP93X@/CHZ<E]M:6X@/2!N=6UE<FEC7VQI M;6ET<SQ.=6UB97)?='EP93XZ.FUI;B@I.PT*"0D)=&5M<&QA=&4\='EP96YA M;64@3G5M8F5R7W1Y<&4^(&-O;G-T('1Y<&5N86UE(&-O;7!O;F5N='-?=')A M:71S/&-O;7!O;F5N='-?<F=B/$YU;6)E<E]T>7!E/B ^.CIR7W1Y<&4@8V]M M<&]N96YT<U]T<F%I=',\8V]M<&]N96YT<U]R9V(\3G5M8F5R7W1Y<&4^(#XZ M.G)?;6%X(#T@;G5M97)I8U]L:6UI=',\3G5M8F5R7W1Y<&4^.CIM87@H*3L- M"@D)"71E;7!L871E/'1Y<&5N86UE($YU;6)E<E]T>7!E/B!C;VYS="!T>7!E M;F%M92!C;VUP;VYE;G1S7W1R86ET<SQC;VUP;VYE;G1S7W)G8CQ.=6UB97)? M='EP93X@/CHZ9U]T>7!E(&-O;7!O;F5N='-?=')A:71S/&-O;7!O;F5N='-? M<F=B/$YU;6)E<E]T>7!E/B ^.CIG7VUI;B ](&YU;65R:6-?;&EM:71S/$YU M;6)E<E]T>7!E/CHZ;6EN*"D[#0H)"0ET96UP;&%T93QT>7!E;F%M92!.=6UB M97)?='EP93X@8V]N<W0@='EP96YA;64@8V]M<&]N96YT<U]T<F%I=',\8V]M M<&]N96YT<U]R9V(\3G5M8F5R7W1Y<&4^(#XZ.F=?='EP92!C;VUP;VYE;G1S M7W1R86ET<SQC;VUP;VYE;G1S7W)G8CQ.=6UB97)?='EP93X@/CHZ9U]M87@@ M/2!N=6UE<FEC7VQI;6ET<SQ.=6UB97)?='EP93XZ.FUA>"@I.PT*"0D)=&5M M<&QA=&4\='EP96YA;64@3G5M8F5R7W1Y<&4^(&-O;G-T('1Y<&5N86UE(&-O M;7!O;F5N='-?=')A:71S/&-O;7!O;F5N='-?<F=B/$YU;6)E<E]T>7!E/B ^ M.CIB7W1Y<&4@8V]M<&]N96YT<U]T<F%I=',\8V]M<&]N96YT<U]R9V(\3G5M M8F5R7W1Y<&4^(#XZ.F)?;6EN(#T@;G5M97)I8U]L:6UI=',\3G5M8F5R7W1Y M<&4^.CIM:6XH*3L-"@D)"71E;7!L871E/'1Y<&5N86UE($YU;6)E<E]T>7!E M/B!C;VYS="!T>7!E;F%M92!C;VUP;VYE;G1S7W1R86ET<SQC;VUP;VYE;G1S M7W)G8CQ.=6UB97)?='EP93X@/CHZ8E]T>7!E(&-O;7!O;F5N='-?=')A:71S M/&-O;7!O;F5N='-?<F=B/$YU;6)E<E]T>7!E/B ^.CIB7VUA>" ](&YU;65R M:6-?;&EM:71S/$YU;6)E<E]T>7!E/CHZ;6%X*"D[#0H-"@T*"0D)=&5M<&QA M=&4\/B!C;&%S<R!C;VUP;VYE;G1S7W1R86ET<SQC;VUP;VYE;G1S7W)G8CQF M;&]A=#X@/B![#0H)"0EP=6)L:6,Z#0H)"0D)='EP961E9B!F;&]A="!R7W1Y M<&4[#0H)"0D)='EP961E9B!F;&]A="!G7W1Y<&4[#0H)"0D)='EP961E9B!F M;&]A="!B7W1Y<&4[#0H)"0D)<W1A=&EC(&-O;G-T(')?='EP92!R7VUI;CL- M"@D)"0ES=&%T:6,@8V]N<W0@<E]T>7!E(')?;6%X.PT*"0D)"7-T871I8R!C M;VYS="!G7W1Y<&4@9U]M:6X[#0H)"0D)<W1A=&EC(&-O;G-T(&=?='EP92!G M7VUA>#L-"@D)"0ES=&%T:6,@8V]N<W0@8E]T>7!E(&)?;6EN.PT*"0D)"7-T M871I8R!C;VYS="!B7W1Y<&4@8E]M87@[#0H)"0E].PT*#0H-"@D)"71E;7!L M871E/#X@8VQA<W,@8V]M<&]N96YT<U]T<F%I=',\8V]M<&]N96YT<U]R9V(\ M9&]U8FQE/B ^('L-"@D)"7!U8FQI8SH-"@D)"0ET>7!E9&5F(&1O=6)L92!R M7W1Y<&4[#0H)"0D)='EP961E9B!D;W5B;&4@9U]T>7!E.PT*"0D)"71Y<&5D M968@9&]U8FQE(&)?='EP93L-"@D)"0ES=&%T:6,@8V]N<W0@<E]T>7!E(')? M;6EN.PT*"0D)"7-T871I8R!C;VYS="!R7W1Y<&4@<E]M87@[#0H)"0D)<W1A M=&EC(&-O;G-T(&=?='EP92!G7VUI;CL-"@D)"0ES=&%T:6,@8V]N<W0@9U]T M>7!E(&=?;6%X.PT*"0D)"7-T871I8R!C;VYS="!B7W1Y<&4@8E]M:6X[#0H) M"0D)<W1A=&EC(&-O;G-T(&)?='EP92!B7VUA>#L-"@D)"7T[#0H-"@T*"0D) M=&5M<&QA=&4\/B!C;&%S<R!C;VUP;VYE;G1S7W1R86ET<SQC;VUP;VYE;G1S M7W)G8CQL;VYG(&1O=6)L93X@/B![#0H)"0EP=6)L:6,Z#0H)"0D)='EP961E M9B!L;VYG(&1O=6)L92!R7W1Y<&4[#0H)"0D)='EP961E9B!L;VYG(&1O=6)L M92!G7W1Y<&4[#0H)"0D)='EP961E9B!L;VYG(&1O=6)L92!B7W1Y<&4[#0H) M"0D)<W1A=&EC(&-O;G-T(')?='EP92!R7VUI;CL-"@D)"0ES=&%T:6,@8V]N M<W0@<E]T>7!E(')?;6%X.PT*"0D)"7-T871I8R!C;VYS="!G7W1Y<&4@9U]M M:6X[#0H)"0D)<W1A=&EC(&-O;G-T(&=?='EP92!G7VUA>#L-"@D)"0ES=&%T M:6,@8V]N<W0@8E]T>7!E(&)?;6EN.PT*"0D)"7-T871I8R!C;VYS="!B7W1Y M<&4@8E]M87@[#0H)"0E].PT*#0H-"@D)"7-T<G5C="!C;VUP;VYE;G1S7S,R M8B![#0H)"0EP=6)L:6,Z#0H)"0D):6YT('(H*2!C;VYS="![#0H)"0D)"7)E M='5R;B!T:&ES+3Y?<CL-"@D)"0E]#0H)"0D)=F]I9"!R*&-O;G-T(&EN="!V M86QU92D@>PT*"0D)"0ET:&ES+3Y?<B ]('9A;'5E.PT*"0D)"7T-"@D)"0EI M;G0@9R@I(&-O;G-T('L-"@D)"0D)<F5T=7)N('1H:7,M/E]G.PT*"0D)"7T- M"@D)"0EV;VED(&<H8V]N<W0@:6YT('9A;'5E*2![#0H)"0D)"71H:7,M/E]G M(#T@=F%L=64[#0H)"0D)?0T*"0D)"6EN="!B*"D@8V]N<W0@>PT*"0D)"0ER M971U<FX@=&AI<RT^7V([#0H)"0D)?0T*"0D)"79O:60@8BAC;VYS="!I;G0@ M=F%L=64I('L-"@D)"0D)=&AI<RT^7V(@/2!V86QU93L-"@D)"0E]#0H)"0EP M<FEV871E.@T*"0D)"6EN="!?<B Z(#@[#0H)"0D):6YT(%]G(#H@.#L-"@D) M"0EI;G0@7V(@.B X.PT*"0D)"6EN=" Z(#@[#0H)"0E].PT*#0H-"@D)"71E M;7!L871E/#X@8VQA<W,@8V]M<&]N96YT<U]T<F%I=',\8V]M<&]N96YT<U\S M,F(^('L-"@D)"7!U8FQI8SH-"@D)"0ET>7!E9&5F(&EN="!R7W1Y<&4[#0H) M"0D)='EP961E9B!I;G0@9U]T>7!E.PT*"0D)"71Y<&5D968@:6YT(&)?='EP M93L-"@D)"0ES=&%T:6,@8V]N<W0@<E]T>7!E(')?;6EN(#T@,#L-"@D)"0ES M=&%T:6,@8V]N<W0@<E]T>7!E(')?;6%X(#T@,#L-"@D)"0ES=&%T:6,@8V]N M<W0@9U]T>7!E(&=?;6EN(#T@,#L-"@D)"0ES=&%T:6,@8V]N<W0@9U]T>7!E M(&=?;6%X(#T@,C4U.PT*"0D)"7-T871I8R!C;VYS="!B7W1Y<&4@8E]M:6X@ M/2 R-34[#0H)"0D)<W1A=&EC(&-O;G-T(&)?='EP92!B7VUA>" ](#(U-3L- M"@D)"7T[#0H-"@T*"0D)<W1R=6-T(&-O;7!O;F5N='-?,S)B7VEN=B![#0H) M"0EP=6)L:6,Z#0H)"0D):6YT('(H*2!C;VYS="![#0H)"0D)"7)E='5R;B!T M:&ES+3Y?<CL-"@D)"0E]#0H)"0D)=F]I9"!R*&-O;G-T(&EN="!V86QU92D@ M>PT*"0D)"0ET:&ES+3Y?<B ]('9A;'5E.PT*"0D)"7T-"@D)"0EI;G0@9R@I M(&-O;G-T('L-"@D)"0D)<F5T=7)N('1H:7,M/E]G.PT*"0D)"7T-"@D)"0EV M;VED(&<H8V]N<W0@:6YT('9A;'5E*2![#0H)"0D)"71H:7,M/E]G(#T@=F%L M=64[#0H)"0D)?0T*"0D)"6EN="!B*"D@8V]N<W0@>PT*"0D)"0ER971U<FX@ M=&AI<RT^7V([#0H)"0D)?0T*"0D)"79O:60@8BAC;VYS="!I;G0@=F%L=64I M('L-"@D)"0D)=&AI<RT^7V(@/2!V86QU93L-"@D)"0E]#0H)"0EP<FEV871E M.@T*"0D)"6EN=" Z(#@[#0H)"0D):6YT(%]B(#H@.#L-"@D)"0EI;G0@7V<@ M.B X.PT*"0D)"6EN="!?<B Z(#@[#0H)"0E].PT*#0H-"@D)"71E;7!L871E M/#X@8VQA<W,@8V]M<&]N96YT<U]T<F%I=',\8V]M<&]N96YT<U\S,F)?:6YV M/B![#0H)"0EP=6)L:6,Z#0H)"0D)='EP961E9B!I;G0@<E]T>7!E.PT*"0D) M"71Y<&5D968@:6YT(&=?='EP93L-"@D)"0ET>7!E9&5F(&EN="!B7W1Y<&4[ M#0H)"0D)<W1A=&EC(&-O;G-T(')?='EP92!R7VUI;B ](# [#0H)"0D)<W1A M=&EC(&-O;G-T(')?='EP92!R7VUA>" ](# [#0H)"0D)<W1A=&EC(&-O;G-T M(&=?='EP92!G7VUI;B ](# [#0H)"0D)<W1A=&EC(&-O;G-T(&=?='EP92!G M7VUA>" ](#(U-3L-"@D)"0ES=&%T:6,@8V]N<W0@8E]T>7!E(&)?;6EN(#T@ M,C4U.PT*"0D)"7-T871I8R!C;VYS="!B7W1Y<&4@8E]M87@@/2 R-34[#0H) M"0E].PT*#0H-"@D)"2\O($Y/5$4@,BD-"@D)"71E;7!L871E/'1Y<&5N86UE M($-O;7!O;F5N=',L('1Y<&5N86UE($-O;7!O;F5N='-?=')A:71S(#T@8V]M M<&]N96YT<U]T<F%I=',\0V]M<&]N96YT<SX@/B!C;&%S<R!C;VQO<B![#0H) M"0EP=6)L:6,Z#0H)"0D)8V]L;W(H*2 Z(%]C;VUP;VYE;G1S*"D@>PT*"0D) M"0ET:&ES+3YA<W-I9VY?<F=B*# N,&PL(# N,&PL(# N,&PI.PT*"0D)"7T- M"@D)"0EC;VQO<BAC;VYS="!L;VYG(&1O=6)L92!R+"!C;VYS="!L;VYG(&1O M=6)L92!G+"!C;VYS="!L;VYG(&1O=6)L92!B*2 Z(%]C;VUP;VYE;G1S*"D@ M>PT*"0D)"0ET:&ES+3YA<W-I9VY?<F=B*'(L(&<L(&(I.PT*"0D)"7T-"@D) M"0EC;VQO<BAC;VYS="!#;VUP;VYE;G1S(&-O;7!O;F5N=',I(#H@7V-O;7!O M;F5N=',H8V]M<&]N96YT<RD@>WT[#0H)"0D)=&5M<&QA=&4\='EP96YA;64@ M0V]M<&]N96YT<U\R+"!T>7!E;F%M92!#;VUP;VYE;G1S7W1R86ET<U\R/B!C M;VQO<BAC;VYS="!C;VQO<CQ#;VUP;VYE;G1S7S(L($-O;7!O;F5N='-?=')A M:71S7S(^)B!C*2 Z(%]C;VUP;VYE;G1S*"D@>PT*"0D)"0ET:&ES+3YA<W-I M9VY?8RAC*3L-"@D)"0E]#0H)"0D)8V]L;W(\0V]M<&]N96YT<RP@0V]M<&]N M96YT<U]T<F%I=',^)B!O<&5R871O<B ]*&-O;G-T($-O;7!O;F5N=',@8V]M M<&]N96YT<RD@>PT*"0D)"0ET:&ES+3Y?8V]M<&]N96YT<R ](&-O;7!O;F5N M=',[#0H)"0D)"7)E='5R;B J=&AI<SL-"@D)"0E]#0H)"0D)=&5M<&QA=&4\ M='EP96YA;64@0V]M<&]N96YT<U\R+"!T>7!E;F%M92!#;VUP;VYE;G1S7W1R M86ET<U\R/B!C;VQO<CQ#;VUP;VYE;G1S+"!#;VUP;VYE;G1S7W1R86ET<SXF M(&]P97)A=&]R(#TH8V]N<W0@8V]L;W(\0V]M<&]N96YT<U\R+"!#;VUP;VYE M;G1S7W1R86ET<U\R/B8@8RD@>PT*"0D)"0ET:&ES+3YA<W-I9VY?8RAC*3L- M"@D)"0D)<F5T=7)N("IT:&ES.PT*"0D)"7T-"@D)"0EC;VQO<CQ#;VUP;VYE M;G1S+"!#;VUP;VYE;G1S7W1R86ET<SXF(&-O;7!O;F5N=',H8V]N<W0@;&]N M9R!D;W5B;&4@<BP@8V]N<W0@;&]N9R!D;W5B;&4@9RP@8V]N<W0@;&]N9R!D M;W5B;&4@8BD@>PT*"0D)"0ET:&ES+3YA<W-I9VY?<F=B*'(L(&<L(&(I.PT* M"0D)"0ER971U<FX@*G1H:7,[#0H)"0D)?0T*"0D)"6-O;&]R/$-O;7!O;F5N M=',L($-O;7!O;F5N='-?=')A:71S/B8@8V]M<&]N96YT<U]C*&-O;G-T(&QO M;F<@9&]U8FQE('(L(&-O;G-T(&QO;F<@9&]U8FQE(&<L(&-O;G-T(&QO;F<@ M9&]U8FQE(&(I('L-"@D)"0D)=&AI<RT^87-S:6=N7W)G8BAC;VQO<CHZ8V]R M<F5C=%]V86QU92AR*2P@8V]L;W(Z.F-O<G)E8W1?=F%L=64H9RDL(&-O;&]R M.CIC;W)R96-T7W9A;'5E*&(I*3L-"@D)"0D)<F5T=7)N("IT:&ES.PT*"0D) M"7T-"@D)"0EC;VQO<CQ#;VUP;VYE;G1S+"!#;VUP;VYE;G1S7W1R86ET<SXF M(&-O;7!O;F5N='-?92AC;VYS="!L;VYG(&1O=6)L92!R+"!C;VYS="!L;VYG M(&1O=6)L92!G+"!C;VYS="!L;VYG(&1O=6)L92!B*2![#0H)"0D)"6EF*'(@ M(3T@8V]L;W(Z.F-O<G)E8W1?=F%L=64H<BDI('L-"@D)"0D)"71H<F]W(&)O M;W-T.CIC;VQO<CHZ8F%D7W9A;'5E*# I.PT*"0D)"0E]#0H)"0D)"6EF*&<@ M(3T@8V]L;W(Z.F-O<G)E8W1?=F%L=64H9RDI('L-"@D)"0D)"71H<F]W(&)O M;W-T.CIC;VQO<CHZ8F%D7W9A;'5E*#$I.PT*"0D)"0E]#0H)"0D)"6EF*&(@ M(3T@8V]L;W(Z.F-O<G)E8W1?=F%L=64H8BDI('L-"@D)"0D)"71H<F]W(&)O M;W-T.CIC;VQO<CHZ8F%D7W9A;'5E*#(I.PT*"0D)"0E]#0H)"0D)"71H:7,M M/F%S<VEG;E]R9V(H<BP@9RP@8BD[#0H)"0D)"7)E='5R;B J=&AI<SL-"@D) M"0E]#0H)"0D)8V]L;W(\0V]M<&]N96YT<RP@0V]M<&]N96YT<U]T<F%I=',^ M)B!C;VUP;VYE;G1S7V\H8V]N<W0@='EP96YA;64@0V]M<&]N96YT<U]T<F%I M=',Z.G)?='EP92!R+"!C;VYS="!T>7!E;F%M92!#;VUP;VYE;G1S7W1R86ET M<SHZ9U]T>7!E(&<L(&-O;G-T('1Y<&5N86UE($-O;7!O;F5N='-?=')A:71S M.CIB7W1Y<&4@8BD@>PT*"0D)"0ET:&ES+3Y?8V]M<&]N96YT<RYR*'(I.PT* M"0D)"0ET:&ES+3Y?8V]M<&]N96YT<RYG*&<I.PT*"0D)"0ET:&ES+3Y?8V]M M<&]N96YT<RYB*&(I.PT*"0D)"0ER971U<FX@*G1H:7,[#0H)"0D)?0T*"0D) M"6-O;&]R/$-O;7!O;F5N=',L($-O;7!O;F5N='-?=')A:71S/B8@8V]M<&]N M96YT<U]O7V,H8V]N<W0@='EP96YA;64@0V]M<&]N96YT<U]T<F%I=',Z.G)? M='EP92!R+"!C;VYS="!T>7!E;F%M92!#;VUP;VYE;G1S7W1R86ET<SHZ9U]T M>7!E(&<L(&-O;G-T('1Y<&5N86UE($-O;7!O;F5N='-?=')A:71S.CIB7W1Y M<&4@8BD@>PT*"0D)"0ET:&ES+3Y?8V]M<&]N96YT<RYR*&-O;&]R.CIC;W)R M96-T7W9A;'5E7W(H<BDI.PT*"0D)"0ET:&ES+3Y?8V]M<&]N96YT<RYG*&-O M;&]R.CIC;W)R96-T7W9A;'5E7V<H9RDI.PT*"0D)"0ET:&ES+3Y?8V]M<&]N M96YT<RYB*&-O;&]R.CIC;W)R96-T7W9A;'5E7V(H8BDI.PT*"0D)"0ER971U M<FX@*G1H:7,[#0H)"0D)?0T*"0D)"6-O;&]R/$-O;7!O;F5N=',L($-O;7!O M;F5N='-?=')A:71S/B8@8V]M<&]N96YT<U]O7V4H8V]N<W0@='EP96YA;64@ M0V]M<&]N96YT<U]T<F%I=',Z.G)?='EP92!R+"!C;VYS="!T>7!E;F%M92!# M;VUP;VYE;G1S7W1R86ET<SHZ9U]T>7!E(&<L(&-O;G-T('1Y<&5N86UE($-O M;7!O;F5N='-?=')A:71S.CIB7W1Y<&4@8BD@>PT*"0D)"0EI9BAR("$](&-O M;&]R.CIC;W)R96-T7W9A;'5E7W(H<BDI('L-"@D)"0D)"71H<F]W(&)O;W-T M.CIC;VQO<CHZ8F%D7W9A;'5E*# I.PT*"0D)"0E]#0H)"0D)"6EF*&<@(3T@ M8V]L;W(Z.F-O<G)E8W1?=F%L=65?9RAG*2D@>PT*"0D)"0D)=&AR;W<@8F]O M<W0Z.F-O;&]R.CIB861?=F%L=64H,2D[#0H)"0D)"7T-"@D)"0D):68H8B A M/2!C;VQO<CHZ8V]R<F5C=%]V86QU95]B*&(I*2![#0H)"0D)"0ET:')O=R!B M;V]S=#HZ8V]L;W(Z.F)A9%]V86QU92@R*3L-"@D)"0D)?0T*"0D)"0ET:&ES M+3Y?8V]M<&]N96YT<RYR*'(I.PT*"0D)"0ET:&ES+3Y?8V]M<&]N96YT<RYG M*&<I.PT*"0D)"0ET:&ES+3Y?8V]M<&]N96YT<RYB*&(I.PT*"0D)"0ER971U M<FX@*G1H:7,[#0H)"0D)?0T*"0D)"6QO;F<@9&]U8FQE(&-O;7!O;F5N="AC M;VYS="!I;G0@:6YD97@I(&-O;G-T('L-"@D)"0D)<W=I=&-H*&EN9&5X*2![ M#0H)"0D)"6-A<V4@,#H-"@D)"0D)"7)E='5R;B!T:&ES+3YR*"D[#0H)"0D) M"6-A<V4@,3H-"@D)"0D)"7)E='5R;B!T:&ES+3YG*"D[#0H)"0D)"61E9F%U M;'0Z#0H)"0D)"0ER971U<FX@=&AI<RT^8B@I.PT*"0D)"0E]#0H)"0D)?0T* M"0D)"6QO;F<@9&]U8FQE(&-O;7!O;F5N=%]E*&-O;G-T(&EN="!I;F1E>"D@ M8V]N<W0@>PT*"0D)"0ES=VET8V@H:6YD97@I('L-"@D)"0D)8V%S92 P.@T* M"0D)"0D)<F5T=7)N('1H:7,M/G(H*3L-"@D)"0D)8V%S92 Q.@T*"0D)"0D) M<F5T=7)N('1H:7,M/F<H*3L-"@D)"0D)8V%S92 R.@T*"0D)"0D)<F5T=7)N M('1H:7,M/F(H*3L-"@D)"0D)9&5F875L=#H-"@D)"0D)"71H<F]W(&)O;W-T M.CIC;VQO<CHZ8F%D7V-O;7!O;F5N="AI;F1E>"D[#0H)"0D)"7T-"@D)"0E] M#0H)"0D)=F]I9"!C;VUP;VYE;G0H8V]N<W0@:6YT(&EN9&5X+"!C;VYS="!L M;VYG(&1O=6)L92!V86QU92D@>PT*"0D)"0ES=VET8V@H:6YD97@I('L-"@D) M"0D)8V%S92 P.@T*"0D)"0D)=&AI<RT^<BAV86QU92D[#0H)"0D)"0ER971U M<FX[#0H)"0D)"6-A<V4@,3H-"@D)"0D)"71H:7,M/F<H=F%L=64I.PT*"0D) M"0D)<F5T=7)N.PT*"0D)"0ED969A=6QT.@T*"0D)"0D)=&AI<RT^8BAV86QU M92D[#0H)"0D)"0ER971U<FX[#0H)"0D)"7T-"@D)"0E]#0H)"0D)=F]I9"!C M;VUP;VYE;G1?8RAC;VYS="!I;G0@:6YD97@L(&-O;G-T(&QO;F<@9&]U8FQE M('9A;'5E*2![#0H)"0D)"7-W:71C:"AI;F1E>"D@>PT*"0D)"0EC87-E(# Z M#0H)"0D)"0ET:&ES+3YR7V,H=F%L=64I.PT*"0D)"0D)<F5T=7)N.PT*"0D) M"0EC87-E(#$Z#0H)"0D)"0ET:&ES+3YG7V,H=F%L=64I.PT*"0D)"0D)<F5T M=7)N.PT*"0D)"0ED969A=6QT.@T*"0D)"0D)=&AI<RT^8E]C*'9A;'5E*3L- M"@D)"0D)"7)E='5R;CL-"@D)"0D)?0T*"0D)"7T-"@D)"0EV;VED(&-O;7!O M;F5N=%]E*&-O;G-T(&EN="!I;F1E>"P@8V]N<W0@;&]N9R!D;W5B;&4@=F%L M=64I('L-"@D)"0D)<W=I=&-H*&EN9&5X*2![#0H)"0D)"6-A<V4@,#H-"@D) M"0D)"71H:7,M/G)?92AV86QU92D[#0H)"0D)"0ER971U<FX[#0H)"0D)"6-A M<V4@,3H-"@D)"0D)"71H:7,M/F=?92AV86QU92D[#0H)"0D)"0ER971U<FX[ M#0H)"0D)"6-A<V4@,CH-"@D)"0D)"71H:7,M/F)?92AV86QU92D[#0H)"0D) M"0ER971U<FX[#0H)"0D)"61E9F%U;'0Z#0H)"0D)"0ET:')O=R!B;V]S=#HZ M8V]L;W(Z.F)A9%]C;VUP;VYE;G0H:6YD97@I.PT*"0D)"0E]#0H)"0D)?0T* M"0D)"79O:60@8V]M<&]N96YT7V-E*&-O;G-T(&EN="!I;F1E>"P@8V]N<W0@ M;&]N9R!D;W5B;&4@=F%L=64I('L-"@D)"0D)<W=I=&-H*&EN9&5X*2![#0H) M"0D)"6-A<V4@,#H-"@D)"0D)"71H:7,M/G)?8RAV86QU92D[#0H)"0D)"0ER M971U<FX[#0H)"0D)"6-A<V4@,3H-"@D)"0D)"71H:7,M/F=?8RAV86QU92D[ M#0H)"0D)"0ER971U<FX[#0H)"0D)"6-A<V4@,CH-"@D)"0D)"71H:7,M/F)? M8RAV86QU92D[#0H)"0D)"0ER971U<FX[#0H)"0D)"61E9F%U;'0Z#0H)"0D) M"0ET:')O=R!B;V]S=#HZ8V]L;W(Z.F)A9%]C;VUP;VYE;G0H:6YD97@I.PT* M"0D)"0E]#0H)"0D)?0T*"0D)"6QO;F<@9&]U8FQE('(H*2!C;VYS="![#0H) M"0D)"7)E='5R;B!S=&%T:6-?8V%S=#QL;VYG(&1O=6)L93XH=&AI<RT^7V-O M;7!O;F5N=',N<B@I*2]S=&%T:6-?8V%S=#QL;VYG(&1O=6)L93XH<W1A=&EC M7V-A<W0\;&]N9R!D;W5B;&4^*$-O;7!O;F5N='-?=')A:71S.CIR7VUA>"U# M;VUP;VYE;G1S7W1R86ET<SHZ<E]M:6XI*3L-"@D)"0E]#0H)"0D)='EP96YA M;64@0V]M<&]N96YT<U]T<F%I=',Z.G)?='EP92!R7V\H*2!C;VYS="![#0H) M"0D)"7)E='5R;B!T:&ES+3Y?8V]M<&]N96YT<RYR*"D[#0H)"0D)?0T*"0D) M"79O:60@<BAC;VYS="!L;VYG(&1O=6)L92!V86QU92D@>PT*"0D)"0ET:&ES M+3YA<W-I9VY?<BAV86QU92D[#0H)"0D)?0T*"0D)"79O:60@<E]C*&-O;G-T M(&QO;F<@9&]U8FQE('9A;'5E*2![#0H)"0D)"71H:7,M/F%S<VEG;E]R*&-O M;&]R.CIC;W)R96-T7W9A;'5E*'9A;'5E*2D[#0H)"0D)?0T*"0D)"79O:60@ M<E]E*&-O;G-T(&QO;F<@9&]U8FQE('9A;'5E*2![#0H)"0D)"6EF*&-O;&]R M.CIC;W)R96-T7W9A;'5E*'9A;'5E*2 A/2!V86QU92D@>PT*"0D)"0D)=&AR M;W<@8F]O<W0Z.F-O;&]R.CIB861?=F%L=64H,"D[#0H)"0D)"7T-"@D)"0D) M=&AI<RT^87-S:6=N7W(H8V]L;W(Z.F-O<G)E8W1?=F%L=64H=F%L=64I*3L- M"@D)"0E]#0H)"0D)=F]I9"!R7V\H8V]N<W0@='EP96YA;64@0V]M<&]N96YT M<U]T<F%I=',Z.G)?='EP92!V86QU92D@>PT*"0D)"0ET:&ES+3Y?8V]M<&]N M96YT<RYR*'9A;'5E*3L-"@D)"0E]#0H)"0D)=F]I9"!R7V]?8RAC;VYS="!T M>7!E;F%M92!#;VUP;VYE;G1S7W1R86ET<SHZ<E]T>7!E('9A;'5E*2![#0H) M"0D)"71H:7,M/E]C;VUP;VYE;G1S+G(H8V]L;W(Z.F-O<G)E8W1?=F%L=65? M<BAV86QU92DI.PT*"0D)"7T-"@D)"0EV;VED(')?;U]E*&-O;G-T('1Y<&5N M86UE($-O;7!O;F5N='-?=')A:71S.CIR7W1Y<&4@=F%L=64I('L-"@D)"0D) M:68H=F%L=64@(3T@8V]L;W(Z.F-O<G)E8W1?=F%L=65?<BAV86QU92DI('L- M"@D)"0D)"71H<F]W(&)O;W-T.CIC;VQO<CHZ8F%D7W9A;'5E*# I.PT*"0D) M"0E]#0H)"0D)"71H:7,M/E]C;VUP;VYE;G1S+G(H=F%L=64I.PT*"0D)"7T- M"@D)"0EL;VYG(&1O=6)L92!G*"D@8V]N<W0@>PT*"0D)"0ER971U<FX@<W1A M=&EC7V-A<W0\;&]N9R!D;W5B;&4^*'1H:7,M/E]C;VUP;VYE;G1S+F<H*2DO M<W1A=&EC7V-A<W0\;&]N9R!D;W5B;&4^*'-T871I8U]C87-T/&QO;F<@9&]U M8FQE/BA#;VUP;VYE;G1S7W1R86ET<SHZ9U]M87@M0V]M<&]N96YT<U]T<F%I M=',Z.F=?;6EN*2D[#0H)"0D)?0T*"0D)"71Y<&5N86UE($-O;7!O;F5N='-? M=')A:71S.CIG7W1Y<&4@9U]O*"D@8V]N<W0@>PT*"0D)"0ER971U<FX@=&AI M<RT^7V-O;7!O;F5N=',N9R@I.PT*"0D)"7T-"@D)"0EV;VED(&<H8V]N<W0@ M;&]N9R!D;W5B;&4@=F%L=64I('L-"@D)"0D)=&AI<RT^87-S:6=N7V<H=F%L M=64I.PT*"0D)"7T-"@D)"0EV;VED(&=?8RAC;VYS="!L;VYG(&1O=6)L92!V M86QU92D@>PT*"0D)"0ET:&ES+3YA<W-I9VY?9RAC;VQO<CHZ8V]R<F5C=%]V M86QU92AV86QU92DI.PT*"0D)"7T-"@D)"0EV;VED(&=?92AC;VYS="!L;VYG M(&1O=6)L92!V86QU92D@>PT*"0D)"0EI9BAC;VQO<CHZ8V]R<F5C=%]V86QU M92AV86QU92D@(3T@=F%L=64I('L-"@D)"0D)"71H<F]W(&)O;W-T.CIC;VQO M<CHZ8F%D7W9A;'5E*#$I.PT*"0D)"0E]#0H)"0D)"71H:7,M/F%S<VEG;E]G M*&-O;&]R.CIC;W)R96-T7W9A;'5E*'9A;'5E*2D[#0H)"0D)?0T*"0D)"79O M:60@9U]O*&-O;G-T('1Y<&5N86UE($-O;7!O;F5N='-?=')A:71S.CIG7W1Y M<&4@=F%L=64I('L-"@D)"0D)=&AI<RT^7V-O;7!O;F5N=',N9RAV86QU92D[ M#0H)"0D)?0T*"0D)"79O:60@9U]O7V,H8V]N<W0@='EP96YA;64@0V]M<&]N M96YT<U]T<F%I=',Z.F=?='EP92!V86QU92D@>PT*"0D)"0ET:&ES+3Y?8V]M M<&]N96YT<RYR*&-O;&]R.CIC;W)R96-T7W9A;'5E7V<H=F%L=64I*3L-"@D) M"0E]#0H)"0D)=F]I9"!G7V]?92AC;VYS="!T>7!E;F%M92!#;VUP;VYE;G1S M7W1R86ET<SHZ9U]T>7!E('9A;'5E*2R96-T7W9A;'5E7V<H=F%L=64I*2![#0H)"0D)"0ET:')O=R!B M;V]S=#HZ8V]L;W(Z.F)A9%]V86QU92@Q*3L-"@D)"0D)?0T*"0D)"0ET:&ES M+3Y?8V]M<&]N96YT<RYG*'9A;'5E*3L-"@D)"0E]#0H)"0D);&]N9R!D;W5B M;&4@8B@I(&-O;G-T('L-"@D)"0D)<F5T=7)N('-T871I8U]C87-T/&QO;F<@ M9&]U8FQE/BAT:&ES+3Y?8V]M<&]N96YT<RYB*"DI+W-T871I8U]C87-T/&QO M;F<@9&]U8FQE/BAS=&%T:6-?8V%S=#QL;VYG(&1O=6)L93XH0V]M<&]N96YT M<U]T<F%I=',Z.F)?;6%X+4-O;7!O;F5N='-?=')A:71S.CIB7VUI;BDI.PT* M"0D)"7T-"@D)"0ET>7!E;F%M92!#;VUP;VYE;G1S7W1R86ET<SHZ8E]T>7!E M(&)?;R@I(&-O;G-T('L-"@D)"0D)<F5T=7)N('1H:7,M/E]C;VUP;VYE;G1S M+F(H*3L-"@D)"0E]#0H)"0D)=F]I9"!B*&-O;G-T(&QO;F<@9&]U8FQE('9A M;'5E*2![#0H)"0D)"71H:7,M/F%S<VEG;E]B*'9A;'5E*3L-"@D)"0E]#0H) M"0D)=F]I9"!B7V,H8V]N<W0@;&]N9R!D;W5B;&4@=F%L=64I('L-"@D)"0D) M=&AI<RT^87-S:6=N7V(H8V]L;W(Z.F-O<G)E8W1?=F%L=64H=F%L=64I*3L- M"@D)"0E]#0H)"0D)=F]I9"!B7V4H8V]N<W0@;&]N9R!D;W5B;&4@=F%L=64I M('L-"@D)"0D):68H8V]L;W(Z.F-O<G)E8W1?=F%L=64H=F%L=64I("$]('9A M;'5E*2![#0H)"0D)"0ET:')O=R!B;V]S=#HZ8V]L;W(Z.F)A9%]V86QU92@R M*3L-"@D)"0D)?0T*"0D)"0ET:&ES+3YA<W-I9VY?8BAC;VQO<CHZ8V]R<F5C M=%]V86QU92AV86QU92DI.PT*"0D)"7T-"@D)"0EV;VED(&)?;RAC;VYS="!T M>7!E;F%M92!#;VUP;VYE;G1S7W1R86ET<SHZ8E]T>7!E('9A;'5E*2![#0H) M"0D)"71H:7,M/E]C;VUP;VYE;G1S+F(H=F%L=64I.PT*"0D)"7T-"@D)"0EV M;VED(&)?;U]C*&-O;G-T('1Y<&5N86UE($-O;7!O;F5N='-?=')A:71S.CIB M7W1Y<&4@=F%L=64I('L-"@D)"0D)=&AI<RT^7V-O;7!O;F5N=',N<BAC;VQO M<CHZ8V]R<F5C=%]V86QU95]B*'9A;'5E*2D[#0H)"0D)?0T*"0D)"79O:60@ M8E]O7V4H8V]N<W0@='EP96YA;64@0V]M<&]N96YT<U]T<F%I=',Z.F)?='EP M92!V86QU92D@>PT*"0D)"0EI9BAV86QU92 A/2!C;VQO<CHZ8V]R<F5C=%]V M86QU95]B*'9A;'5E*2D@>PT*"0D)"0D)=&AR;W<@8F]O<W0Z.F-O;&]R.CIB M861?=F%L=64H,BD[#0H)"0D)"7T-"@D)"0D)=&AI<RT^7V-O;7!O;F5N=',N M8BAV86QU92D[#0H)"0D)?0T*"0D)<')I=F%T93H-"@D)"0E#;VUP;VYE;G1S M(%]C;VUP;VYE;G1S.PT*"0D)"79O:60@87-S:6=N7W(H8V]N<W0@;&]N9R!D M;W5B;&4@=F%L=64I('L-"@D)"0D)=&AI<RT^7V-O;7!O;F5N=',N<BA#;VUP M;VYE;G1S7W1R86ET<SHZ<E]T>7!E*'-T871I8U]C87-T/&QO;F<@9&]U8FQE M/BA#;VUP;VYE;G1S7W1R86ET<SHZ<E]M:6XI*W9A;'5E*G-T871I8U]C87-T M/&QO;F<@9&]U8FQE/BA#;VUP;VYE;G1S7W1R86ET<SHZ<E]M87@M0V]M<&]N M96YT<U]T<F%I=',Z.G)?;6EN*2DI.PT*"0D)"7T-"@D)"0EV;VED(&%S<VEG M;E]G*&-O;G-T(&QO;F<@9&]U8FQE('9A;'5E*2![#0H)"0D)"71H:7,M/E]C M;VUP;VYE;G1S+F<H0V]M<&]N96YT<U]T<F%I=',Z.F=?='EP92AS=&%T:6-? M8V%S=#QL;VYG(&1O=6)L93XH0V]M<&]N96YT<U]T<F%I=',Z.F=?;6EN*2MV M86QU92IS=&%T:6-?8V%S=#QL;VYG(&1O=6)L93XH0V]M<&]N96YT<U]T<F%I M=',Z.F=?;6%X+4-O;7!O;F5N='-?=')A:71S.CIG7VUI;BDI*3L-"@D)"0E] M#0H)"0D)=F]I9"!A<W-I9VY?8BAC;VYS="!L;VYG(&1O=6)L92!V86QU92D@ M>PT*"0D)"0ET:&ES+3Y?8V]M<&]N96YT<RYB*$-O;7!O;F5N='-?=')A:71S M.CIB7W1Y<&4H<W1A=&EC7V-A<W0\;&]N9R!D;W5B;&4^*$-O;7!O;F5N='-? M=')A:71S.CIB7VUI;BDK=F%L=64J<W1A=&EC7V-A<W0\;&]N9R!D;W5B;&4^ M*$-O;7!O;F5N='-?=')A:71S.CIB7VUA>"U#;VUP;VYE;G1S7W1R86ET<SHZ M8E]M:6XI*2D[#0H)"0D)?0T*"0D)"79O:60@87-S:6=N7W)G8BAC;VYS="!L M;VYG(&1O=6)L92!R+"!C;VYS="!L;VYG(&1O=6)L92!G+"!C;VYS="!L;VYG M(&1O=6)L92!B*2![#0H)"0D)"71H:7,M/F%S<VEG;E]R*'(I.PT*"0D)"0ET M:&ES+3YA<W-I9VY?9RAG*3L-"@D)"0D)=&AI<RT^87-S:6=N7V(H8BD[#0H) M"0D)?0T*"0D)"7-T871I8R!L;VYG(&1O=6)L92!C;W)R96-T7W9A;'5E*&-O M;G-T(&QO;F<@9&]U8FQE('9A;'5E*2![#0H)"0D)"6EF*'9A;'5E(#P@,"XP M;"D@>PT*"0D)"0D)<F5T=7)N(# N,&P[#0H)"0D)"7T@96QS92!I9BAV86QU M92 ^(#$N,&PI('L-"@D)"0D)"7)E='5R;B Q+C!L.PT*"0D)"0E](&5L<V4@ M>PT*"0D)"0D)<F5T=7)N('9A;'5E.PT*"0D)"0E]#0H)"0D)?0T*"0D)"7-T M871I8R!L;VYG(&1O=6)L92!C;W)R96-T7W9A;'5E7W(H8V]N<W0@='EP96YA M;64@0V]M<&]N96YT<U]T<F%I=',Z.G)?='EP92!V86QU92D@>PT*"0D)"0EI M9BAV86QU92 \($-O;7!O;F5N='-?=')A:71S.CIR7VUI;BD@>PT*"0D)"0D) M<F5T=7)N($-O;7!O;F5N='-?=')A:71S.CIR7VUI;CL-"@D)"0D)?2!E;'-E M(&EF*'9A;'5E(#X@0V]M<&]N96YT<U]T<F%I=',Z.G)?;6%X*2![#0H)"0D) M"0ER971U<FX@0V]M<&]N96YT<U]T<F%I=',Z.G)?;6%X.PT*"0D)"0E](&5L M<V4@>PT*"0D)"0D)<F5T=7)N('9A;'5E.PT*"0D)"0E]#0H)"0D)?0T*"0D) M"7-T871I8R!L;VYG(&1O=6)L92!C;W)R96-T7W9A;'5E7V<H8V]N<W0@='EP M96YA;64@0V]M<&]N96YT<U]T<F%I=',Z.F=?='EP92!V86QU92D@>PT*"0D) M"0EI9BAV86QU92 \($-O;7!O;F5N='-?=')A:71S.CIG7VUI;BD@>PT*"0D) M"0D)<F5T=7)N($-O;7!O;F5N='-?=')A:71S.CIG7VUI;CL-"@D)"0D)?2!E M;'-E(&EF*'9A;'5E(#X@0V]M<&]N96YT<U]T<F%I=',Z.F=?;6%X*2![#0H) M"0D)"0ER971U<FX@0V]M<&]N96YT<U]T<F%I=',Z.F=?;6%X.PT*"0D)"0E] M(&5L<V4@>PT*"0D)"0D)<F5T=7)N('9A;'5E.PT*"0D)"0E]#0H)"0D)?0T* M"0D)"7-T871I8R!L;VYG(&1O=6)L92!C;W)R96-T7W9A;'5E7V(H8V]N<W0@ M='EP96YA;64@0V]M<&]N96YT<U]T<F%I=',Z.F)?='EP92!V86QU92D@>PT* M"0D)"0EI9BAV86QU92 \($-O;7!O;F5N='-?=')A:71S.CIB7VUI;BD@>PT* M"0D)"0D)<F5T=7)N($-O;7!O;F5N='-?=')A:71S.CIB7VUI;CL-"@D)"0D) M?2!E;'-E(&EF*'9A;'5E(#X@0V]M<&]N96YT<U]T<F%I=',Z.F)?;6%X*2![ M#0H)"0D)"0ER971U<FX@0V]M<&]N96YT<U]T<F%I=',Z.F)?;6%X.PT*"0D) M"0E](&5L<V4@>PT*"0D)"0D)<F5T=7)N('9A;'5E.PT*"0D)"0E]#0H)"0D) M?0T*"0D)?3L-"@T*#0H)"0ET96UP;&%T93QT>7!E;F%M92!#;VUP;VYE;G1S M+"!T>7!E;F%M92!#;VUP;VYE;G1S7W1R86ET<SX@<W1D.CIO<W1R96%M)B!O M<&5R871O<B \/"AS=&0Z.F]S=')E86TF('-T<F5A;2P@8V]N<W0@8V]L;W(\ M0V]M<&]N96YT<RP@0V]M<&]N96YT<U]T<F%I=',^(&,I('L-"@D)"0ER971U M<FX@<W1R96%M(#P\(")21T(Z6R(@/#P@8RYR*"D@/#P@(CL@(B \/"!C+F<H M*2 \/" B.R B(#P\(&,N8B@I(#P\(")=(CL-"@D)"7T-"@T*"0E]#0H-"@T* M"0ET>7!E9&5F(')G8CHZ8V]L;W(\<F=B.CIC;VUP;VYE;G1S7W)G8CQL;VYG M(&1O=6)L93XL(')G8CHZ8V]M<&]N96YT<U]T<F%I=',\<F=B.CIC;VUP;VYE M;G1S7W)G8CQL;VYG(&1O=6)L93X@/B ^(&-O;&]R7W)G8CL-"@D)='EP961E M9B!R9V(Z.F-O;&]R/')G8CHZ8V]M<&]N96YT<U\S,F(L(')G8CHZ8V]M<&]N M96YT<U]T<F%I=',\<F=B.CIC;VUP;VYE;G1S7S,R8CX@/B!C;VQO<E]R9V)? ?=VEN.PT*#0H-"@E]#0H-"@T*?0T*#0H-"B-E;F1I9@`` ` end begin 666 color.cpp M(VEN8VQU9&4@(F-O;&]R+FAP<"(-"@T*8V]N<W0@8F]O<W0Z.F-O;&]R.CIR M9V(Z.F-O;7!O;F5N='-?=')A:71S/&)O;W-T.CIC;VQO<CHZ<F=B.CIC;VUP M;VYE;G1S7W)G8CQF;&]A=#X@/CHZ<E]T>7!E(&)O;W-T.CIC;VQO<CHZ<F=B M.CIC;VUP;VYE;G1S7W1R86ET<SQB;V]S=#HZ8V]L;W(Z.G)G8CHZ8V]M<&]N M96YT<U]R9V(\9FQO870^(#XZ.G)?;6EN(#T@,"XP9CL-"F-O;G-T(&)O;W-T M.CIC;VQO<CHZ<F=B.CIC;VUP;VYE;G1S7W1R86ET<SQB;V]S=#HZ8V]L;W(Z M.G)G8CHZ8V]M<&]N96YT<U]R9V(\9FQO870^(#XZ.G)?='EP92!B;V]S=#HZ M8V]L;W(Z.G)G8CHZ8V]M<&]N96YT<U]T<F%I=',\8F]O<W0Z.F-O;&]R.CIR M9V(Z.F-O;7!O;F5N='-?<F=B/&9L;V%T/B ^.CIR7VUA>" ](#$N,&8[#0IC M;VYS="!B;V]S=#HZ8V]L;W(Z.G)G8CHZ8V]M<&]N96YT<U]T<F%I=',\8F]O M<W0Z.F-O;&]R.CIR9V(Z.F-O;7!O;F5N='-?<F=B/&9L;V%T/B ^.CIG7W1Y M<&4@8F]O<W0Z.F-O;&]R.CIR9V(Z.F-O;7!O;F5N='-?=')A:71S/&)O;W-T M.CIC;VQO<CHZ<F=B.CIC;VUP;VYE;G1S7W)G8CQF;&]A=#X@/CHZ9U]M:6X@ M/2 P+C!F.PT*8V]N<W0@8F]O<W0Z.F-O;&]R.CIR9V(Z.F-O;7!O;F5N='-? M=')A:71S/&)O;W-T.CIC;VQO<CHZ<F=B.CIC;VUP;VYE;G1S7W)G8CQF;&]A M=#X@/CHZ9U]T>7!E(&)O;W-T.CIC;VQO<CHZ<F=B.CIC;VUP;VYE;G1S7W1R M86ET<SQB;V]S=#HZ8V]L;W(Z.G)G8CHZ8V]M<&]N96YT<U]R9V(\9FQO870^ M(#XZ.F=?;6%X(#T@,2XP9CL-"F-O;G-T(&)O;W-T.CIC;VQO<CHZ<F=B.CIC M;VUP;VYE;G1S7W1R86ET<SQB;V]S=#HZ8V]L;W(Z.G)G8CHZ8V]M<&]N96YT M<U]R9V(\9FQO870^(#XZ.F)?='EP92!B;V]S=#HZ8V]L;W(Z.G)G8CHZ8V]M M<&]N96YT<U]T<F%I=',\8F]O<W0Z.F-O;&]R.CIR9V(Z.F-O;7!O;F5N='-? M<F=B/&9L;V%T/B ^.CIB7VUI;B ](# N,&8[#0IC;VYS="!B;V]S=#HZ8V]L M;W(Z.G)G8CHZ8V]M<&]N96YT<U]T<F%I=',\8F]O<W0Z.F-O;&]R.CIR9V(Z M.F-O;7!O;F5N='-?<F=B/&9L;V%T/B ^.CIB7W1Y<&4@8F]O<W0Z.F-O;&]R M.CIR9V(Z.F-O;7!O;F5N='-?=')A:71S/&)O;W-T.CIC;VQO<CHZ<F=B.CIC M;VUP;VYE;G1S7W)G8CQF;&]A=#X@/CHZ8E]M87@@/2 Q+C!F.PT*#0IC;VYS M="!B;V]S=#HZ8V]L;W(Z.G)G8CHZ8V]M<&]N96YT<U]T<F%I=',\8F]O<W0Z M.F-O;&]R.CIR9V(Z.F-O;7!O;F5N='-?<F=B/&1O=6)L93X@/CHZ<E]T>7!E M(&)O;W-T.CIC;VQO<CHZ<F=B.CIC;VUP;VYE;G1S7W1R86ET<SQB;V]S=#HZ M8V]L;W(Z.G)G8CHZ8V]M<&]N96YT<U]R9V(\9&]U8FQE/B ^.CIR7VUI;B ] M(# N,#L-"F-O;G-T(&)O;W-T.CIC;VQO<CHZ<F=B.CIC;VUP;VYE;G1S7W1R M86ET<SQB;V]S=#HZ8V]L;W(Z.G)G8CHZ8V]M<&]N96YT<U]R9V(\9&]U8FQE M/B ^.CIR7W1Y<&4@8F]O<W0Z.F-O;&]R.CIR9V(Z.F-O;7!O;F5N='-?=')A M:71S/&)O;W-T.CIC;VQO<CHZ<F=B.CIC;VUP;VYE;G1S7W)G8CQD;W5B;&4^ M(#XZ.G)?;6%X(#T@,2XP.PT*8V]N<W0@8F]O<W0Z.F-O;&]R.CIR9V(Z.F-O M;7!O;F5N='-?=')A:71S/&)O;W-T.CIC;VQO<CHZ<F=B.CIC;VUP;VYE;G1S M7W)G8CQD;W5B;&4^(#XZ.F=?='EP92!B;V]S=#HZ8V]L;W(Z.G)G8CHZ8V]M M<&]N96YT<U]T<F%I=',\8F]O<W0Z.F-O;&]R.CIR9V(Z.F-O;7!O;F5N='-? M<F=B/&1O=6)L93X@/CHZ9U]M:6X@/2 P+C [#0IC;VYS="!B;V]S=#HZ8V]L M;W(Z.G)G8CHZ8V]M<&]N96YT<U]T<F%I=',\8F]O<W0Z.F-O;&]R.CIR9V(Z M.F-O;7!O;F5N='-?<F=B/&1O=6)L93X@/CHZ9U]T>7!E(&)O;W-T.CIC;VQO M<CHZ<F=B.CIC;VUP;VYE;G1S7W1R86ET<SQB;V]S=#HZ8V]L;W(Z.G)G8CHZ M8V]M<&]N96YT<U]R9V(\9&]U8FQE/B ^.CIG7VUA>" ](#$N,#L-"F-O;G-T M(&)O;W-T.CIC;VQO<CHZ<F=B.CIC;VUP;VYE;G1S7W1R86ET<SQB;V]S=#HZ M8V]L;W(Z.G)G8CHZ8V]M<&]N96YT<U]R9V(\9&]U8FQE/B ^.CIB7W1Y<&4@ M8F]O<W0Z.F-O;&]R.CIR9V(Z.F-O;7!O;F5N='-?=')A:71S/&)O;W-T.CIC M;VQO<CHZ<F=B.CIC;VUP;VYE;G1S7W)G8CQD;W5B;&4^(#XZ.F)?;6EN(#T@ M,"XP.PT*8V]N<W0@8F]O<W0Z.F-O;&]R.CIR9V(Z.F-O;7!O;F5N='-?=')A M:71S/&)O;W-T.CIC;VQO<CHZ<F=B.CIC;VUP;VYE;G1S7W)G8CQD;W5B;&4^ M(#XZ.F)?='EP92!B;V]S=#HZ8V]L;W(Z.G)G8CHZ8V]M<&]N96YT<U]T<F%I M=',\8F]O<W0Z.F-O;&]R.CIR9V(Z.F-O;7!O;F5N='-?<F=B/&1O=6)L93X@ M/CHZ8E]M87@@/2 Q+C [#0H-"F-O;G-T(&)O;W-T.CIC;VQO<CHZ<F=B.CIC M;VUP;VYE;G1S7W1R86ET<SQB;V]S=#HZ8V]L;W(Z.G)G8CHZ8V]M<&]N96YT M<U]R9V(\;&]N9R!D;W5B;&4^(#XZ.G)?='EP92!B;V]S=#HZ8V]L;W(Z.G)G M8CHZ8V]M<&]N96YT<U]T<F%I=',\8F]O<W0Z.F-O;&]R.CIR9V(Z.F-O;7!O M;F5N='-?<F=B/&QO;F<@9&]U8FQE/B ^.CIR7VUI;B ](# N,&P[#0IC;VYS M="!B;V]S=#HZ8V]L;W(Z.G)G8CHZ8V]M<&]N96YT<U]T<F%I=',\8F]O<W0Z M.F-O;&]R.CIR9V(Z.F-O;7!O;F5N='-?<F=B/&QO;F<@9&]U8FQE/B ^.CIR M7W1Y<&4@8F]O<W0Z.F-O;&]R.CIR9V(Z.F-O;7!O;F5N='-?=')A:71S/&)O M;W-T.CIC;VQO<CHZ<F=B.CIC;VUP;VYE;G1S7W)G8CQL;VYG(&1O=6)L93X@ M/CHZ<E]M87@@/2 Q+C!L.PT*8V]N<W0@8F]O<W0Z.F-O;&]R.CIR9V(Z.F-O M;7!O;F5N='-?=')A:71S/&)O;W-T.CIC;VQO<CHZ<F=B.CIC;VUP;VYE;G1S M7W)G8CQL;VYG(&1O=6)L93X@/CHZ9U]T>7!E(&)O;W-T.CIC;VQO<CHZ<F=B M.CIC;VUP;VYE;G1S7W1R86ET<SQB;V]S=#HZ8V]L;W(Z.G)G8CHZ8V]M<&]N M96YT<U]R9V(\;&]N9R!D;W5B;&4^(#XZ.F=?;6EN(#T@,"XP;#L-"F-O;G-T M(&)O;W-T.CIC;VQO<CHZ<F=B.CIC;VUP;VYE;G1S7W1R86ET<SQB;V]S=#HZ M8V]L;W(Z.G)G8CHZ8V]M<&]N96YT<U]R9V(\;&]N9R!D;W5B;&4^(#XZ.F=? M='EP92!B;V]S=#HZ8V]L;W(Z.G)G8CHZ8V]M<&]N96YT<U]T<F%I=',\8F]O M<W0Z.F-O;&]R.CIR9V(Z.F-O;7!O;F5N='-?<F=B/&QO;F<@9&]U8FQE/B ^ M.CIG7VUA>" ](#$N,&P[#0IC;VYS="!B;V]S=#HZ8V]L;W(Z.G)G8CHZ8V]M M<&]N96YT<U]T<F%I=',\8F]O<W0Z.F-O;&]R.CIR9V(Z.F-O;7!O;F5N='-? M<F=B/&QO;F<@9&]U8FQE/B ^.CIB7W1Y<&4@8F]O<W0Z.F-O;&]R.CIR9V(Z M.F-O;7!O;F5N='-?=')A:71S/&)O;W-T.CIC;VQO<CHZ<F=B.CIC;VUP;VYE M;G1S7W)G8CQL;VYG(&1O=6)L93X@/CHZ8E]M:6X@/2 P+C!L.PT*8V]N<W0@ M8F]O<W0Z.F-O;&]R.CIR9V(Z.F-O;7!O;F5N='-?=')A:71S/&)O;W-T.CIC M;VQO<CHZ<F=B.CIC;VUP;VYE;G1S7W)G8CQL;VYG(&1O=6)L93X@/CHZ8E]T M>7!E(&)O;W-T.CIC;VQO<CHZ<F=B.CIC;VUP;VYE;G1S7W1R86ET<SQB;V]S M=#HZ8V]L;W(Z.G)G8CHZ8V]M<&]N96YT<U]R9V(\;&]N9R!D;W5B;&4^(#XZ ..F)?;6%X(#T@,2XP;#L` ` end
Adam Badura wrote:
So, more on topic: is an actual implementation of the proposed color lib in development? ie. is there any code that I can compile and take a look at the decisions being made in context?
I have included only one example (rather simple just to check if everything compiles) because you were hurrying me so much... :)
Sorry if I have been sounding like a arrogant manager or something, I was just tring to say have the code out quickly, cause it's easier to fix design issues /before/ you write 53 classes depending in it. Or at least, I should have. Disclaimer: Below is my _personal_ opinion about the library, anyone who's looked at my previous posts will know that I'm not always the brightest something in the something!
I compiled on Microsoft Visual C++ Toolkit 2003 and Borland C++ 5.5 both compiled without errors.
You should also test with GCC, btw. But two is one more that most test with! (Heck, it's /two/ more than some test with.)
So what do the files containt? Almost everything is in color.hpp because almost everything is template or inline. Now only RGB model is implemented - I wanted to get clear idea what to do and how do it. Then write CMYK or YUV (they should be almost the same) and project conversions. Then write the rest.
I'm not sure CMYK is common as a representation in memory. HSV and YUV are more likely, though. Maybe some of the CIE formats?
Actual project looks like this:
1) We have classes for color data representations (in color.hpp components_rgb, components_32b, components_32b_inv). They are responsible for storing and serving "raw" data. This is done because for a color class (see 3) it does not matter wheather color components have all 8 or 16 bits or how are they placed in memory. Color class (see 3) must know only some details given in components_traits (see 2). Color representation class must serve 6 functions:
TYPE_OF_R r() const; // return R value void r(TYPE_OF_R value); // set R value TYPE_OF_G g() const; // return G value void g(TYPE_OF_G value); // set G value TYPE_OF_B b() const; // return B value void b(TYPE_OF_B value); // set B value
ugh... getter-setter methods. Why don't we just directly access the values? This /is/ only the representation in memory, right?
They should be as fast as only possible. No error checking - color class (see 3) will do it when needed. Also a copy constructor and copy operator should be available but this usually is no problem because default compiler generated one will do. All this is introduced to allow use of library with other libraries (DirectX, OpenGL, native WinAPI, ...) and formats of color storing.
Sensible.
I declared all this classes actually as structures to emphasise on importance of memory model. This classes have to be allocated in memory exactyl as they have data memers to allow worinkg with buffers for and from other devices and libraries.
2) We have template class components_traits which has to be specialized for every representation class (see 1). It serves basic static data of the component:
typedef TYPE_OF_R r_type; typedef TYPE_OF_G g_type; typedef TYPE_OF_B b_type; static const r_type r_min; static const r_type r_max; static const g_type g_min; static const g_type g_max; static const b_type b_min; static const b_type b_max;
OK. (Although I don't know how often min and max for each type will be used. Hue for HSV is about all I can think of, and even then, full range should be more common than [0, 360) ) Requiring a specialisation every time shouldn't be neccesary: template <class Repr> components_traits { typedef typename Repr::r_type r_type; // .. static const r_type r_min = typename template numeric_limits<r_type>::min(); // .. }; Then you just need to define r_type, etc in the representation. Keep the traits class, though. It may be usefull for edge cases and using other interfaces.
this is used be color class (see 3) in conversions correcting values and defining interface. r_type, g_type and b_type must be convertable to long double and must construct from long double. This is no problem in case of standard types. And because this types must (or at least should to be functional) behave like number so requirement is quite natural...
3) We have color class. It is parametrized by representation class (see 1) and its traits (see 2).
Sounds reasonable, however, see below
This class gives 2 way access to color data. First one is unified by type long double. Components are of type long double in range [0; 1]. Actually the can be in any representation but they color class takes care of conversion to long double. Conversion form long double to actual representation is done by the representation (by the type of component) so kind of rounding is determined there and in usual case it will be rounding to nearest representable color (or it should be like this). This is added to allow writing of generic functions taht do not care about actual representation and its limits. But it should be remembered that this is not the fastes access (aspecially in writng) because it requires conversions and mathematical operations. Second is by actual component type (all functions postfixed with _o). This is as fast as possible but not as generic... All (write) functions come in few versions. Version without postfix makes no error chcecking (to be used in releas version of program to make it faster). Version ending in _c corrects values. If value given for component is smaller the minimum for that component minimum is writen instead, if value is larger then maximum then maximum is writen instead. This is aspecially useful for generic functions because rounding in floating point operations can actually take value beyond accepted range. Version ending in _e throws an exception when component value is out of range (or when component is out of range see further remarks). This is intended to be used in debuging application and then in release to replace by non-checking calls. I writed an indexed function where index 0 gives (or sets) R, 1 is for G and 2 is for B. But they only are available in long double version because actual component tpyes me be different.
All this sounds like it could be done cleaner with generic programming. You already are exposing the types of the components: why pass everything though long double? The behaviour of the functions would be better determined by a policy template parameter, IMHO. Less names to keep track of. So: // Default traits = color_traits< rgbx_8 >, like basic_string typedef color_rgb< rgbx_8, colors::exception_policy > my_color; my_color::r_type red_value;
So I think its all by now.
What do I want to do futher? 1) add "nice features" like functions "darker", "brighter" and so on...
Just one "lightness" should do: we have to figure out what canonical colourspace to use, or whether the user can specify it, though.
2) add comparing with or without "toleration range" (colors [0.00000001, 0.0, 0.0] and [0.0, 0.0, 0.0] really do not differ that much aspecially converted to integer based representation...
This is more general a problem than color (unfortunately).
3) add and test useful representations 4) add reading and writing form a string and all web-color as predefined, but this will I do perhabs after completting everything else (actually there is an << operator defined but only to ease testing)
The library shouldn't try to handle every format ever used to store color, of course.
5) add other models and convertions betwean them
A lot of the work will be trying to define how to have a sensible interface to drasticly different color representations. Think STL: a lot of very different ways to contain things, but everything can be used with a single generalised interface. Of course, you can should still be able to access the special abilities of each type (like you can op [] for vector, splice for list, in STL).
So what you think?
It could be very usefull> Colour is one of those things that doesn't want to be tied to a number, though, so you have a bit of work infront of you. I hope (for your sake!) that you know what you've gotten yourself into.
Adam Badura
<snip binary files dumped inline> Looks like something along the line killed the files.
participants (1)
-
Adam Badura -
Alec Ross -
Andy Little -
Cory Nelson -
Fabio Fracassi -
Geoffrey Romer -
Jason Kankiewicz -
Kevin Wheatley -
Nigel Stewart -
Paolo Coletta -
Pavel Vozenilek -
Reece Dunn -
Rene Rivera -
Rob Stewart -
Simon Buchan -
Vladimir Prus