Сравнение вещественных чисел

[igor]

А на мониторах это нифига не работает и реализация не может "правильно учесть растр" - она не может знать в какую сторону ей сместить линию с координатой 0.5 (вверх или вниз), поэтому она рисует две полупрозрачные линии с координатами 0 и 1.

А должна была бы округлить координату 0.5 до целого и нарисовать одну плотную линию в нужном месте с точностью до межпиксельного расстояния. А вот с наклонными линиями тактика всё-же должна быть наверно другой.

[vlad]

А на мониторах это нифига не работает и реализация не может "правильно учесть растр" - она не может знать в какую сторону ей сместить линию с координатой 0.5 (вверх или вниз), поэтому она рисует две полупрозрачные линии с координатами 0 и 1.

А должна была бы округлить координату 0.5 до целого и нарисовать одну плотную линию в нужном месте с точностью до межпиксельного расстояния. А вот с наклонными линиями тактика всё-же должна быть наверно другой.

Не может она сама округлить. Потому что ожидается, что линии 0.5000001 и 0.4999999 должны быть визуально неотличимы. Так же как 0.9999999 и 1.0000001.

P.S. Да, с наклонными вообще песня...

[Димыч]

А на мониторах это нифига не работает и реализация не может "правильно учесть растр" - она не может знать в какую сторону ей сместить линию с координатой 0.5 (вверх или вниз), поэтому она рисует две полупрозрачные линии с координатами 0 и 1.

А должна была бы округлить координату 0.5 до целого и нарисовать одну плотную линию в нужном месте с точностью до межпиксельного расстояния. А вот с наклонными линиями тактика всё-же должна быть наверно другой.

Все не так просто. Действительно, получение сглаженных линий толщиной в один пиксель та еще задача!

Для целей сглаживания (anti-aliasing) применяются не пиксельные координаты, а логические. В разных методах сглаживания применяются разные разные способы сопоставления логических и пиксельных координат.  В Qt, например, при выключенном сглаживании пиксели рисуются справа и снизу от логической точки, при включенном сглаживании - вокруг математической точки. В AGG строго вокруг логической точки в любом случае; для рисования примитивов в один пиксель созданы отдельные рендереры.

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

[valexey]

Субпиксельное сглаживание оно ведь учитывает специфику TFT-матрицы, поэтому сглаживание далеко не всегда субпиксельное. Особенно не шрифтов, а просто линий.

А Qt без сглаживание смотрится просто отвратно. Там такие мохры у линий вылазят, это что-то.

Лучшее сглаживание – это dpi хотя бы как у iPhone 4 и никакого софтверного сглаживания.

[Димыч]

Субпиксельных сглаживаний много

То, что заявлено MS как ClearType - да, пытается учитывать то, что вывод будет идти на TFT матрицу. В других случаях оно никак не связано с физической поверхностью вывода графики.

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

[valexey]

Субпиксельных сглаживаний много

То, что заявлено MS как ClearType - да, пытается учитывать то, что вывод будет идти на TFT матрицу. В других случаях оно никак не связано с физической поверхностью вывода графики.

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

Ой, ну таки не надо пытаться что-то куда-то вешать разработчику приложений мобильные платформы, которым я таки периодически являюсь. :-)

В Симбиане нет сглаживания, в iOS нет сглаживания, и все отлично смотрится. Просто потому, что dpi высокое. Нет сглаживания, нет и артефактов и работает быстрее.

Про мелкософты не скажу, ибо не интересуюсь, но вот таки в Haiku рендерер шрифтов таки умеет использовать субпиксельное сглаживание. И я видел работы по субпиксельному сглаживанию уменьшеных картинок.

Но сглаживание это от бедности. Для того, чтобы было нормально, нужно нормальное dpi. На уровне dpi принтеров лазерных.

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

[Димыч]

Хороший DPI это круто, не спорю. На iPhone действительно все смотрится круто.
В Haiku шрифты как рас сглаживаются AGG И там субпиксель это не точка в троеточии, а 1/256 пикселя.
Приведу две картинки с сайта AGG. Один и тот же текст сдвигается на 1/10 пикселя. с субпиксельным сглаживанием и без оного. Там, где логическая точка равна 1/256 пикселя результат оччень даже симпатичный. Но, возвращаясь к вопросу об округлении, чтобы нарисовать линию в один пиксель надо постараться и поиграться с координатами.

[valexey]

Хороший DPI это круто, не спорю. На iPhone действительно все смотрится круто.
В Haiku шрифты как рас сглаживаются AGG И там субпиксель это не точка в троеточии, а 1/256 пикселя.
Приведу две картинки с сайта AGG. Один и тот же текст сдвигается на 1/10 пикселя. с субпиксельным сглаживанием и без оного. Там, где логическая точка равна 1/256 пикселя результат оччень даже симпатичный. Но, возвращаясь к вопросу об округлении, чтобы нарисовать линию в один пиксель надо постараться и поиграться с координатами.

