ну какбэ https://en.wikipedia.org/wiki/Dither
- - - Добавлено - - -
и далее по ссылкам под картинками, например
https://en.wikipedia.org/wiki/Floyd–Steinberg_dithering
формулы простые совсем
Вид для печати
ну какбэ https://en.wikipedia.org/wiki/Dither
- - - Добавлено - - -
и далее по ссылкам под картинками, например
https://en.wikipedia.org/wiki/Floyd–Steinberg_dithering
формулы простые совсем
Lethargeek, формулы может и просты, только вот хорошо бы ещё и разбираться в теме, с чем у меня туго, так как от графики и разных художеств я очень далёк. Мозги заточены под другое. Тут просто выхода иного нет :)
Теорию уже немного начитался. Тут вот в чём вопрос: все статьи относятся к картинкам где у каждого пикселя свой цвет. На Профи же два цвета на 8 точек. То есть понятие "левый"/"нижний" пиксель не очевидное. Если пиксель в начале байта, какой пиксель считать "слева", тот который в этом байте или тот который уже в следующем байте?
Как теорию подтянуть под наши реали?
Изначально картинки готовятся во внешних программах, они всё это проделывают сами. "Размытие" получается уже после адаптации к экрану Профи. Когда применять теорию и какую? Не пойму как в теории перейти от цвета на точку, к двум цветам на байт.
Применять что-то после адаптации уже поздно, многие детали утеряны. Применять до - так оно как бы уже применялась (во внешних программах). ИМХО тут вопрос посложнее да же приведения к двум цветам. Тут как нужно и цвета сохранить, и пиксели встроить так что бы сохранить детали.
Мне не хватает теоретически-практических знаний. То что для художника очевидно, для меня темный лес.
Есть мысль сделать два прохода. На первом приводим как сейчас. На втором каждый пиксель результата сравниваем с оригиналом, если он стал темнее/светлее более чем на некий порядок, меняем его значение.
при распределении ошибки попробуй выбирать внизу ближайший цвет из доступных двух
для начала сделай в один проход
Извини, если достал.
На первом этапе нет двух цветов на байт, у каждого пикселя свой цвет.Цитата:
Сообщение от Lethargeek
Нужно сначала привести всю картинку к двум цветам на байт? Но тогда теряются детали.
Или берем первые 8 точек, приводим их к двум цветам, и полученную общую ошибка на байт распределяем так же на 8 точек? А что делать с "деталями" в первом байте? Мы их теряем?
А может так, берем за основу два крайних цвета в байте, а для средних 6 из сочетания цвета и пикселей (дизеринга) пытаемся найти оптимальную комбинацию?
С одной стороны не вижу необходимости двигаться по вертикали, так как две соседние по вертикали точки могут иметь разные цвета и они уже обработаны по внешних программах.
С другой стороны, учет (и влияние) вертикальных соседей даст возможность применять более хитрые пиксельные маски (забыл правильно название) для цвета.
Нужна некая комбинация из методов поучения двухцветных и 16 цветных картинок. Когда часть цветов эмулирются плотностью пикселей с учетом деления на байты. Возможно стоит работать с исходными файлами с числом цветов более 16. Но от одной мысли об этом у меня начинаются головные боли.
ну тогда переводи построчно в два цвета, а ошибку вниз сноси попиксельно
потом переходишь к этой уже изменённой нижней строке и повторяешь