|
nedoPC.orgCommunity for electronics hobbyists, established in 2002 |
|
Last visit was: 08 Nov 2024 16:54
|
It is currently 08 Nov 2024 16:54
|
Создаём подобие JPEG для ретрокомпов (Walsh+Huffman)
Author |
Message |
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23398 Location: Silicon Valley
|
| | | | Shaos wrote: А по яркости-тёмности картинки можно сделать вывод поглядев на отсчёт спектра [0][0] - у средне-серых картинок он около 2000. У высветленных картинок он может достигать 3900, а у затемнённых уходить ниже 1000 - я видел значения 789 и даже 245. И как я писал на предыдущей странице, тот алгоритм ошибки, что я использую, занижает ошибку у высветленных изображений и завышает у затемнённых, поэтому полагаться чисто на ошибку наверное не стоит.
Можно теоретически прикинуть значение [0][0] у картинки полностью залитой средней яркостью (32) в квадрате 64х64 - сначала складываем 64 яркости 32 и затем делим на 8 (корень из 64), что даёт 256, затем проходимся в перпендикулярном направлении - в этом случае складываем 64 отсчёта по 256 и снова делим на 8, что даёт 2048 - вот это и есть теоретическая величина отсчёта спектра [0][0] для средне-серого изображения (что вполне соотносится с наблюдениями изложенными выше). Для ярко-белой заливки (63 это максимум) таким же способом получается 4032, а для совсем чёрного (0) очевидно получится 0.
Если мы считаем двухмерного Уолша не в 64х64, а в 16х16, то там цифры будут 512 для средне-серого изображения (в 4 раза меньше, чем в 64х64) и 1008 для ярко-белой заливки (опять же в 4 раза меньше, чем для 64х64) - соответственно если мы будем делать "прогрессивное" восстановление картинки, двигаясь от низких разрешений к высоким, пропуская нечётные степени двойки, то надо будет корректировать отсчёты от предыдущего разрешения умножая их на 4.
P.S. Так как в текущем формате WHT под сохранение отсчёта [0][0] отведено 16 бит, то теоретический предел по размерам получается 1024x1024, которое даст 64512 в [0][0] для ярко-белой картинки. По-идее, если картинка тёмная, то можно и 2048х2048 попробовать сохранять (так то оно хранит log2N в 4 битах, т.е. вплоть до 15, но со стороной 2^15 у нас не полетит 100%). | | | | |
В версии 2 формата WHI (первые 2 байта таких файлов будут содержать W2) надо будет поднять битность нулевого отсчёта до 18, чтобы сохранять размеры до 4096x4096, плюс знак, чтобы можно было сохранять цветоразностные поля (там будут отрицательные значения наряду с положительными). Ну или сразу 20 со знаком (что даст 8192x8192 для 6-битных изображений или 2048x2048 для 8-битных), причём битность "выскочек" надо будет тоже поднять т.к. сейчас оно кодируется 4 битами, т.е. от 0 до 15, можно конечно использовать 0 заместо 16, но в версии 2 наверное надо использовать сдвинутые значения - скажем сдвинутые на 8: Ну или даже можно нулевой отсчёт записать в "выскочки" и тогда фиксированной битности вообще не будет использоваться нигде...
|
06 Dec 2023 04:44 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23398 Location: Silicon Valley
|
| | | | Shaos wrote: Таки будет у меня комментарий Но только когда WHI файлы первой версии (сигнатура W1), которые кодируют один квадрат, будут склеиваться вместе (можно через COPY /B это делать) и комментарий, идущий после сигнатуры W0, будет нужен для указания что с этими квадратами делать, например текст "320x200" будет означать что далее идущую цепочку квадратов надо выложить как чёрно-белую картинку в экран 320x200 слева-направо сверху-вниз, а скажем "RGB320x200" будет говорить о том, что далее идут квадратики по каналам: R,G,B,R,G,B и т.д. которые также будут заполнять экран 320x200. Анимацию даже можно аналогичным образом задавать указав комментарий "MOVIE" После ключевых слов может идти обычный пользовательский комментарий, если вдруг кто-то что-то захочет внутрь такого комбинированного файла написать и попусту растратить файловое пространство... | | | | |
По идее можно расширить идею - в последовательности квадратов может попадаться секция W0 с комментарием COPYn где n - это порядковый номер уже обработанного квадрата - таким способом уже можно поддержать тайлы (повторяющиеся квадраты по ходу картинки). А в случае MOVIE можно также иметь по ходу дела секции W0 с комментарием SKIP, что значит пропуск квадрата (т.е. на его месте будет просвечивать предыдущее изображение). Для отметки начала следующего кадра можно использовать комментарий FRAME, за которым может идти задержка в мс для отработки стоп-кадра. По сути и квадраты разного размера можно поддержать - например файл может начаться с квадрата 64x64, за которым будут идти 4 квадрата 32x32, что будет означать, что эти 4 меньших квадрата должны составить больший квадрат 64х64 вместо расстановки квадратов в строчку...
|
06 Dec 2023 19:29 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23398 Location: Silicon Valley
|
| | | | Shaos wrote: Приступаю к реализации алгоритма "по верхней планке", чтобы покрыть факторы качества ниже 90 - для начала надо пройтись по самой первой строчке таблицы, чтобы узнать верхние Q для каждой колонки. Далее находим нижние значения, от которых надо начинать плясать вверх - они вычисляются элементарно - минимально разумная точка это число, которое можно представить указанным количеством бит без квантования (это я уже умею вычислять - см.выше) либо самое нижнее возможное (у меня количество отчётов "выскочек" ограничено 99, поэтому если там в 99-й позиции уже стоит число, которое невозможно представить без искажений данным количеством бит, то танцуем от этого самого числа вверх). Далее бинарным поиском находим точку "по верхней планке" для Q=99 в каждой колонке и далее скачем вверх (опять же бинарным поиском), чтобы найти следующее Q не равное 99 - в таблице для FEMALER приведённой выше за 99 идёт 69 потом 49 потом 36 потом 28 и т.д. По этим цепочкам чисел выбираем самое ближайшее сверху для задаваемого пользователем значения Q (например если пользователь указал Q=50, то выбираем Q=69) и считаем по уже отработанному алгоритму, отбрасывая лишние единички для подгонки Q и перебирая все способы сжатия и все способы обхода матрицы для каждой из колонок (заранее отбросив все колонки, в которых не попадается выбранное значение Q, чтобы не тратить на них вычислительное время), выбирая лучший вариант в колонке и далее выбираем самое лучшее сжатие среди лучших по колонкам... | | | | |
Фуф - вроде накодил универсальный адаптивный алагоритм как хотел FEMALER.BWS Q=80 FEMALER.BWS Q=50 FEMAILER.BWS Q=25 P.S. Алгоритм "по верхней планке" полностью игнорирует ошибку при сравнении результата и оригинала просто беря самое сильное сжатие с указанным количеством ненулевых отсчётов, что даёт не самую лучшую картинку на выходе - тут как бы надо выбирать, либо картинка получше, либо сжатие посильнее и пока я выбираю сжатие...
You do not have the required permissions to view the files attached to this post.
|
07 Dec 2023 01:05 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23398 Location: Silicon Valley
|
Выложил Walsh Explorer v1.0.5 на гитлаб: https://gitlab.com/shaos/graphin/-/tree/main/WALSHEXPТакже приаттачил новый ZIP-архив в первое сообщение этого топикаОсновная фича версии 1.0.5 это адаптивный алгоритм создания WHI-файлов: он просит задать качество от 1 до 99: и имя файла: после этого будет сгенерён оптимальный WHI-файл: Новая оценка трудозатрат: | | | | Code: Total Physical Source Lines of Code (SLOC) = 4,146 Development Effort Estimate, Person-Years (Person-Months) = 0.89 (10.68) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05)) Schedule Estimate, Years (Months) = 0.51 (6.15) (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Estimated Average Number of Developers (Effort/Schedule) = 1.74 Total Estimated Cost to Develop = $ 120,269 (average salary = $56,286/year, overhead = 2.40). SLOCCount, Copyright (C) 2001-2004 David A. Wheeler SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL. SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to redistribute it under certain conditions as specified by the GNU GPL license; see the documentation for details. Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."
| | | | |
по сравнению с предыдущей оценкой от 11 ноября добавилось 3 с лишним человеко-месяца работы в итоге стоимость разработки возросла с $83K до $120K P.S. По состоянию на 1996 год там было 3,187 строк, т.е. я тысячу строк примерно добавил за последний месяц...
You do not have the required permissions to view the files attached to this post.
|
08 Dec 2023 00:22 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23398 Location: Silicon Valley
|
Ещё раз сравниваю ELAINE сжатую адаптивным WHI-алгоритмом с JPEG (беру близкие по размеру файлы WHI и пишу с каким Q они были сделаны): Субъективно WHI для этой картинки в градациях серого выглядит немного лучше, чем JPEG с похожей степенью сжатия по-моему P.S. Приаттачиваю архив с файлами картинок ELAINE в форматах PNG,BWS,WHI и JPG, если кто хочет сам проверить...
You do not have the required permissions to view the files attached to this post.
|
09 Dec 2023 01:14 |
|
Who is online |
Users browsing this forum: Claude AI [Bot] and 0 guests |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
|
|