nedoPC.org

Выложил версию 1.0.2, в которой добавил ещё 2 способа обхода спектра:


Причём формат WHI файла расширился так, что старые файлы всё ещё читаются (ранее написано как я это сделал)

https://gitlab.com/shaos/graphin/-/tree/main/WALSHEXP

P.S. Обновил приаттаченную к первому сообщению версию - теперь там тоже 1.0.2

Таки будет у меня комментарий

Но только когда WHI файлы первой версии (сигнатура W1), которые кодируют один квадрат, будут склеиваться вместе (можно через COPY /B это делать) и комментарий, идущий после сигнатуры W0, будет нужен для указания что с этими квадратами делать, например текст "320x200" будет означать что далее идущую цепочку квадратов надо выложить как чёрно-белую картинку в экран 320x200 слева-направо сверху-вниз, а скажем "RGB320x200" будет говорить о том, что далее идут квадратики по каналам: R,G,B,R,G,B и т.д. которые также будут заполнять экран 320x200. Анимацию даже можно аналогичным образом задавать указав комментарий "MOVIE"

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

Довольно прозрачно описано. у jpg кроме маркера добавлено слово - длина текстового комментария.
Заодно формат кодировки ANSI, что придаст свою головную боль.

У меня будет просто строка заканчивающаяся нулём

Пока выложил свои эксперименты с отрисовкой RGB картинок используя 256-цветную палитру:

https://gitlab.com/shaos/graphin/-/blob/main/EXAMPLES/RGB_VIEW.CPP

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

Заодно выложил обновлённую версию Walsh Explorer v1.0.3 (в первом сообщении этого топика архив также обновлён):

https://gitlab.com/shaos/graphin/-/blob/main/WALSHEXP/

В версии 1.0.3 заточка под нового графина и меню обхода матрицы отсчётов спектра слегка переставил:

Думаю какую-то автоматизацию в Walsh Explorer прикрутить, чтобы разные опции пробовать при сохранении WHI-файла не вручную, а программно (через внешний файл команд, который будет генерироваться другой программой). Потом пользуясь полученными результатами приделаю в Walsh Explorer адаптивный алгоритм (сохранение файла в самом компактном виде по заданному качеству Q). Потом поддержку цветных картинок прикручу (пользуясь наработками, что изложены выше) и только потом создам отдельную либу кодера-декодера для включения в сторонние программы (в том числе в наш будущий графический редактор nedopixels).

P.S. Сделал автоматизацию по быстрому на уровне графина (но пока не выкладываю). Команды в ней задаются в текстовом "скрипте" имя которого даётся как аргумент при вызове WALSHEXP.EXE и который выглядит вот так:
Этот скрипт открывает файл FEMALEB.BWS, выбирает сохранение WHI устанавливая нужные опции (менюшки идентифицируются первой строчкой меню, которая обычно обозначает заголовок, а панельки - количеством видимых элементов) и задавая имя сохраняемого файла FB6-134 после чего программа закрывается (т.к. последней командой идёт выбрать Exit в главном меню)...

Выложил версию 1.0.4 с автоматизацией

https://gitlab.com/shaos/graphin

Архив в первом сообщении топика тоже обновил

P.S. Также в меню задания битности для квантования сделал стартовое значение 12 вместо 13, т.к. 13 это слишком много - мой Хаффман не справляется с таким количеством литералов...

Вот с помощью GIMP слепил вместе сжатые независимо друг от друга каналы RGB с разной битностью, примерным показателем качества Q и коэффициентом сжатия K:










Такое ощущение, что качество надо задавать не от 0 до 99, а 1,2,3,4,5,6,7,8,9 ибо скачки большие (качество я тут считал как процент оставшихся ненулевых квантованных отсчётов по отношению к количеству ненулевых неквантованных отсчётов коих было порядка 86% в данном конкретном изображении) либо вообще программно прогнать все значения битностей от 12 до 3 и показать пользователю все варианты, чтобы он выбирал сам...

Сохранил оригинальную цветную картинку как JPEG с качеством от 0 до 100 с шагом от 1 до 5:
теперь сравним WHI-картинки с сопоставимыми по размеру JPG-ами:
и выглядит так, что JPEG цветную картинку сжимает лучше (точнее упаковывает в тот же размер лучшее качество - потому что subsampling?):

Я придумал как поддержать Q с мелким шагом от 1 до 99

Просто начинаем отбрасывать отсчёты (стартуя с правого-нижнего угла спектра) -1 и +1 пока не доберёмся до нужного процента
Если выкинув все -1 и +1 не добрались до нужного процента, то начинаем выкидывать -2 и +2 и т.д.
По сути квантование это и делает, только очень грубо - сразу помногу, а так мы как бы добавляем мелкую корректировку, чтобы подкрутить процент до желаемого

P.S. Обдумывая будущий адаптивный алгоритм сохранения в формат WHI посохранял красную составляющую вышеразмноженной картинки (FEMALER.BWS) с разными параметрами (ниже K означает коэффициент сжатия, а Q - качество как процент отквантованных ненулевых отсчётов к количеству неквантованных ненулевых отсчётов в непожатом спектре):

