The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Новая версия программы для очистки SVG файлов - svgcleaner 0.7.0

10.10.2016 02:29

Доступен новый выпуск программы svgcleaner, предназначенной для пакетной очистки SVG-файлов от ненужной информации. Чистка осуществляется без потерь для видимого изображения. По сути программа делает две вещи: удаляет элементы и атрибуты, не участвующие в конечном изображении, и приводит задействованные элементы и атрибуты к более компактному виду. В итоге, результирующий размер файла может быть уменьшен на 40-60%.

Код программы написан на Rust и распространяется под лицензией GPLv2. Для управления процессом очистки отдельно подготовлен графический интерфейс на Qt. Готовые сборки доступны для Linux x86_64 (portable-архив), Windows и macOS.

Основные изменения:

  • Консольная версия переписана с C++ на Rust.
  • Реализованы собственные библиотеки для разбора SVG и представления SVG в виде DOM.
  • Существенное увеличение производительности (до трёх раз быстрее).
  • Все функции очистки теперь работают в режиме без потерь качества (lossless).
  • Степень очистки снижена на ~5%, ценой стабильности и корректности;
  • Добавлена документация для каждой опции очистки.
  • GUI переписан с нуля и вынесен в отдельный репозиторий.


  1. Главная ссылка к новости (https://github.com/RazrFalcon/...)
  2. OpenNews: Вышла новая версия программы для очистки SVG файлов - SVG Cleaner 0.6
Автор новости: RazrFalcon
Тип: Программы
Ключевые слова: svg
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (59) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, iPony (?), 08:44, 10/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Какой-то велосипед.
    Время с точностью до 0.00001 секунды - это круто
     
     
  • 2.2, pkdr (ok), 08:57, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +5 +/
    С каких это пор для компьютеров интервалы времени в 0.01 миллисекунду стали чем-то мелким и не заслуживающим измерения? Даже в начале 90-х время работы процессов всегда мерялось в долях миллисекунды, а иногда и в микросекундах.
     
     
  • 3.40, soarin (ok), 17:36, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Ты метрологическую проверку сделал, что автор программы измеряет что надо?
    Пользователю это не надо, и QElapsedTimer не даёт гарантированную точность на полных разрядах своего типа данных.
    К чему твоё высказывание?
     
     
  • 4.52, Аноним (-), 21:25, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Может всё-таки "поверка"?
    Пора бы уже заметить и усвоить эту разницу в одну букву.
     
  • 3.41, Аноним (-), 17:52, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    У обычных писюков 10 микросекунд могут работать а могут и нет. Это как минимум требует таймер высокого разрешения (>=100 kHz).
     
  • 3.60, Онаним (?), 05:10, 11/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А какая вообще разница сколько там миллисекунд затрачено на очистку этого файла, особенно если ты делаешь это вручную через GUI?
     
  • 2.3, RazrFalcon (ok), 09:20, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Ну так среднее время очистки в районе 10мс. В чем тогда мерять?
     
     
  • 3.4, Crazy Alex (ok), 09:41, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Вот в миллисекундах и мерять. Там флуктуации доступа к диску или особенности шедулера больше повлияют, чем эти доли.
     
     
  • 4.14, RazrFalcon (ok), 11:31, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Можно и без дробной части, да. Это не принципиально. Просто есть файлы которые обрабатываются меньше чем за 1мс.
     
  • 3.24, Аноним (-), 13:02, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А зачем вообще мерить?
     
     
  • 4.34, RazrFalcon (ok), 15:07, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Это философский вопрос. Особой нужды нет.
     
     
  • 5.44, Аноним (-), 18:53, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Это философский вопрос. Особой нужды нет.

    Ответ на него давно дал Кнут, сказавший что преждевременная оптимизация - корень всех зол.

     
     
  • 6.54, Ordu (ok), 22:55, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да, совершенно верно. И поэтому автор svgcleaner пишет на опеннете новости о своей программе, а Аноним перечитавший Кнута изображает иксперда в комментах к этой новости.

    Во-первых, не надо путать оптимизацию, и диагностику производительности.

    Во-вторых, дай себе труд повтыкать вот сюда: https://gist.github.com/hellerbarde/2843375

    Ты видишь, что среди разных рассмотренных временных отрезков младшие пять _порядков_ на глаз неразличимы? То есть, при определённых условиях, можно, совершив какую-нибудь глупость, сделать свою программу раз в сто тормознее и даже не заметить этого. Двадцать лет назад, и тем более до этого, такой проблемы не было, потому что "программа в сто раз медленнее" -- это было практически наверняка заметно глазом. Сегодня программист накручивает одну сложность на другую сложность, на третью, на десятую, программа начинает выполняться уже не "моментально", а всего лишь "в мгновение ока". Программу отправляют на "боевую задачу", где объёмы выполняемой работы на пару порядков больше, и выясняется что программа говно. И оптимизировать её уже невозможно, потому что там накрученных сложностей и алгоритмических глупостей больше, чем собственно кода.

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

     
  • 6.55, RazrFalcon (ok), 01:27, 11/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Чем она преждевременная? Прога зарелизена уже. Оптимизируй - не хочу.
     
  • 4.42, Аноним (-), 17:53, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Для оптимизации процесса. Для опеннетчиков же это философские вопросы и поводы покудахтать.
     

  • 1.6, ГеккоШтат (?), 09:55, 10/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Допустим:
    1.есть 10 тыс файлов.
    2.Их надо пройти этим софтом.
    Зная среднее время можно хоть примерно сказать сколько времени необходимо на все 10 тыс.
    Не?
     
     
  • 2.36, еуьф (?), 15:10, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    неа. файлы могут быть сильно разными, не угадаешь.
     
     
  • 3.50, alltiptop (ok), 20:15, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Можно смотреть по общему объёму, там основная работа идёт построчная.
     
     
  • 4.56, RazrFalcon (ok), 01:29, 11/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >>основная работа идёт построчная

    Никакой работы со строками тут нет.

     
     
  • 5.61, alltiptop (ok), 08:49, 11/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >>>основная работа идёт построчная
    > Никакой работы со строками тут нет.

    А как он тогда работает с xml(svg)?

     
     
  • 6.62, RazrFalcon (ok), 08:58, 11/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Посредством генерации DOM.
     
     
  • 7.66, Mail (?), 14:46, 11/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А домик из воздуха строят. Ну-ну.
     
     
  • 8.69, Аноним (-), 11:39, 14/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Файл может читаться блочно, а не построчно ... текст свёрнут, показать
     

  • 1.8, Аноним (-), 10:20, 10/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    О, для Rust уже есть Qt-биндинг.

    >Консольная версия переписана с C++ на Rust.

    Ну это поспешили, в GCC ещё нет фронтенда для Rust.

     
     
  • 2.15, RazrFalcon (ok), 11:32, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Нет. GUI на С++.

    >>в GCC ещё нет фронтенда для Rust.

    И это прекрасно.

     
     
  • 3.22, Аноним (-), 11:57, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А что, биндинг для Rust на Qt не написал?
     
  • 3.45, Аноним (-), 18:55, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > И это прекрасно.

    Хороший повод не пользоваться такими программами, чтобы когда мозилла околеет - не пойти на дно вместе с их стремной экосистемой и такими аффтарами.

     
     
  • 4.65, Аноним (-), 11:20, 11/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> И это прекрасно.
    > Хороший повод не пользоваться такими программами, чтобы когда мозилла околеет - не
    > пойти на дно вместе с их стремной экосистемой и такими аффтарами.

    Можно подумать, анонима заставляют платить за пользование программой -- и таким образом хотят развести на бабло. А компилятор с экосистемой закрытая проприетарь и сразу сломается.

    Уважаемый форточник (или маковод), вы кое-что путаете -- это совсем не то, к чему вы так привыкли!

     

  • 1.9, Kaffeine (?), 11:07, 10/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Хорошая программа, с её помощью в KDE оптимизировали иконки Breeze, размер уменьшился с 28,0 до 9,4 мегабайт.

    Непонятно только, зачем понадобилось переписывать на (гораздо менее популярный и, как уже сказали, ещё отсутствующий в GCC) Rust. Автор хочет сказать, что ускорение в три раза получилось сменой языка, а не модернизацией алгоритма? Прошу ответить конструктивно. :)

     
     
  • 2.12, Какаянахренразница (ok), 11:18, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Кому (которому из присутствующих здесь анонимов) адресован вопрос?
     
  • 2.16, RazrFalcon (ok), 11:34, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Они использовали svgo, насколько я знаю. И то, у них там от силы половина файлов обработана. svgcleaner позволяет еще в 2 раза сжать.
     
     
  • 3.27, Kaffeine (?), 13:33, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    https://kdeonlinux.wordpress.com/2016/04/25/performance-update-for-breeze-icon
     
     
  • 4.32, RazrFalcon (ok), 14:58, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Тем временем: https://github.com/KDE/breeze-icons/blob/master/optimize-svg.sh
     
  • 3.53, _Vitaly_ (ok), 22:49, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Сжать после SVGO в 2 раза :) ?
     
     
  • 4.57, RazrFalcon (ok), 01:30, 11/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Те иконки, что лежат у них в репе, можно сжать в два раза. Если они и прогоняют их через svgo, то на очень слабых настройках.
     
  • 2.18, RazrFalcon (ok), 11:39, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Увеличение производительности связано исключительно с алгоритмами. Rust даже немного медленнее плюсов.

    Но так как это личный проект - пишу на том, на чём удобно. А это Rust. От плюсов слишком много боли.

     
     
  • 3.68, ваноним (?), 19:12, 12/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    боль лишь у неосиляторов стандарта и у мазохистов с кривыми компиляторами
     
  • 2.23, тоже Аноним (ok), 12:41, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Не знаю, как у автора, а у меня бывало, что переписывание нетривиального алгоритма с C-like оптимизированной версии на обычные STL-контейнеры заметно ускорило алгоритм просто потому, что автор стал лучше понимать, что конкретно происходит в процессе ;)

    Здесь же стоит учесть, что SVG - это, в сущности, XML. Если разбирать (а потом писать) его своим велосипедом на "крестах", может здорово просесть производительность по сравнению со стандартной, оптимизированной по скорости библиотекой высокоуровневого языка. Впрочем, никто не мешает подобрать аналогичную библиотеку и для "крестов"...

     
     
  • 3.31, Гвидо (?), 14:06, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Не знаю, как у автора, а у меня бывало ... что автор стал лучше понимать...

    Как это понимать?

     
     
  • 4.48, тоже Аноним (ok), 19:44, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Может быть, после второго-третьего прочтения?

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

     
     
  • 5.67, Гвидо (?), 20:19, 11/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ты напрасно называешь себя автором алгоритма - у тебя не то что не отросли навыки алгоритмического мышления, но и отсутствует культура написания вменяемого кода.
    Именование переменных, понимание их области видимости - всё это в лучшем случае у тебя впереди.
    Дерзай.
     
  • 2.25, Аноним (-), 13:04, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    многопоточность
     
     
  • 3.26, RazrFalcon (ok), 13:13, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Программа однопоточная. GUI просто запускает несколько копий параллельно. Но увеличение производительности именно в консольной версии, которая однопоточная.
     

  • 1.10, Аноним (-), 11:08, 10/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Столбец Ratio странный. Либо там должно быть отношение размеров стало/было, либо он должен называться «Удалено». Тогда будет понятно. А сейчас не понятно.
     
     
  • 2.11, Drew DeVault (?), 11:11, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    левее 2 столбца «стало» и «было»
     
     
  • 3.13, Аноним (-), 11:31, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Я вижу. Но проценты вычисляются так: (1 - стало/было) * 100. Не совсем Ratio, правда? Это число показывает сколько процентов байт было удалено.
     
  • 2.17, RazrFalcon (ok), 11:37, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Столбец показывает сколько было удалено. С терминологией, возможно, неувязка.
     
     
  • 3.30, Anonymouss (?), 13:42, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    "Size reduction"
     

  • 1.19, Аноним (-), 11:47, 10/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А для видеофайлов такое есть? В информации о файлах, озданных мной, всегда libavcodec 57
     
  • 1.20, Аноним (-), 11:52, 10/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > Степень очистки снижена на ~5%, ценой стабильности и корректности;

    Какой из следующих вариантов означает эта фраза?
    чистить стало хуже, зато стабильнее и корректнее
    чистить стало лучше, зато менее стабильно и корректно
    чистить стало хуже, зато менее стабильно и корректно

     
     
  • 2.21, RazrFalcon (ok), 11:53, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Первый.
     

  • 1.28, Александр (??), 13:37, 10/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "теперь работают в режиме без потерь качества (lossless)" - значит ранее описанную словом линию (векторная графика ведь) изгибали  или уничтожали? Или этот тег писали через букву?
     
     
  • 2.33, RazrFalcon (ok), 15:02, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Суть в том, что раньше программа содержала деструктивные опции, которые удаляли/искажали видимые части изображения. Теперь их нет.
     
     
  • 3.38, Александр (??), 16:01, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ► Спасибо за полезный ответ !
     

  • 1.43, Аноним (-), 18:41, 10/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    cargo build --release --verbose Fresh bitflags v0 7 0 Fresh unic... большой текст свёрнут, показать
     
     
  • 2.46, Аноним (-), 18:57, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Мда. Я думал что у GCC в C++ плохие сообщения об ошибках. Признаю, был неправ!
     
  • 2.58, RazrFalcon (ok), 01:34, 11/10/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Писать багрепорт в https://github.com/kbknapp/clap-rs, ибо это его ошибка. Для начала советую обновить Rust до последней версии. В Readme указано, что нужна последняя стабильная версия.
     

  • 1.47, Аноним (-), 19:28, 10/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Пропустил через svgcleaner файл сделанный в Inkscape.
    Исходный файл: 42мб, имеет много слоёв с векторами и битмапами, многие слои временно выключены.
    Файл на выходе: 10мб, информация о слоях удалена, невидимые элементы удалены.
    Впечатления:
    - gui-версия из Downloads не запускается "...could not find or load the Qt platform plugin "xcb""
    - консольная версия работает
    - считаю, что фраза "losslessly reduce size" из описания программы вводит в заблуждение.
    - эдакий "Flatten Image" for publishing svg-files
     
     
  • 2.49, тоже Аноним (ok), 19:51, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > - считаю, что фраза "losslessly reduce size" из описания программы вводит в заблуждение.

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

    Теряется дополнительная информация - так это и является заявленным функционалом программы! Она и предназначена для постпродакшена, а не для рабочих файлов. Ну, и полей для откровенно ненужной информации в этом формате не предусмотрено ;)

     
  • 2.51, llolik (ok), 20:58, 10/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > - gui-версия из Downloads не запускается "...could not find or load the
    > Qt platform plugin "xcb""

    Это на LOR уже разрешили. Надо пакет libxcb-xinerama0 доставить там, где его нет (на Mint или Федорке).
    https://www.linux.org.ru/news/opensource/12935157?cid=12935965
    Ниже по треду проблему с падением 7za тоже решили.

     
  • 2.59, RazrFalcon (ok), 01:42, 11/10/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >>информация о слоях удалена

    В SVG нет понятия Слой. Inkscape просто создаёт группу, которую svgcleaner с легкостью удаляет, ибо она не имеет смысла. "Отключенные слои" - это просто <g display="none">, вот я его и удаляю.

    Вы можете отключить: Ungroup groups и Remove invisible elements, что бы оставить "слои".

    >>считаю, что фраза "losslessly reduce size" из описания программы вводит в заблуждение.

    В README чётко описано зачем нужна прога: "The main purpose of the svgcleaner is to losslessly reduce size of an SVG image, created in a vector editing application, before publishing.". То есть чистить "рабочий" файл смысла нет.

     

  • 1.63, Xenia Joness (ok), 09:42, 11/10/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Консольная версия переписана с C++ на Rust.
    > Существенное увеличение производительности (до трёх раз быстрее)

    Отсюда следует вывод, что Rust быстрее C++ в 3 раза. Это вправду так?

     
     
  • 2.64, RazrFalcon (ok), 10:11, 11/10/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    https://www.opennet.ru/openforum/vsluhforumID3/109350.html#18
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру