Чанка 2х2

[tae1980]

Ищу материал по организации чанки 2х2.

Как грамотно построить блоки чанки? Их можно сделать приличное количество, но большая часть будет зеркальным отображением друг друга. Нужно понять, какие конструкции блоков лучше всего взять и как распределить их по "яркости".

Хочу попробовать применить технология при конверсии картинок с IBM под экран Профи.
Из ходя из структуры экрана, на 4 блок чанки 2х2 можно будет использовать 4 цвета, 2 для верхней и 2 для нижней линии, но общих для линии из 4 блоков чанки.

Что видится в первом приближении.
Берем два вертикальных байта графики. Для каждого находим:
* два самых частых цвета, или по другим критериям (например, самые яркие/темный цвета)
* выстраиваем все используемые цвета по яркости (на основе приведения цвета к градации серости).
* как-то цвета нужно соотнести с чанками или построить чанки из ходя из текущих условий.

После чего если цветов в обоих байтов всего один или два, выводим как есть.
Если в одном из двух байтов цветов 3 и более, начинаем обработку. Для 4 точек 2х2 исходной картинки находим усредненный цвет, и заменяем их на соответствующую ему чанку. Но вот как понять как она должна выглядеть?

Как рассчитывать чанки: для каждой линии из 4 блоков с учетом их цветов или для всей картинки сразу?

Есть только общая идея. Нужна консультация художника и других знающих людей.

[Advertiser]

[Shiny]

чанки 2х2 тут не причем, они используются для картинок иным методом.

Генерация описана здесь, например:
https://zxaaa.net/view_demo.php?id=7885

[tae1980]

Shiny, Спасибо, материал очень хороший. Главное очень доходчивый и с примерами. Что встречается очень редко.
Но ИМХО проблема с конверсией картинок для Профи более сложная. Весь материал посвящен картинкам с одинаковым цветовым разрешения на всей площади. Не важно это два цвета или 256 цветов.
Тогда как на Профи 2 цвета на 8 точек. От сюда я не пониманию как разбрасывать ошибку. Например, берем первый бит в байте, куда бросать его ошибку? В следующий бит или в следующий байт? Кидать в бит в 90% бесполезно, так как они взаимосвязанные.
Подготовка изображения для конверсии начинается с его обработке во внешних программах (например фотошоп), где оно масштабируется, цвета приводиться к 16 из 256 палитры Ппрофи. То есть всё что описано в материале делает внешняя программа. Мне нужно это перенести в формат Профи.
На текущий день я реализовал 6 алгоритмов расчета 2 цветов на 8 точек. Вот пример их работы.

Скрытый текст

[свернуть]

На мой взгляд лучший результат у шестого метода. Но и там видны горизонтальные полосы, возникшие из-за объединения цветов, когда в исходных 8 точках было 3 и более цвета. Моя задача избавиться от них. Вот как это сделать я пока не знаю.

Тут и возникла идея использовать пиксельные маски для цветов. Но как это сделать внутри одной линии тоже не понятно. Что и заставило подумать о чанках. Думаю их использование позволит передать более 16 цветов на картинки и избавиться от горизонтальных полос.

Так что вопрос открыт.

[Lethargeek]

Тогда как на Профи 2 цвета на 8 точек. От сюда я не пониманию как разбрасывать ошибку. Например, берем первый бит в байте, куда бросать его ошибку? В следующий бит или в следующий байт? Кидать в бит в 90% бесполезно, так как они взаимосвязанные

Блин. Ты не биты обрабатываешь, а ПИКСЕЛИ. Ошибку бросаешь в те же самые ПИКСЕЛИ, в которые предписывает конкретный алгоритм, какой ты там выберешь (того же Флойда-Стейнберга). Вопрос к том, к каким ЦВЕТАМ ты ПРИВОДИШЬ пиксели. Всей-то разницы, что при конверсиях на пц обычно заранее задают просто одинаковую глубину цвета (битность) любого пикселя, но самом деле с тем же успехом задавать можно несколько произвольных целевых палитр с произвольным разбиением исходного изображения на участки любых форм и размеров. У тебя участки будут группами 8x1 пикселей, каждая со своей целевой палитрой в два цвета, к ним пошагово и приводишь. А еще НЕПРИВЕДЁННЫЕ пиксели, включая правые в той же группе, могут быть пока что ЛЮБОГО цвета. А также отсюда следует, что задача выбора целевых палитр - полностью самостоятельная, по своему какому-либо критерию. Притом выбор может быть статическим (все целевые палитры для всех групп целой картинки задать заранее) и динамическим (пересчитываешь целевую палитру каждый раз при переходе вправо в новую группу). Пробуй оба.

[Shiny]

Открыт вопрос или нет, но есть реализации разные: - покурить dithering 16 colors; - поизучать исходники bmp2scr(хотя автор сам признает, что в них трудно разобраться)

[tae1980]

Если не возражаешь, давай детально разберем твоё сообщение. Так сказать для так неучей как я.

Блин. Ты не биты обрабатываешь, а ПИКСЕЛИ. Ошибку бросаешь в те же самые ПИКСЕЛИ, в которые предписывает конкретный алгоритм, какой ты там выберешь (того же Флойда-Стейнберга). Вопрос к том, к каким ЦВЕТАМ ты ПРИВОДИШЬ пиксели.