Левая колонка говорит нам о том, с какого значения начинается квантование (это самое большое квантованное значение - всё что амплитудой больше сохраняется отдельно как есть - я это делаю из-за того, что несколько больших отсчётов обычно "выскочки" по амплитуде и их из квантования лучше исключить, чтобы попусту не размазывали динамический диапазон). Качество Q=99 означает, что все ненулевые отсчёты остались нетронутыми (максимально возможное качество). Как можно видеть, одни и те же значения качества попадаются в разных битностях, но с разным началом квантования - при этом коэффициент сжатия тоже не сильно гуляет и примерно соответствует качеству. Получается, что можно нужное качество найти для разных битностей (подрезав слабые отсчёты как я писал чуть выше), а потом чисто по подсчитанной ошибке (и по итоговому коэффициенту сжатия) автоматически можно решить какие параметры сжатия в итоге выбираются для сохранения итоговой картинки.

P.P.S. Вот раскрасил в разноцветные заливки для пущей понятности:


Чтобы сохранить данное изображение вообще без квантования и без отдельного запоминания "выскочек" (за исключением отсчёта [0][0] который всегда положительный, всегда больше всех по амплитуде и всегда сохраняется отдельно), надо выбрать 10 бит/отсчёт т.к. в данном случае надо уметь сохранять -388 и +388, которые упаковываются в 2^9 плюс 1 бит знака, т.е. 10 бит на отсчёт - при 10bits/sample все показатели Q в колонке будут 99 (не пишу 100 т.к. отсчёты после Уолша на самом деле имеют дробную часть, которую я отбрасываю, ну т.е. уже не 100% восстановление, но близкое к тому)...

К вопросу о том отличаются ли визуально восстановленные картинки скажем для Q=36 в случае 7 битов, 6 битов и 5 битов - да, отличаются:






Именно поэтому нужно ещё ошибку учитывать, которая в данном случае принимает значения 5%, 6% и 7% соответственно (однако 7-битный вариант имеет коэффициент сжатия похуже):

P.S. Коэффициент сжатия тут получились выше, чем в таблице в предыдущем сообщении, т.к. тут я пользовался методом "Huffman after RLE", а при составлении таблицы вчера я делал "Huffman only", который даёт результаты лучше только для высокой битности когда мало нулей.

P.P.S. Добавил ещё один алгоритм обхода "Boustrophedon Diagonal" - это когда диагональные линии не обрываются, переходя на начало, а идут сначала в одну сторону, потом в другую - оно должно дать чуть лучшую локальность для RLE чем просто Diagonal (хотя пока они выдают идентичные результаты по степени сжатия):

Я хотел выбирать начало квантования по тому месту, в котором оно более-менее выравнивается - например 3 идущие друг за другом (упорядоченные) абсолютные величины отличаются не более чем на 7% (или 5 единиц? или 2 шага квантования?) - это замечательно работает для вышеприведённой картинки для 7 битов и 6 битов - достаточно ровный блок Q начинается на 125, однако в случае 5 битов почему-то ровный блок качеств начался не с 125, а с 124:




P.S. Если плясать от шагов квантования, то для 7 бит это 1/64 (без учёта знака), для 6 бит - 1/32 и для 5 бит 1/16.
125/64=1.95 (двойной шаг - 3.91) - и 123 отличается от 125 на 2 единицы (полтора шага квантования брать?)
125/32=3.91 (двойной шаг - 7.81 и полуторный - 5.86) - полтора тоже срабатывает
а вот для /16 первый раз оно сработает уже на 157-148-145:



P.P.S. Вообще надо квантование применять к диапазону -125...+125 - поэтому умножаем на 2...

Возможно как раз от Q=99 и надо плясать (наплевав на выбор старта исходя из шага квантования и т.д.) - выбираем самую высокую битность (в данном случае 10bits/sample) и там поиск начала квантования НЕ нужен - отсчёты кодируются все как есть (кроме [0][0] который всегда отдельно). Далее отбрасываем низкие по амплитуде отсчёты для достижения нужного Q (если Q=99 то останавливаемся прямо сразу). Далее идём в следующую битность - 9bits/sample и стартуем сначала квантования 255 (в этом случае опять же Q будет 99) и двигаемся вверх, ища самую первую строку, где Q больше либо равна желаемой и начинаем отбрасывать низкие по амплитуде отсчёты там пока не достигнем желаемой Q, далее двигаемся в 8bits/sample и стартуем с уровня 127 и т.д. (совсем до 2bits/sample доходить ненадо ибо количество "выскочек" в формате WHI волюнтаристски ограничено числом 100, включая [0][0], поэтому если 2^(N-1)-1 сидит глубже, чем 100 отсортированных по амплитуде абсолютных значений отсчётов, то стартуем с 99-го и если показатель Q для него уже меньше желаемого, то эту битность даже не рассматриваем). По ходу пьесы сохраняем (запоминаем) все параметры сжатия и выбираем самое сильное для желаемого Q (причём то, для которого показатель ERR не сильно страшный) - вобщем как-то так...