User Tag List

Показано с 1 по 10 из 36

Тема: Чанка 2х2

Древовидный режим

Предыдущее сообщение Предыдущее сообщение   Следующее сообщение Следующее сообщение
  1. #5

    Регистрация
    09.09.2018
    Адрес
    г. Саратов
    Сообщений
    438
    Спасибо Благодарностей отдано 
    144
    Спасибо Благодарностей получено 
    115
    Поблагодарили
    50 сообщений
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Если не возражаешь, давай детально разберем твоё сообщение. Так сказать для так неучей как я.
    Цитата Сообщение от Lethargeek Посмотреть сообщение
    Блин. Ты не биты обрабатываешь, а ПИКСЕЛИ. Ошибку бросаешь в те же самые ПИКСЕЛИ, в которые предписывает конкретный алгоритм, какой ты там выберешь (того же Флойда-Стейнберга). Вопрос к том, к каким ЦВЕТАМ ты ПРИВОДИШЬ пиксели.
    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
    Как видно и цветов может быть больше. Только их нужно грамотно увязать.

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

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

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

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Похожие темы

  1. Заполнение чанка
    от GM BIT в разделе Программирование
    Ответов: 3
    Последнее: 12.08.2011, 17:13

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •