Как я делал сборку WebP ConvertBAT, но в процессе что-то пошло не так, однако меня это не остановило

Однажды оптимизируя старые скриншоты был выбран формат изображений WebP, и такой выбор был сделан не спроста.

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

Ведь скомпилированные инструменты работают даже в Ubuntu 13.04, любители устраивать ад зависимостей, смотрите и учитесь:

А то наделают всякого, что даже через неистовые танцы с бубном ничего не работает... Но сейчас "линуксы" подождут, ибо сборка будет разрабатываться для Windows:

Ну а потом уже можно и про "линуксы" подумать, найти бы ещё пригодный для нормального использования дистрибутив, чтобы было ради чего делать сборку...

Значит так, прежде всего нужно разобраться в возможностях:

Ну что, время читать мануалы? И да, и нет, ибо документация здесь поверхностная, похоже нужно через командную строку вызывать справку для каждого инструмента и смотреть, что из инструментов будет полезно, а что нет.

Вот так гораздо интереснее:

Прежде всего нужно подготовить разделы реестра, так как инструменты предназначены для работы с изображениями, значит и работать они должны только с файлами изображений, вот так контекстное меню будет появляться только при выделении PNG и JPEG файлов:

Для расширения возможностей команды будут направляться в отдельные BAT файлы:

Однако есть небольшая проблема, чистая Windows 7 даже понятия не имеет про WebP формат, соответственно нет и раздела в реестре про данный формат файла, думаю неплохо будет позаботиться об этом нюансе...

Добавляем несколько разделов в реестр и теперь система знает про расширение файлов ".webp", правда иконка файла не изменилась, но это уже после перезагрузки всё появится:

Однако всплыла проблема, WebP инструменты версии 1.3.1 не работают в Windows 7 без SP1, даже если полноценно установить кодеки, ещё меня позабавил вопрос в сообщении с ошибкой "are you running Windows XP SP3 or newer?", не припомню чтобы существовала 64 разрядная Windows XP SP3, это так странно...

А ведь в Windows 7 SP1 всё нормально работает даже без установки кодеков.

В общем получился небольшой файл реестра добавляющий расширение webp в систему, но его не буду оставлять в сборке, в нём просто нет никакой нужды по итогу, чисто как опыт сойдёт:

Идём дальше, появились команды в контекстное меню, не сами конечно появились, но примерно с этого момента начались проблемы...

Контекстное меню отлично работает, однако если попытаться открыть изображение через стандартный просмотрщик изображений Windows, то выбивает ошибку "Этому файлу не сопоставлена программа...", если удалить созданные в реестре разделы то всё приходит в норму:

Заметили что верхний скриншот уже сделан в Windows 7? А всё потому что Windows 10 теперь невозможно нормально использовать.

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

В общем Windows 10 начала тормозить, меня даже пытался напугать синий экран с ошибкой "DRIVER_VERIFIER_DETECTED_VIOLATION", очень интересно!

На всякий случай решил проверить основной накопитель на котором установлена система, и тут Crystal Disk Mark показал очень печальные результаты. Конечно, ~6 МБ в секунду при чтении/записи в режиме случайного доступа достаточно хорошая скорость, если бы это был обычный HDD, а не полноценный NVMe SSD Samsung 970 PRO 512GB с MLC NAND и DRAM кэшем...

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

Ну и копирование файлов происходит медленно, на перезагрузку система тоже очень долго уходит, собственно почему я и решил протестировать SSD ... Несколько раз протестировал SSD в настройках BIOS, но все тесты говорят "пройдено":

Ладно, может это действительно только Windows 10 поломалась каким-то чудом? Я загрузил Windows 7, и она, как всегда, работает хорошо.

Запускаю тест диска, скорости ~3.5 ГБ в секунду при линейном чтении и 55/600 МБ в секунду при случайном доступе, однако скорость записи явно ниже чем должна быть, даже в линейном режиме:

Как должно быть? Ну примерно вот так:

Загрузил ещё Wubuntu, но "линуксы" такие "линуксы"... Утилиты для работы с диском в данном дистрибутиве не умеют тестировать скорость, даже Gparted кастрированный в этом дистрибутиве, бррр, но выход был найден, просто запустил подсчет файлов на диске, но на глаз точно определить что-то невозможно в данном случае.