Epic fail – в обоих случаях рендеринг шрифта таки использует оную троеточку. Предлагаю увеличить картинку и заценить прекрасное расслоение одной линии на три. Позиционирование изображение тут да, субпиксельное (даже если убрать троеточку), но сглаживание тут обычное, попиксельное :-) Попиксельное сглаживание позволяет делать субпиксельное позиционирование.

[valexey]

И да, таки на счет Haiku я в курсе, потому как я этой системой пользуюсь периодически, ну и вообще я старый BeOS'ник :-) И там (Haiku) шрифты умеют как просто через grayscale/alpha сглаживаться, так и использовать субпиксельное сглаживание.

А позиционирование с точность в 1/256 пикселя просто потому, что альфаканал у нас имеет диапазон значений от 0 до 255 :-)

Кстати, очень интересно было бы посмотреть на это все не в rgba, а в yuv420p например :-) Что-то мне подсказывает, что там будет фиг а не позиционирование с десятыми долями точек без цветовых артефактов. Ибо там даже нормально с точностью до одной точки не всегда получается сделать.

[Димыч]

расслоение одной линии на три.

Ну где на три, а где и на пять-шесть.
Этот текст отрендерен, вероятнее всего, в рендерере RGBA или BGRA, что дает размытие черного цвета на составляющие при субпиксельном сдвиге. Ничего криминального, нормальный эффект. При применении Grayscale renderer было бы строго серенькое с черненьким, т.е. никакого цвета.
Еще раз подчеркнуть хочу, что субпиксельное сглаживание - это способ работы с картинкой в логических координатах, причем эти координаты на два-три порядка отличаются от пиксельных координат. Делать это имеет смысл только при относительно низких DPI. Никакого отношения к использованию TFT и факта разложения пикселя на тройку цветов в общем случае это не имеет.

О чем спорим?

[valexey]

Кстати, вот на этой картинке из википедии:

У меня лично хуже всего смотрится линия нумер 2 – она серая, размытая, какая-то невнятная. Линия 1 и линия 3 смотрятся практически идентично, у линии 3 чуть виден красноватый отблеск по верхней кромке, в остальном они практически идентичны. Линия 1 без сглаживания вообще, линия 2 с попиксельным сглаживанием (и естественно субпиксельным позиционированием), линия 3 с субпиксельным сглаживанием.

Смотрю с ноута 15-шки, разрешение 1440x900. Не вижу причин использовать линии типа 2 вообще. Если только у кого-то старые десктопные мониторы с 72 dpi или около того остались еще. Если нужно позиционирование точнее 1 пикселя, тогда имеет смысл использовать линии третьего типа.

Статья в вики

PS. Посмотрел на эту картинку с iPhone, различий в линиях не увидел вообще.

[valexey]

расслоение одной линии на три.

Ну где на три, а где и на пять-шесть.
Этот текст отрендерен, вероятнее всего, в рендерере RGBA или BGRA, что дает размытие черного цвета на составляющие при субпиксельном сдвиге. Ничего криминального, нормальный эффект.

Это не так хотя бы потому, что первый образец по определению никто субпиксельно не сдвигал, сдвигали четко на 1 пиксель рывком, так вот, там в точности то же самое расслоение. Кроме того, при определенном значении субпиксельного сдвига расслоение на второй картинке должно было бы полностью пропасть, этого не случилось.

Отрисовка шла скорее всего через freetype (agg это умеет), а freetype умеет субпиксельно сглаживать при рендеринге, в отличае от agg. Вообще отрисовка шрифтов не показательна, ибо тут слишком много слоев рендеринга наворочено. В частности зависит и от самого шрифта многое, от того же хинтинга например. :-)

[valexey]

И таки да. спорим мы о терминах :-) Это всегда очень увлекательно. :-)

Я таки предлагаю не путать субпиксельное позиционирование граф. элемента с субпиксельным сглаживанием.

[valexey]

Набор операций сравнения действительных чисел <, =, > заменить на один из наборов <, >= или <=, > .

И что это таки даст?
С любым из этих наборов я смогу проверить на строгое равенство и внезапно получить хрень.
Ну: пусть у нас есть < и >=

Код: [Выделить]

a, b: REAL;
is_eq : BOOL;

is_eq := NOT ( (a < b) OR (b < a) )
Тут достаточно одного < :-)

[vlad]

Набор операций сравнения действительных чисел <, =, > заменить на один из наборов <, >= или <=, > .

И что это таки даст?
С любым из этих наборов я смогу проверить на строгое равенство и внезапно получить хрень.

Не, понятно, что можно получить хрень. Просто если хрень получается громоздкая, то больше шансов задуматься, прежде чем ее написать