Помогите определиться с архитектурой библиотеки управления цветом на C#

Question

[efremovaleksey]

Пишу свою библиотеку, работающую с цветом (операции в различных цветовых пространствах), пишу на C#, в том числе и с целью освоить язык (новый для меня), и разобраться в деталях в Color Management'е.

Вот только до сих пор в раздумьях, как это реализовать, с чего начать. Для одних задач будет оптимальнее использовать в качестве основного представления цвета RGB, в других LAB, в третьих LCh (для тех, кто не в теме, это, примитивно говоря «Lab с цветом в полярных координатах»). Это библиотека. Пользователь должен выбирать сам, что ему важнее, какие операции над цветом в каком формате больше всего съедают время.

Может, просто взять, и сделать что то вроде в теле класса?

#if LAB_MAIN_FORMAT
    //...
#elif RGB_MAIN_FORMAT
    //...
#elif LCh_MAIN_FORMAT
    //...
#endif

Да, буду рад конкретным ссылкам на статьи, литературу, где можно найти описание решения схожих задач.
Если вопрос кажется вам глупым, прошу не пинать, а внятно объяснить.

Comments

[lair]

Я вообще не понимаю, в чем ваша проблема, и зачем вам препроцессор — учитывая, что «пользователь» к нему доступа не имеет.

Answer 1

[lair]

Стандартное решение проблемы «Для одних задач будет оптимальнее использовать в качестве основного представления цвета RGB, в других LAB, в третьих LCh » — это три различных набора классов (с общими базовыми интерфейсами), по одному на цветовую модель. По аналогии с тем, как в ado.net сделан доступ к различным СУБД.

Answer 2

[ostapbender]

Единый immutable класс Color, который конвертирует во все представления «на лету»

class Color
{
    private Rgb rgb;
    private Lab lab;

    public Rgb Rgb
    {
        get { return rgb ?? (rgb == ToRgb(this)); }
    }

    public Lab Lab
    {
        get { return lab ?? (lab == ToLab(this)); }
    }

    public static Color FromRgb(int r, int g, int b)
    {	
    }

    public static Color FromHsv(...)
    {	
    }

    public static Color FromLab(...)
    {	
    }

    private static Rgb ToRgb(Color c)
    {	
    }

    private static Lab ToLab(Color c)
    {	
    }
}

И потом реализации всяких операций используют то представление, в котором им удобнее работать:

class ColorOperations
{
    public static Color Darken(Color c, float amount)
    {
        // Тут выгоднее использовать c.Hsv
    }

    public static Color Sharpen(Color c, float amount)
    {
        // А тут выгоднее использовать c.Lab
    }
}

Answer 3

[efremovaleksey]

Согласен, ступил немного, потому и спрашиваю.
Проблема в возможности выбора внутреннего представления цвета в соответствии с типом, который будет использоваться в основной программе.

Пример. Если будут часто использоваться одни операции, то выигрышным будет кодирование цвета внутри библиотеки в качестве основного «носителя» в RGB. Если другие, то LAB. Не гонять же туда-сюда цвет.

Как сделать подобный выбор до компиляции?

Comments

[lair]

Как сделать подобный выбор до компиляции?

Никак. Пользователь использует уже скомпилированную библиотеку. Поэтому — как сказано выше, три набора классов.

Не гонять же туда-сюда цвет.

Почему? Вам все равно придется это делать.

Answer 4

[gleb_kudr]

1. Классы цветов — отдельно на каждый цвет. Ибо конвертеры не являются точными и абсолютными. Хотя бы потому, что Лаб — числа с плавающей точкой, а RGB — целое. Плюс, конвертация зависит от зашитых констант.
2. Константы параметров для конвертации (например белая точка, константа D).
3. Абстрактный класс с методами конвертации.

Могу поделиться исходниками класса-конвертера на c# из RGB в LAB и обратно через XYZ. Пишите в личку.

Comments

[gleb_kudr]

>отдельно на каждый цвет

Отдельно на каждое цветовое пространство, конечно.