Картинка сохраняется в формате, который ближе всего видеокартам — в виде растрового изображения, но из неё восстанавливается растровый контур любого разрешения без потерь качества. Если совсем свысока взглянуть на любой векторный формат — это математическое описание изображения, по которому можно восстановить растр с любым требуемым разрешением. А кто сказал, что матрица интенсивностей, положенная в основу метода — не математическое описание?:) К сложившемуся термину «вектор» как набору кривых это конечно не имеет отношения.
Фейсбуковцы уже на стену лезут от этой моды на фоточки и селфи.
Я сначала не понял, в чём суть — существует (и довольно давно) jpegtran, который весьма неплохо оптимизирует жпеги. А выяснилось, что оно внутри и есть jpegtran, но с улучшенной степенью сжатия:)
Да собственно я давно нашёл решение для себя, оно попроще:) Смысл в том, что многие современные IDE умеют по хоткею запустить внешнюю программу. Она принимает stdin и выплевывает stdout, и не нужно убивать выходной на простой парсер. Даже плагин писать не нужно.
Delphi
Меня терзают смутные сомнения насчет кроссплатформенности — как там с Linux и Mac?
Для таких товарищей пишутся Coding Style Guide-ы, непокорных просто не пускают на сервер до тех пор пока не исправят код. В Гугле ещё веселее — перед пушем ваш код сканирует валидатор, если он ему не нравится — придётся переделывать.
Он не может не учитывать, когда накладывается патч. А при простом сравнении глазами можно и выкинуть (см. выше). Проблема, конечно, есть, но никто ещё не умер.
В некоторых style-guide-ах можно наоборот встретить подобное требование, в частности, align-declarations. Из известных примеров — GNOME, где выравнивают даже аргументы функций. Кроме того, это помогает в редакторах с поддержкой длинного (на несколько строк) курсора. Скажем, прототип функции поменялся, и нужно в 10 строк добавить по одному одинаковому аргументу. Проблему вижу только при миграции (методом копипасты) кода из проекта с одним стилем кодирования в другой.
А есть ли возможность PIPE-интерфейса? Я например не пользуюсь саблаймом, но в Geany можно любой кусок кода отправить внешней программе на обработку и ваш плагин можно будет прикрутить в два счёта при условии наличия интерфейса командной строки.
Не замечал чтобы актуальный IM что-то плохо рендерил, но чтобы не пользоваться браузером всё равно полно вариантов, самый легковесный — это CairoSVG (на Питоне). Я просто слабо представляю как такое решение будет интегрироваться со сборочным сервером, например, где графики обычно нет.
> мне самому аналог обычного jpeg'а писать придётся и делать деление на этапы
Я предлагаю сделать проще. НЧ составляющую закодировать алгоритмом жпега, положим получится 6 килобайт картинка жпег. Далее сделать grain extract (А-В+0.5) для оригинала и пожатого жпега, получим вот такую картинку:
Это была ваша птица из примера, которую я сначала сжал в жпег 6 кб, а затем применил grain extract с оригиналом. Это и будет та самая ВЧ составляющая, то есть «детали», которые хорошо умеет сжимать ваш алгоритм. Видно, что шум тут очень слабый, кодировать его будет проще. Чтобы было заметнее, я увеличу контраст этого шума:
Далее после кодирования данной ВЧ составляющей получаем вторую картинку, положим, она займёт после сжатия вашим методом 10 килобайт. Восстанавливаем оригинал по обратной формуле А+В-0.5, считаем PSNR, чтобы оценить качество сжатия. Итого — ужали исходное изображение в 2 прохода до 16 килобайт. Далее подгоняем жпег до 16 килобайт и также считаем PSNR, после чего сравниваем, что лучше. Потом для пущей эффективности алгоритм можно скрестить с вейвлетами и поиграться с балансом ВЧ-НЧ, я думаю это тоже как-то влиять будет.
Я так понимаю автор комментария всё же имел ввиду сравнение PSNR-метрики для восстановленного изображения данным методом в сравнении с каким-либо другим популярным алгоритмом сжатия для разных входных данных. Если алгоритм покажет хоть какие-то практические результаты, у него есть шанс на жизнь пусть не в вебе, но в каких-то специализированных приложениях или играх, где размер имеет значение, но чёткость текстур тоже играет немаловажную роль.
Скажем так, по своему опыту знаю, что нередко стандартные алгоритмы сжатия не подходят и приходится изобретать. Например, jpeg не поддерживает альфа-канал и бывает выгоднее сохранить два жпега (цвет+альфа), чем жать всю картинку в PNG. Если алгоритм покажет хороший результат, он может стать 1) дополнением для стандартного жпега чтобы кодировать ВЧ часть 2) может быть значительно доработан (дельта кодирование, бинарный формат выхлопа, сжатие LZW). Более того, для приемлемого результата достаточно кодировать только яркость.
Ещё бы алгоритм в более удобоваримой форме на GitHub выложить… На Питоне например. Матлаб всё же специфичная прога, не язык программирования.
Не мешает добавить дельта-кодирование и квантование, будет проще сжимать это каким-нибудь словарным алгоритмом. Любой формат — будь то jpg или png — состоит из обработки сигнала и сжатия deflate (в те времена лучше не знали). Сейчас можно скрестить с более эффективным lzma или bzip2. После этого уже было бы интересно посмотреть на результат.
Но мне кажется природу не обманешь. Если разложить картинку на JPG (7 килобайт) и остатки (шум, оставшийся после сжатия), потом сжать остатки алгоритмом bzip2 — получим исходные 30 килобайт, до которых можно ужать картинку форматом PNG. Сжимать годные остатки каким-то шумом можно, но это всё равно что просто добавить белый шум на изображение — будет создаваться иллюзия отсутствия артефактов сжатия, хотя PSNR упадёт. Такую технику использовали ещё в стародавние времена в играх, как только — чтобы текстуры не казались уж очень размытыми, в них подмешивали более мелкую текстуру шума:
Скрытый текст
Самое логичное что приходит на ум — сжимать таким методом «годные остатки», но есть предчувствие, что качество от этого не сильно увеличится.
Насколько я знаю, такой плагин существует, но он на момент когда я его щупал был в глубокой бете и работал через раз. Впрочем, скачать .blend-файл и импортировать из него необходимый материал совершенно не сложно.
Фейсбуковцы уже на стену лезут от этой моды на фоточки и селфи.
Я сначала не понял, в чём суть — существует (и довольно давно) jpegtran, который весьма неплохо оптимизирует жпеги. А выяснилось, что оно внутри и есть jpegtran, но с улучшенной степенью сжатия:)
Меня терзают смутные сомнения насчет кроссплатформенности — как там с Linux и Mac?
?
Смысл в том, что в отличие от «красивостей» в примерах, в некоторых проектах (GNOME) принято писать как в моем примере.
А
лентяидвигатели прогресса в свою очередь пилят AStyle.Тоже делал такую штуку, но выравнивает лишь переменные: github.com/scriptum/geany-scripts/blob/master/align-declarations.py
mogrify -density 300 -format png *.swgИ дело в шляпе. density по вкусу (в DPI).
P.S. + Makefile как уже писали выше, чтобы переконвертировались только изменившиеся картинки.
Прямо неуловимый Джо
Так можно подборку из 100500 малоизвестных команд сделать. Нужно писать про те, которые есть в LSB (и следовательно в каждом дистрибутиве) хотя бы.
Я предлагаю сделать проще. НЧ составляющую закодировать алгоритмом жпега, положим получится 6 килобайт картинка жпег. Далее сделать grain extract (А-В+0.5) для оригинала и пожатого жпега, получим вот такую картинку:
Это была ваша птица из примера, которую я сначала сжал в жпег 6 кб, а затем применил grain extract с оригиналом. Это и будет та самая ВЧ составляющая, то есть «детали», которые хорошо умеет сжимать ваш алгоритм. Видно, что шум тут очень слабый, кодировать его будет проще. Чтобы было заметнее, я увеличу контраст этого шума:
Далее после кодирования данной ВЧ составляющей получаем вторую картинку, положим, она займёт после сжатия вашим методом 10 килобайт. Восстанавливаем оригинал по обратной формуле А+В-0.5, считаем PSNR, чтобы оценить качество сжатия. Итого — ужали исходное изображение в 2 прохода до 16 килобайт. Далее подгоняем жпег до 16 килобайт и также считаем PSNR, после чего сравниваем, что лучше. Потом для пущей эффективности алгоритм можно скрестить с вейвлетами и поиграться с балансом ВЧ-НЧ, я думаю это тоже как-то влиять будет.
Скажем так, по своему опыту знаю, что нередко стандартные алгоритмы сжатия не подходят и приходится изобретать. Например, jpeg не поддерживает альфа-канал и бывает выгоднее сохранить два жпега (цвет+альфа), чем жать всю картинку в PNG. Если алгоритм покажет хороший результат, он может стать 1) дополнением для стандартного жпега чтобы кодировать ВЧ часть 2) может быть значительно доработан (дельта кодирование, бинарный формат выхлопа, сжатие LZW). Более того, для приемлемого результата достаточно кодировать только яркость.
Ещё бы алгоритм в более удобоваримой форме на GitHub выложить… На Питоне например. Матлаб всё же специфичная прога, не язык программирования.
Но мне кажется природу не обманешь. Если разложить картинку на JPG (7 килобайт) и остатки (шум, оставшийся после сжатия), потом сжать остатки алгоритмом bzip2 — получим исходные 30 килобайт, до которых можно ужать картинку форматом PNG. Сжимать годные остатки каким-то шумом можно, но это всё равно что просто добавить белый шум на изображение — будет создаваться иллюзия отсутствия артефактов сжатия, хотя PSNR упадёт. Такую технику использовали ещё в стародавние времена в играх, как только — чтобы текстуры не казались уж очень размытыми, в них подмешивали более мелкую текстуру шума:
Самое логичное что приходит на ум — сжимать таким методом «годные остатки», но есть предчувствие, что качество от этого не сильно увеличится.