Кто-то возразит что в "линуксах" и не должно быть бенчмарков для диска! И вообще, в Windows тоже нет встроенного теста скорости для дисков! Но кто сказал что "линуксы" должны быть похожи на Windows? Почему "линуксы" не могут быть лучше той самой Windows? Особенно экземпляры, разработчики которых прямо заявляют, что их "линукс" лучше "винды"...

Метаясь между разными операционными системами вспомнилось что нужно бы проверить SMART диска, но там всё прекрасно, а потом скачал KDiskMark для Linux, это аналог Crystal Disk Mark, скомпилированную версию запустить не получилось, увы, это типичный ад зависимостей в "линуксах". В итоге использовал запасной вариант в виде AppImage, всяко лучше, чем ничего:

У меня диск разбит на три основных раздела, первый 120 ГБ для Windows 7, второй 160 ГБ для Windows 10, третий примерно на 196 ГБ для "линуксов", по итогу тест в пределах третьего раздела показал неплохие скорости, но далеко не идеальные, второй раздел уже явно просел по скорости едва дотягивая до 2 ГБ в секунду при линейном чтении, а первый раздел и вовсе не дотянул даже до 1.5 ГБ в секунду, ну и со скоростью записи всё не очень хорошо, неужели виновата файловая система NTFS?

В общем вернулся снова в Windows 7, в режиме случайного доступа скорость чтения немного увеличилась, в остальном без особых изменений.

Осталось только проверить SSD с помощью утилиты Victoria, и тут получилась забавная картина, первые ~10 ГБ читались на скорости около 1350 МБ/с, после скорость поднялась до нормальных ~2.8 ГБ/с, однако в зоне 250 - 320 ГБ скорость явно проседала, как раз именно в этой зоне установлена Windows 10...

Примерно с 320 ГБ начинается достаточно приятный график чтения, эта зона отведена под "линуксы", и обычно не используется:

В целом не совсем понятно что же именно случилось, то ли Windows 10 поломалась, то ли SSD деградировал, но в любом случае это очень неприятная ситуация. У меня нет иного выбора как продолжать работу над сборкой уже в среде Windows 7, ибо в отличие от Windows 10, она прекрасно работает даже на очень медленных по современным меркам жёстких дисках...

К концу дня было решено собрать графики с остальных SSD, Apacer AS340 (для виртуальных машин) показал очень неприятный график скорости, ибо есть даже сектор с временем доступа 1.6 секунды.

На PNY CS900 у меня игры GOG/Steam, Genshin и т.п., график скорости тоже очень рваный, но обошлось без "уставших" ячеек памяти.

Apacer AS350 показал равномерный график в отличие от первых двух SSD, видимо у него таки работают технологии выравнивания износа:

Ради полноты картины ещё раз протестировал Samsung 970 PRO, и о чудо, график изменился! За три часа работы под управлением Windows 7 в зоне первых ~10 ГБ объёма скорость поднялась с ~1350 до нормальных 2200-2800 МБ/с, а пики в середине объёма вообще исчезли:

Однако для Windows 10 ничего не изменилось, и скорее всего всё поломалось до начала работы над сборкой WebP ConvertBAT, ведь система не перезагружалась почти месяц, а за это время она имела дело с очень проблемным USB накопителем, он даже загадил журнал тысячами сообщений об ошибке (проблемы с контролёром), да и VirtualBox там гадит время от времени:

Фанатики Linux жаловались что я не показываю как ломается Windows, вот у них радости будут полные штаны, наконец настал момент когда поломалась "шинда"! Это действительно редкое явление, ведь за время жизни многострадальной Windows 10 у меня успело поломаться как минимум 3 дистрибутива Linux, причём поломаться гораздо сильнее чем это сделала Windows 10... Ведь Windows 10 всё ещё можно использовать, хоть и с тормозами, а "линуксы" ломались до состояния "невозможно использовать".

Впрочем, теперь я могу нормально играть в игры без лишних задержек вывода по вине композитора, ибо Windows 7 позволяет отключить композитор в отличие от всяких Windows 10/11... Каждый раз чувствую облегчение получая в играх быстрый отклик от управления возвращаясь в Windows 7 после Windows 10:

Ну да ладно, пора бы продолжить работу над сборкой...

Нужно решить проблему "этому файлу не сопоставлена программа":

Сократив имена разделов проблема не решилась, значит дело не в этом:

В ходе экспериментов было выяснено, что во всём виновата "позиция"! Может звучит странно, но без этого свойства никаких проблем нет...

