DaDither - еще одна програмка для dither-га картинок

[NEO SPECTRUMAN]

Добавил

проверяем








по крайней мере проверенные в emu палитры на вид совпадают

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

Два варианта - 200x225 и 256x256. На выходе дамп + 1 байт с кодом палитры.

замечаниЁ

1. белая рамка при сплющивании подставляется перед конвертацией


со всеми вытекающими


оно начинаит считать белый одним из основных цветом
которого на картинке может и близко не быть

тут можно сделать 3 варианта
белый фон
черный фон (именно его лучше по дефолту тк черный есть почти всегда (да и обычно на спектрумах ставят именно черный бордюр чтоб не мозолил глаза))
фон какой получитсо (тк может быть пофиг какого цвета рамка)



2. номер палитры лучше отображать и в самом редакторе
подсматривать в hex редакторе какой же номер палитры у сконверченой картинки не очень удобно
ну и это актуально наверно и для бека


3. щас нет возможности нормально выставить максимальный уровень для наиболее рационального испоользования
есть ligtness fix но оно измеряется в сферически вакуумных единицах и нужный оптимальный не поставишь

можно было бы сделать вообще несколько прессетов
255 > 85 - для RGB0 палитр в которых белый получается при помощи 3-х пикселей
255 > 128 - для палитр в которых белый получается при помощи 2-х инверсных пикселей (например зеленый+магента)
255 > 171 - для CMY подобных палитр в которых белый получается при помощи 3-х пикселей (собственно C, M, Y)

и можно было бы режим auto
когда динамический диапазон подгоняется под каждую палитру

например
если на картинке максимальная яркость 230 а в палитре есть 255 растягиваем картинку 230 до 255
если на картинке максимальная яркость 230 а в палитре только 128 то сплющиваем 230 до 128
нижний уровень наверно не нужно дотягивать до 0

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

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

или нужно как то проверять для каждой компоненты раздельно

я еще не дошел до реализации подобного
и пока правильный алгоритм действий не придумал...

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

Dec, так же наверно нужно в первом посте описать нестандартные форматы изобретенные в этой теме
ато потом затеряется в каком формете экран специалиста с атрибутами
где палитра в формате экрана львова

[Dec]

белая рамка при сплющивании подставляется перед конвертацией

А куда ее девать? Если пользователь захотел режим "сплющивания" - то это его видение композиции, и рамка является частью композиции, и ответственность за цвет рамки несет пользователь. Я могу добавить что-нибудь типа кнопки Auto, при нажатии которой цвет рамки будет подбираться автоматически на основе пикселей, расположенных вдоль рамки.

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

номер палитры лучше отображать и в самом редакторе

Согласен.

есть ligtness fix но оно измеряется в сферически вакуумных единицах и нужный оптимальный не поставишь

Как работает Ligtness fix:
При отрицательных значения светлые цвета затемняются, был диапазон 0-100, станет диапазон 0-80.
При положительных значения темные цвета засветляются, был диапазон 0-100, станет диапазон 20-100.
Единица измерения - проценты.
Модификация цвета производится в цветовом пространстве CIELab путем модификации L-компоненты.

нужно в первом посте описать нестандартные форматы изобретенные в этой теме

Согласен. Но по сути изобретен лишь один формат - для Львова. Для Специалиста нет какого-то своего проприетарного выходного формата кроме bmp/png/gif.

[NEO SPECTRUMAN]

Для Специалиста нет какого-то своего проприетарного выходного формата кроме

просмотрел
я думол и для него сделано
надо наверно сделать
чтоб не писать отдельный png2specialist конвертер

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

Модификация цвета производится в цветовом пространстве CIELab путем модификации L-компоненты.

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


я умножал на коэфициент уже в линейном RGB пространстве
белый то получается белым но другие цвета чота ярче чем надо...


если подумать
по идеи нужно умножать на 0.3333... 0.5 0.6666... еще в sRGB пространстве
но я не помню почему я отказался от этого в пользу умножения в линейном пространстве

в итоге у меня щас такое результат при компрессии кодерских цветов до 85

белый получился срезанным затемненным

а по идеи результат должен быть такой


замена черного на синий в желтом должна давать белый
замена черного на красный в голубом должна давать белый

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

Модификация цвета производится в цветовом пространстве CIELab путем модификации L-компоненты.

наверно это дает совсем не правильный результат

синий уж совсем выпячиваетсо


кстате этой коррекции нету для режима с выбираемой поллитрой

сама тестовая картинка

[Dec]

надо наверно сделать
чтоб не писать отдельный png2specialist конвертер

Я ведь не против. Но нужно что бы Специалистоводы рассказали мне, как им удобнее. А то я сделаю формат, а пользоваться им не возможно будет.

в итоге у меня щас такое результат при компрессии кодерских цветов до 85

