применениие плитошного сканироввния
для борьбы с текучкой
d = 1.0
обышный NDither и DaDither
![]()
не обышный NDither
к сожалению практически мало применимо
иззо длительного времени конвертации...
применениие плитошного сканироввния
для борьбы с текучкой
d = 1.0
обышный NDither и DaDither
![]()
не обышный NDither
к сожалению практически мало применимо
иззо длительного времени конвертации...
@Dec и NEO SPECTRUMAN (раз уж тут так много от него постов) - Ordered dithering планируется добавить в DaDither и NDither?
Что б вот такое получать на выходе?
(навеяно последним постом)
ну как его сделоть хз
и там ожидаетсо много всяких концептуальных проблем
вот я делол просто шахматткой
и если б оно еще не переливалось на лсдшниках...
ты мож поискать конвертор с алгоритмами Joel Yliluoma-ы
у него вроде бы пральный ордеред дизеринг
- - - Добавлено - - -
да и такой же цветопередачи может и не получитсо
флойд начинает делать нормальную цветопередачу
ТОЛЬКО если начать выходить за пределы 0...1 (фотошопы это не делают)
вместе с этой цветопередачей появляетсо и "текучка"
в ордеред дизеренге диапаазон в 0...1 видимо вообще прибит гвоздями
опять рожи кирпично белого цвета...
- - - Добавлено - - -
этот SUХХ и сферический феил
- - - Добавлено - - -
второй отожрал гиг рамы на картинке 320х200
и ниче не сконвертил...
исходя из предыдущего скриншота он тоже бесполезен
- - - Добавлено - - -
интересно как конвертят новые gimp-ы
можно сделать легкую решеточку артифактами
![]()
![]()
![]()
![]()
![]()
![]()
![]()
![]()
это как раз те самые полосочки на границах знакомест на которые жаловалсо dec
если же ошыбку не передавать за границы "плиточки"
то решеточка будет еще заметней
(правда нельзя будет выжать d=1)
надо будет попробовать глянуть
- - - Добавлено - - -
RGB vs YUV более наглядно
- - - Добавлено - - -
а еще можно обмануть "неправильные" конверторы
подсуныть им изображение с скорректированной гаммой
и пол литру с скоректированной гаммой
а потом на результат надеть правильную палитру
хотя конечно до "правильного" конвертера оно близко недотянет
да и будут потери еще до начала конвертации..
Последний раз редактировалось NEO SPECTRUMAN; 08.10.2023 в 22:12.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
вот отключил наследование ошибки у плиточек
![]()
![]()
![]()
- - - Добавлено - - -
"окно" раздачи ошибки у флойда ассиметричное и создает кашу в плитке 2х2
а вот с симетричным круглым окном
X образное окно
квадратное окно
крестообразное окно
![]()
Последний раз редактировалось NEO SPECTRUMAN; 08.10.2023 в 20:51.
вернемся к матчастям
а тошнее к весомым коэфициентом для каждого канала
опять же мы щитаем что соотношение у нас такое 4G 2R 1B (пушо лучшо еще не придумали)
наш главный тест
и "эталонная" яркость нарисованная в mspaint (c 0/7 1/7 2/7 итд количесттвом пикселей)
посчитаем количество пикселей в каждом столбце и нормализуем и помножим на 7 для наглядности
вот я думал что если предварительно применить эти коэфициенты к исходному изображению и палитре
при конвертации у нас сразу получитсо все зашибись
и не надо будет потом по 256 раз применять коэфициенты на каждый пиксель
А НИФИГА
фактически такое при подсчете ошибки
(R*2)^2
(G*4)^2
(B*1)^2
НЕ РАБОТАЕТ
я несколько раз проверял код
пробовал разные варианты одинаковые по сути
и результаты все время не правильные
если же вынести множитель за нашу сумму квадратов
которая при расчете ошибки
(R^2)*2
(G^2)*4
(B^2)*1
результат уже такой как надо
но чета с артифактами
НО ПРИ ЭТОМ
в YUV цветовом пространстве (BT.601 Kb = 0.114; Kr = 0.299)
у нас эти весовые коэфициенты каким то образом "встроенны" уже в саму формулу конвертации из Linear RGB в YUV
и если сделать (log srgb) -> (linear rgb) -> (yuv) для изображения и палитры
и просто сконвертировать с
(Y)^2
(U)^2
(V)^2
то получим
но тут ЯВНО не наше любимое 4G 2R 1B
и ступеньки кривоваты
но если почесать репу
можно подкоректировать коэфициенты
Kb = 1.0/7.0 = 0,14285714285714285714285714285714
Kr = 2.0/7.0 = 0,28571428571428571428571428571429
если бы был коэфициент kg он бы выглядел так
Kg = 4.0/7.0 = 0,57142857142857142857142857142857
тобешь Kr + Kg + Kb = 1
ну и результат такой
сравнениё
НУ А ТАК К ЧЕМУ Я ЭТО?
у нас есть атрибутные режимы
и ВОТ ДЛЯ НИХ весомые коэфициенты имеют БОЛЬШОЕ значение
вот наш новый синтетический тест
и маска для откалупывания результатов
и фотошоп чаго по идеи должно быть на выходе
тестируем дадизёр
v1
v2
ну и для теста
можот понадобитсо
ограничивать цвета атрибутного режима до 2-х
- - - Добавлено - - -
у меня
не менее не правильные результаты
тожы без учета весов
если включить YUV BT.601 (этот режим жестка заточен под RGB но все же)
а тут я ну очень хитро учитывал веса и все должно было быть зашибисть
а результат ВААЩЕ о_О
КАК?
(при этом на простых картинках все красиво)
![]()
Последний раз редактировалось NEO SPECTRUMAN; 24.10.2023 в 03:19.
больше брутфорса!
![]()
![]()
![]()
![]()
![]()
Последний раз редактировалось NEO SPECTRUMAN; 04.11.2023 в 04:21.
Запуск с параметрами из командной строки не сделать? Мне для автоматической обработки видео было бы удобнее.
Что-то средствами ffmpeg не так красиво выходит, как с помощью этого мощного приложения.
Скрытый текст
https://drive.google.com/drive/folde...xZ83juCuaBe32I
Scorpion ZS 256 Turbo+/GMX 2MB/SMUC v1.3 OP/CF-IDE 2GB/TS ARM/Covox #DD/FDD 5'25/FDD 3'5/AT Kbrd & Mouse Ctrl v2.5/Universal PS/2 Kbrd Ctrl/ZX WiFi
Leningrad 1/Sega Joy Adapter
DivGMX
ZX Spectrum +2A
ZX Evolution rev. C
TCK Computer 486DX2-66/512K Tridend 9000i/8MB SIMM72/CF-IDE 512MB/ESS 1869/CNet CN200/FDD 5'25/FDD 3'5
[свернуть]
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)