Вообще раньше я ведь делал сборки Waifu2X и RealESRGAN, собственно вот они в контекстном меню, но с такими проблемами не сталкивался по той простой причине, что эти разделы меню работают глобально на все файлы, т.е. даже для файла с TXT расширением:

А сейчас идёт работа с конкретными типами файла, и судя по всему не следует использовать свойство "Position". Ведь задавая позицию в меню для конкретного типа файла система начинает открывать файл через тот самый пункт, который выше всех остальных прописан, а у меня получается прописан вложенный раздел контекстного меню, естественно система ругается так как команда для родительского пункта меню не назначена...

Так гораздо лучше, всё работает без проблем и меню появляется только при работе с подходящими файлами, теперь можно дальше наполнять разделы:

Конечно же нужно всё тестировать, а то вдруг где-то ошибка закралась, или работает не так как надо, но сейчас всё работает как надо:

Прикручиваю команду для просмотра WebP файлов, это может быть полезно если в системе не установлены кодеки:

После были добавлены команды для конвертирования изображений в webp формат, однако может произойти неприятная ситуация, да, меню просто может не появиться при выборе jpg изображения (или любого другого), хотя в реестре всё правильно прописано:

И такая ситуация может произойти у любого пользователя, но как такое возможно? Просто в реестре есть "HKEY_CLASSES_ROOT", обычно всё именно в этом разделе и происходит, но порой нужно зайти немного глубже, прямо в "SystemFileAssociations", и туда уже добавить нужные записи:

Теперь наверняка всё работает как положено:

Но что произойдёт если использовать оба варианта? Да в принципе ничего плохого, просто немного больше записей в реестре будет, но их можно легко убрать из реестра просто использовав файл реестра предназначенный для удаления, умеющий читать сразу поймёт для чего предназначены файлы:

Так как инструменты умеют конвертировать GIF анимации, то почему бы не сделать и этот функционал легкодоступным? Раз функционал полезен, значит нужно его реализовать, и это вполне отлично получилось, в том числе возможность разложить анимированный WebP файл на отдельные кадры:

Собственно пора проверить функционал, WebP Codec для Windows не умеет работать с анимированными файлами, но я позаботился о том, чтобы даже такие файлы всегда можно было открыть:

А ещё позаботился чтобы можно было разложить анимацию на отдельные кадры:

Само собой GIF файлы можно прямо из контекстного меню конвертировать в анимированный WebP:

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

Но всё же было бы хорошо, если бы люди таки читали справку прежде чем использовать сборку, ведь у меня ещё нет полноценного установочного пакета, и по этой причине сборка должна быть расположена в папке "_PORTABLE_" на системном диске:

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

Теперь можно проверить сборку в виртуальной машине с Windows 7, для начала проверяю способна ли система вообще открыть GIF файл, и с этим проблем никаких:

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

Контекстное меню появилось как положено, но есть проблема, утилита для просмотра WebP зависит от OpenGL, а в виртуальной машине нет адекватного драйвера видеокарты, потому оно рисует процессором построчно и крайне медленно:

Но не беда, ведь есть скомпилированные Mesa библиотеки, достаточно подкинуть OpenGL32 файл в папку к инструментам и всё прекрасно работает в полную скорость, даже процессор не нагружается толком, одной проблемой меньше:

Думаю Mesa библиотеку следует оставить в сборке как драйвер OpenGL по умолчанию, так или иначе не замечено ощутимой нагрузки на ядра процессора при работе через Mesa драйвер, при этом устраняется зависимость от драйвера видеокарты.

Единственное я позабыл про инструмент cwebp, он же не работает если у Windows 7 нет SP1... Может заменить его на что-то более старое... Хотя разработчики WebP уже позаботились об этом и выпустили вариант инструментов "no-wic", то что нужно!

Теперь всё работает даже в Windows 7 без SP1:

Даже удалив WebP Codec из системы сборка работает, ведь она не пересекается с кодеками, но всё же стоит заметить, инструмент просмотра WebP файлов в сборке не является полноценным просмотрщиком изображений, он не очень удобен для быстрого и полноценного просмотра множества изображений...

В целом пора бы заканчивать с этим, убрал всё лишнее из папки, уменьшил размер GIF изображения чтобы меньше занимало места на диске, тут же можно заметить разницу между оригинальным GIF, и конвертированным в анимированный WebP:

