[mantech 34]

Приветствую.

Есть такая задачка, рисовать на экране символы, которые получены TTF растеризатором, результатом работы которого является байтовая матрица с коэффициентами яркости каждой точки, при том, что для символа задан цвет (24бита). Я так понимаю, что если коэффициент=255, то цвет пикселя будет именно тот, что задан, если =0 то точки нет, или черная, но как быть со значениями 1-254? Их нужно как-то пересчитывать для R G B по отдельности, вопрос, как? 

[_4afc_ 25]

19 minutes ago, mantech said:

Есть такая задачка, рисовать на экране символы, которые получены TTF растеризатором, результатом работы которого является байтовая матрица с коэффициентами яркости каждой точки, при том, что для символа задан цвет (24бита). Я так понимаю, что если коэффициент=255, то цвет пикселя будет именно тот, что задан, если =0 то точки нет, или черная, но как быть со значениями 1-254? Их нужно как-то пересчитывать для R G B по отдельности, вопрос, как? 

Вероятно, если цвет задан в RGB, то перевести его в YUV изменить Y на y и обратно в rgb

не забываем ограничивать полученные значения до предельных.

 

YCbCr

[mantech 34]

11 минут назад, _4afc_ сказал:

то перевести его в YUV

Так-то да, но медленно, для всего контура символа нужно делать пересчет в плавучке, вот и спрашивал, может есть более быстрый алгоритм только для коррекции яркости...

А если так, берем каждую компоненту, делим на 255 в плавучке, получаемое число умножаем на коэффициент яркости выделяем целую часть и снова собираем компоненты в цвет?

Изменено 6 января, 2022 пользователем mantech

[aaarrr 63]

Не нужна плавучка - в целых, при разрядности >32 все компоненты одним умножением.

Но это как раз ерунда, нужна еще гамма-коррекция.

[mantech 34]

26 минут назад, aaarrr сказал:

Не нужна плавучка - в целых,

Ну в целых-то тут не получится, разве, что фикс. точка.

27 минут назад, aaarrr сказал:

>32 все компоненты одним умножением.

А это как, поясните?

27 минут назад, aaarrr сказал:

нужна еще гамма-коррекция.

На сколько сильно тут нужна, все-таки просто сглаживание контуров, не фотография в высоком качестве.  

Может какой-нить примерчик такого преобразования есть?

[_4afc_ 25]

1 hour ago, mantech said:

Так-то да, но медленно, для всего контура символа нужно делать пересчет в плавучке, вот и спрашивал, может есть более быстрый алгоритм только для коррекции яркости...

А если так, берем каждую компоненту, делим на 255 в плавучке, получаемое число умножаем на коэффициент яркости выделяем целую часть и снова собираем компоненты в цвет?

 

Плавучка не нужна и ничего не даст в качестве. Всегда достаточно было считать в знаковой фиксированной точке умножив на 1024.

Я вам дал наколку на идеальную формулу. Далее можете упрощать. Может там останется пара действий.

Возможно потребуется учёт гаммы, возможно ограничения для значений Y...

[mantech 34]

20 минут назад, _4afc_ сказал:

Я вам дал наколку на идеальную формулу.

Попробую, просто думал, что задача вроде типичная и есть какие-то проверенные решения...

Видимо не могу "правильно" задать вопрос поисковикам, все какие-то фотошопы и вебы вылезают((

Изменено 6 января, 2022 пользователем mantech

[aaarrr 63]

1 hour ago, mantech said:

На сколько сильно тут нужна, все-таки просто сглаживание контуров, не фотография в высоком качестве.

Попробуйте без коррекции вывести черный текст на белом фоне и белый на черном. Один из вариантов будет выглядеть откровенно плохо.

 

1 hour ago, mantech said:

А это как, поясните?

Раскинуть исходные компоненты по 64 битам с зазором в 8 бит, одной операцией умножить все три на однобайтовый коэффициент.

[mantech 34]

28 минут назад, aaarrr сказал:

Попробуйте без коррекции вывести черный текст на белом фоне и белый на черном. Один из вариантов будет выглядеть откровенно плохо.

Попробовал свой вариант, на черном и белом фоне рисует нормально, НО на некоторых цветах самого символа (например синем) почти не ощущается сглаженность, тогда, как на желтом и зеленом все норм... Вообщем не хватает знаний по этой математике((

[tgruzd 11]

3 часа назад, mantech сказал:

 на некоторых цветах самого символа (например синем) почти не ощущается сглаженность, тогда, как на желтом и зеленом все норм

а вы куда изображение выводите? Если, например, на TFT с форматом цвета RGB565,  то чистые синий и красный будут сглаживаться закономерно хуже чем желтый и зеленый (впрочем, на RGB565 в принципе со сглаживанием всё очень плохо).

[mantech 34]

26 минут назад, tgruzd сказал:

а вы куда изображение выводите? Если, например, на TFT с форматом цвета RGB565

TFT ARGB8888

27 минут назад, tgruzd сказал:

впрочем, на RGB565 в принципе со сглаживанием всё очень плохо).

Где-то видел видео, похуже, чем на 24х битах, но вполне норм выглядит.

[tgruzd 11]

1 час назад, mantech сказал:

TFT ARGB8888

если контроллер поддерживает альфаканал, то выходит, что ваша байтовая матрица яркости - это он и есть. Выводите в порядке: A(байт яркости, в вашей терминологии),R,G,B  

1 час назад, mantech сказал:

Где-то видел видео, похуже, чем на 24х битах, но вполне норм выглядит.

Для символов и мелких значков - норм, для относительно больших площадей с плавным градиентом цвета - плохо 

[mantech 34]

50 минут назад, tgruzd сказал:

если контроллер поддерживает альфаканал, то выходит, что ваша байтовая матрица яркости - это он и есть. Выводите в порядке: A(байт яркости, в вашей терминологии),R,G,B  

Там не в альфа канале дело, надо было пересчитать цветовые компоненты в соотв. с каналом яркости пикселя. Проблема была в том, что я не брал цветовое значение точки для расчета, вот и тупило на разных фонах. Альфа канал для этого можно использовать только на верхнем слое, на бекграунде альфа не работает...

56 минут назад, tgruzd сказал:

для относительно больших площадей с плавным градиентом цвета - плохо

Так тут конечно, а на 8и битном цвете градиент это такая пакость)))

[tgruzd 11]

21 минуту назад, mantech сказал:

Альфа канал для этого можно использовать только на верхнем слое, на бекграунде альфа не работает...

Наверное я не так понял вашу задачу. Обычно символы накладывают на исходное изображение (бэкграунд?), смысл моего совета заключался в том, что, раз уж контроллер умеет работать с альфой, то и доверить ему это наложение. Но да, ситуации бывают разные. 

[mantech 34]

47 минут назад, tgruzd сказал:

Но да, ситуации бывают разные.

В моей системе используется оба слоя и основной(бэкграунд) и верхний, так удобнее, например непрозрачные картинки (jpeg), формы оконного интерфейса проще рисовать на нем, а прозрачные картинки в верхнем слое, так происходит автоматическое наложение и ничего вычислять не нужно, но не всегда удобно все рисовать на верхнем слое, а поэтому система должна уметь рисовать и там и там...