Если не возражаешь, давай детально разберем твоё сообщение. Так сказать для так неучей как я.
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
Как видно и цветов может быть больше. Только их нужно грамотно увязать.
Если правильно, имелось ввиду: проведение 3-8 цветов к двум основным внутри одного байта?
Предлагаемый алгоритм для каждого байта:
1. Определяем два основных цвета в байте.
2. Берем первый цвет, приводим к одному из двух цветов,
3. Получаем ошибку. (входит, что передать ошибку можем только вправо, так как байт линейный)
4. Передаем её следующему цвету в байте.
А что делать с цветами которые совпадают с основными? Ведь если цвет не первый, в него будет внесена поправка. А так как поправка не большая, то при приведении по формуле fi к одному из двух цветов, она будет по сути уничтожена. Или все эти вопросы не актуальны, и будут разрешены автоматически внутри алгоритма?





Ответить с цитированием