Исправил ещё одну незначительную ошибку в BAT файле, и ради интереса посмотрим на разницу качества между оригинальным GIF, и конвертированными WebP вариантами, возьмём 55 кадр в качестве основного для сравнения:

Полагаю этот скриншот ничего не говорит о качестве изображения...

Потому просто загружу образцы в PNG формате "как есть", оригинал и WebP Default показывают практически одинаковый уровень качества, "WebP Quality 80" уже не соответствует оригиналу, однако без приближения достаточно сложно заметить разницу:

GIF Original (3872 КиБ)

WebP Default (2682 КиБ)

WebP Quality 80 (1658 КиБ)

Вариант с качеством 70 всё ещё не сильно искажен, но при качестве 50 искажения стали гораздо более выраженными, а при качестве 25 потери очевидны даже без сравнения с оригиналом:

WebP Quality 70 (1157 КиБ)

WebP Quality 50 (816 КиБ)

WebP Quality 25 (504 КиБ)

Перейдём к детальному сравнению, без приближения ничего интересного, даже не буду загружать в статью столь массивный скриншот:

Но если увеличить все изображения и напрямую сравнить, то очевидно даже некоторое увеличение качества при сжатии "WebP Quality 80", как такое может быть? Ведь это сжатие с потерями... Всё просто, те самые артефакты сжатия как раз и добавляют детализацию, в том числе сглаживая резкие градиентные переходы цветов, потому и кажется что качество даже увеличилось после сжатия:

Так можно улучшать GIF анимации и одновременно экономить место, ведь сжатое с качеством 80 весит более чем в 2 раза меньше оригинала, а на глаз во время воспроизведения даже WebP Quality 70 выглядит хорошо...

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

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

-

--

---

Финальные тесты и GitHub

ReadMe файл оформлен на двух языках:

Нужно бы ещё раз проверить чтобы всё работало как надо прежде чем загружать сборку в репозиторий, потому устанавливаю чистую Windows 7 в виртуальную машину:

Само собой система спросила разрешение на внесение изменений в реестр, сейчас не буду отключить эти уведомления, ведь нужно просто проверить работоспособность сборки:

С анимированными WebP всё отлично, прекрасно работает даже без драйвера на видеокарту и при этом не создаёт значительной нагрузки на ЦП:

С остальным функционалом тоже полный порядок:

С файлом удаления ключей реестра тоже в принципе всё сработало отлично, правда я забыл добавить минус к каждому ключу реестра, и он вместо удаления наоборот добавлял в реестр уже существующие разделы, но нюанс исправлен и теперь всё работает как положено, сборка действительно готова для использования и загрузки в репозиторий:

Теперь нужно решить какой архив загружать... А хотя пусть будут оба!

Вот так, а над оформлением поработаю чуть позже:

Ссылка на репозиторий: ( https://github.com/Shedou/WebP-ConvertBAT ).

Не знаю, будет ли эта сборка полезна другим людям, но мне она точно будет полезна, например оптимизировать фотографии, да, EXIF метаданные теряются, это неприятно, но тут уже выбирать между метаданными и размером:

Сравнение качества между оригиналом и WebP Quality 90:

-

--

---

Заключение

Вот так и завершена работа над первой версией сборки WebP ConvertBAT (Windows).

Казалось бы, что такого забросить команды в реестр и пользоваться? Собственно вы сами видели, если конечно читали статью.

Хоть на радость фанатикам Linux у меня и поломалась Windows 10 во время работы, хотя это и не по вине работы с реестром произошло, но как раз чтобы у конечных пользователей такого дерьма не происходило разработчики обязаны сделать своё приложение пригодным для нормального использования, а не оставлять исходный код и пусть все танцуют с кривыми зависимостями хоть до поседения, как это часто любят делать в "линуксах".

И разработчики WebP всё сделали правильно, они сделали формат с открытым исходным кодом, но при этом не забыли и про пользователей с другими разработчиками. Зачастую гораздо удобнее работать с уже скомпилированными исполняемыми файлами, а не исходным кодом который ещё догадайся как собрать, чтобы ничего не навернулось мухоморами.

Теперь можно думать над сборкой для тех самых "линуксов", даже боюсь представить как для зоопарка дистрибутивов сделать универсальное решение, ведь контекстное меню зависит от окружения рабочего стола... Да ещё умудриться чтобы не уступало реализации для Windows...

Благодарю за внимание, больше интересных статей в блоге Hard-Workshop.

Курлык!