Что такое 85? Конвертация в какую палитру?

[NEO SPECTRUMAN]

Что такое 85? Конвертация в какую палитру?

85 это сплющенные 255 до 85 в sRGB диапазоне
для конвертации в 4 цветные палитры с одними только кодерскими red, green, blue, black

цифра со времен конвертаций в фотошопах

для линейного диапазона наверно это будут другие цифры
а у себя я наверно подставил фиг знает что

щас потыкаю у себя

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

ну до
поклацал цифры в линейном диапаозоне результат посредственный


щас когда делая сплющивание до 85 еще когда изображение в sRGB
итоговое изображение не выходит на нужную яркость


то есть сумарно 3 канала дают не 85 яркость а большую (что вобщем то и так было нам уже известно...)

и коррекцию диапазона нужно делать все таки в sRGB пространстве (тогда будут сохранятся именно вопсринимаемые соотношения яркостей)

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

вощем происходит какаято дичь

ставлю коэфициент 0,5 для sRGB
и все правильно


каждый канал сохраняет свою яркость


ставлю расчетный 0.612501025 (0.333333 в линейном пространстве (оно же 85 для фотошопов))
и появляется перегрузка




меньший коэфициент дифузии тоже не спасает
так что это не изза текучки

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

методом научного тыка подобрал коэфициент для sRGB 0.54735


изображение разбирается на ~ равномерные компоненты




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

ну и на реальном изображении

0.54735 для sRGB пространства


0.333333 для линейного RGB пространства (оно же -lc 85 в NDither-е)

видно перегрузку на фоне

0.090841711 для линейного RGB пространства

явно недотягивает

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

sRGB-шное 0,54735 переводится в линейное как 0,260514255
но чего так?
на суммарную единицу это не выходит 0,781542765

можот дето у меня ошибки левые коэфициенты...
тк у меня сорец сильно обвешан экспериментальными свистелками и перделками

[Dec]

Что бы сохранить соотношение яркостей при затемнении цветов - то на мой взгляд правильным решение является умножение на ровно 0.5 в линейных координатах.Все сложнее, чем я думал. "Белый" на скриншоте ниже выглядит темнее "желтого".

Я поправил алгоритм Ligtness fix, теперь коррекция производится в линейных RGB. И если в режиме Львова выставить значение -50, то для твоей тестовой картинки для палитры Black/Red/Green/Blue получается минимальная дельта, и она выбирается автоматически. Сама конвертированная картинка выглядит так:



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

И конкретно для палитры Black/Red/Green/Blue можно попробовать использовать фильтр Байера.

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

Расширил границы fix до -90...90. Примерно на -60 "белый" становится светлее "желтого".

[NEO SPECTRUMAN]

так лучшо
но перегрузка остается




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

то на мой взгляд правильным решение является умножение на ровно 0.5 в линейных координатах

оно то правильное НО
восприятие логарифмическое

+-1% на линейной яркости 0
намного различимей чем
+-1% на линейной яркости 255

а гамма коррекция sRGB как раз делают шкалу логарифмической

я как раз хотел прикрутить себе такой учет разницы восприятия для разной яркости
чтоб не терять детали на черном и чтоб подбиралось близкие цвета с учетом различимости
в итоге у меня получился практически sRGB
и дизеринг разумеется стал работать на нем как в фотошопе...
...конечно у меня еще есть идея как подобное сделать
но это нужно будет опять плясать с бубном...


ну и в случае цветов полученных шахматкой
умножение в линейном пространстве наверно тоже испортит соотношение между получаемыми цветами
хотя это еще надо экспериментально уточнить


если подумать то вариант с умножением в sRGB тоже не правильный
надо подумать еще
но щас что то считать нет никакого желания
добавлю в todo

наверно всетаки правильно умножение в линейном
оно будет сохранять линейные соотношения между цветами
как раз эти соотношения и воспринимаются

и так как sRGB шкала логарифмическа ТО получается
можно быстро делать ~линейное управление яркостью
при помощи инкримента\декремента в sRGB пространстве

[Dec]

Я теперь склоняюсь к мысли, что правильно умножать на 1/3, поскольку белый получается суммой трех пикселей B (яркость 0.072187), R (яркость 0.212655) и G (яркость 0.715158). И усредненная яркость этого кластера 0.33333(3).

[NEO SPECTRUMAN]

на 1/3

это и есть то 85
но у меня чего то появляется при этом перегрузка

проверь у себя
может это у мну косяки

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

вот тут фон явно срезался (справа снизу например)


да и на тестовой картинке у меня срезался белый

но множителе подобранном ручками фон целый


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

чисто по идеи на все случаи жизни должны быть множители
0,3333
0,5
0,6666

[Dec]

Ты можешь скачать обновленную версию и выставить -67. что соответствует умножению на 0.33.