1. ИМХО с сточки зрения Профи это всё таки биты, а то что раскрашены, это частный случай их применения. Я кончено могу ошибаться, то это диктует физическое строение экрана.
2. Все описанный метод УЖЕ применялись с данной картинке (я использую фотошоп). Картинка уже 16 цветов из 256 в палитре Профи. Есть смыл применять их ещё раз? Тем более, что шаг между цветами у Профи весьма ограничен.
3. При переводе цвета в биты у нас из 3-8 цветов остается только 2. И тут дилемма, какие оставить. 6 удаляемых цветов привожу по формуле к ближайшему из двух основных цветов:
Цитата:
(R0,G0,B0) - цвет, аналог которого нужно найти в палитре.
(Ri,Gi,Bi) - i-тый цвет в палитре.
Различие цветов будем оценивать с помощью следующей функции: fi = 30*(Ri-R0)2+59*(Gi-G0)2+11*(Bi-B0)2.
Для которого fi принимает минимальное значение, это и будет искомый цвет.
====

Выше писал, что в попытках найти лучший алгоритм было разработано 6 вариантов. Вот их описание (готовлю материал к хелпу):
1. По байту. Два самых частых цвета. - тут я думаю понятно, берем за основу два наиболее часто встречающийся цвета.
2. По байту. Два самых темных и светлых цвета. - принцип тот же, только берутся два противоположные по яркости цвета. Цвета сравниваются по градации серости.
3. Комбинированный, учёт крайних совместный. - комбинация первых двух, если оба крайних цвета максимальные/минимальные по яркости в байте, то используется второй метод, иначе первый.
4. Комбинированный, учёт крайних раздельный. - то же но крайние цвета оцениваться отдельно. Если какой либо из них самый светлый/темный цвет, он используется как один из основных, вторым использоваться самый частый. Так же есть контроль, что бы цвета не оказались одинаковыми.
5. По байту. По крайним цветам. - Тут за основу берутся два крайних цвета в байте.
6. По полубайтам. Самый частый цвет. - Вот тут интересно. После общения в эхе (особая благодарность Lethargeek, за терпение) и начитки статей, пришла мысль, что нужно как-то дробить информацию и работать с каждой частью в отдельности. А как это сделать в наших условиях? Только делить байт по полам. Что и было сделано (ох и намучился я с реализацией). Байт делиться на два полубайта, для каждого и них определяться самый частый цвет. Которые и используются как основные. Проверяться частота появления у крайних цветов каждого полубайта, если она такая же как и у признанного самым частым, то используется крайний цвет. Проводится контроль выбранных цветов, если он одинаковые, то берется следующий цвет из левого полубайты. Если цвета в нём кончились, начинаем их брать из правого полубайта.

Проблемы начинаются когда подряд идут два и более пикселя разными, но близкими цветами (например, градиент). Было 01234567, а получим 00007777 на одном и 77770000 на соседнем байте. От сюда и полосатость.
А хотелось бы получить 00070777 или иной вариант.

Если вернуться к идеи чанки то аналогичная ситуация может разрешиться так (вариант):
01234567 -> 00070777
01234567 -> 11161666
Как видно и цветов может быть больше. Только их нужно грамотно увязать.

Всей-то разницы, что при конверсиях на пц обычно заранее задают просто одинаковую глубину цвета (битность) любого пикселя, но самом деле с тем же успехом задавать можно несколько произвольных целевых палитр с произвольным разбиением исходного изображения на участки любых форм и размеров. У тебя участки будут группами 8x1 пикселей, каждая со своей целевой палитрой в два цвета, к ним пошагово и приводишь. А еще НЕПРИВЕДЁННЫЕ пиксели, включая правые в той же группе, могут быть пока что ЛЮБОГО цвета. А также отсюда следует, что задача выбора целевых палитр - полностью самостоятельная, по своему какому-либо критерию. Притом выбор может быть статическим (все целевые палитры для всех групп целой картинки задать заранее) и динамическим (пересчитываешь целевую палитру каждый раз при переходе вправо в новую группу). Пробуй оба.

Если правильно, имелось ввиду: проведение 3-8 цветов к двум основным внутри одного байта?

Предлагаемый алгоритм для каждого байта:
1. Определяем два основных цвета в байте.
2. Берем первый цвет, приводим к одному из двух цветов,
3. Получаем ошибку. (входит, что передать ошибку можем только вправо, так как байт линейный)
4. Передаем её следующему цвету в байте.

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

[tae1980]

Shiny, так в том том то и вопрос, что исходники сложно читать. Я и прошу ссылки на статьи и ли объяснить. Тем более меня сейчас больше интересует теория чем практика.

[Shiny]

Shiny, так в том том то и вопрос, что исходники сложно читать. Я и прошу ссылки на статьи и ли объяснить. Тем более меня сейчас больше интересует теория чем практика.

Честно говоря, я и сам не видел толкового описания, только решения с сырками. Тут или читать, или учиться. Другого не знаю.

[tae1980]

Мысли в слух.
А что если так: берем две линии по 8 цветов подряд (верхняя и нижняя). Для них находим общие два самых темных и два самых светлых цвета. Самый темный и светлый цвет берутся как основные для верхнего байта, остальные для нижнего.
После чего разбиваем линии на блоки 2х2. Для каждого блока считаться среднюю яркость. После определяем значение каждого бита блока: если цвет темнее среднего бит=1, если ярче бит=0. Собираем два байта из блоков.

[Shiny]

Непонятен смысл телодвижений. Разобраться самостоятельно? это вы форумом ошиблись, есть stackoverflow и другие ресурсы.
Написать просмотр графики под Профи? это утопия. Есть немало готовых конвертеров.

Если не ошибаюсь, 2х2 использовался в BBC Micro Image Converter

- - - Добавлено - - -

и здесь еще:
http://kecskebak.blogspot.com/2010/