Проект GIMP развивает новый формат изображений, идущий на смену XCF

Запросы к нейронкам сохраняются?

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

XML

ага верим

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

Дада, а zip архив магическим образом можно менять в середине файла без перестроения словаря. Наркоманы

Да там только SOAP в этом параде идиотии не хватает. Использовать XML для хранения картинок.

Ну и почему XML должен ы этом помешать?

Я и сам не фанат XML, лучше бы json взяли или что-то проще (смотря что за структуры в итоге хранить). Но это же в любом случае какие-то мизерные доли процента от всего файла. Если тебе вместо перезаписи 100-мегабайтного файла изображения с кучей слоёв, целиком, надо будет перезаписать в нём только один изменённый слой, скажем, на 1 МБ, и метаданные в XML, скажем, на десяток килобайт, формат этих метаданных в принципе неважен.

По теме: идея отличная. Давно пора.

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

Использовать XML для хранения картинок.

Хм… Кажется я понял, как вы двое это прочитали. Типа, что это будет только XML внутри ZIP, с битмапами прям в XML?

Из новости не очень понятно, но я как-то интуитивно понял это совсем иначе: картинки будут храниться в каком-то одном формате (я бы взял JPEG-XL lossless, что выберут в GIMP — хз), а помимо них будет один или несколько XML-файлов с мета-данными (какая картинка-слой как называется, в каком порядке они идут, какой выбран тип смешения, уровень прозрачности, и такое вот прочее), а также XML-файлы со всякими контурами и выделениями (а для них как раз XML или любой другой «текстовый» формат подходит хорошо, в отличие от битмапов).

Мне кажется, это имеется в виду. Потому и не «набор XML-файлов», а «набор файлов с разметкой XML» — файлы отдельно, XML отдельно. Да, несколько косноязычно, ведь XML тоже файлы, но логично. Если они и правда хотят битмапы в XML хранить, то это конечно маразм. Но разработчики GIMP ранее в маразме замечены не были, поэтому я не верю в такое развитие событий.

Что касается перестройки словаря — если сами битмапы хранить в каком-то формате, разработанном собственно специально для них, уже со сжатием (скажем JPEG-XL или WebP в режиме lossless, или банальный PNG), то на уровне самого zip можно их хранить без сжатия. Тогда, насколько я понимаю, перестройка словаря не потребуется.

upd: вот пруф: https://pasqualepillitteri.it/en/news/11717/gimp-new-file-format-29-years-xcf

A project becomes a zip archive containing XML documents and the layer images, with a structure similar to the one used by other creative software.

XML documents and the layer images

Сразу вспомнил вот об этом изображении.

Ну так во время работы над файлом он будет распакован куда-то в /tmp/XXX и вся работа будет проходить над распакованными файлами. При сохранении вновь создастся zip-архив уже с новыми файлами

Ну так во время работы над файлом он будет распакован куда-то в /tmp/XXX и вся работа будет проходить над распакованными файлами. При сохранении вновь создастся zip-архив уже с новыми файлами

Нет. Это полностью, что называется defeats the purpose. Смысл как раз в том, чтобы при сохранении не создавать новый архив (и не писать при изменении одного пикселя в одном слое десятки-сотни мегабайт), а сохранять только изменившиеся файлы внутри архива.

Ну и в принципе это не требуется и просто глупо.

Ага, сложный документ в 300-400 МБ со слоями, историей, 4к разрешением чтобы поправить один пиксель надо будет не сделать 1 seek по бинарю, write(f, 1, 1) и close, а:

• Распаковать куда-то ZIP
• Распарсить огромный XML (даже если они там не будут хранить картинки, всё равно XML - самое говно для парсинга, кто вообще им сказал что это отличная идея)
• В XML найти какие картинки отвечают за этот слой
• Распарсить картинку
• Сменить там пиксель
• Сохранить PNG
• Сохранить новый XML, потому что XML нельзя править «in place», там надо весь DOM перестраивать и сохранять, потому что текст и сдвиг
• Создать новый ZIP на диске где-то рядом
• И только тогда сделать in place move для атомарности перезаписи.

ускорит операции сохранения

На 146%

годно, благородно.

Из новости не очень понятно

будет использовать набор файлов с разметкой XML

Потому что как обычно, новости на LOR пишутся жопой.

Потому что как обычно, новости на LOR пишутся жопой.

В данном случае это копипаста с опеннета. Оттуда новости мы обычно не правим, если нет прям совсем уж чуши.

никто картинки в xml не хранит. Хранят структуру слоев, параметры фильтров, метаданные и все такое. Сами изображения хранятся файлами в архиве, на которые в xml ставятся ссылки.

Из новости не очень понятно

Потому что как обычно, новости на LOR пишутся жопой.

Бери и читай первоисточник

Гражданин выше сумел найти подробности про layers

Вообще-то если задаться целью именно минимизации перезаписи при изменениях, никто не мешает проработать тег <patch>, дописываемый в конец XML-файла, чтобы меньше гонять диск на авто-сохранении. При окончательном сохранении (или повторном открытии, если что-то пошло не так) - изменения накладываются чохом, в памяти, и массивные данные переписываются один раз.

Запихнуть все добро в mp4 контейнер, картинки хранить как есть, xml - сжать.

Для мелких проектов после каждого изменения перестройка с нуля приемлема.

Для больших проектов - вставка в хвост и переиспользование освободившихся блоков. При сильной фрагментации - перестройка с нуля.

За пару минут написал :)

Ну тут как бы тоже не один seek получается, если порассуждать.

Прочитать заголовок.
Прочитать разметку файла.
Найти нужное место с метаданными.
Найти нужное место с изображением.
Распаковать изображение.
Изменить пиксель.
Запаковать изображение.
Поменять метаданные.
Записать новую разметку файла.

по аналогии с OpenDocument, будет использовать набор файлов с разметкой XML, упакованных в ZIP-архив.

Это будет развитие формата Криты, или что-то совсем своё?

Они сейчас спецификацию выдумывают, очевидно свой костыль

Да нет там подробностей.

New Project File Format
The big focus for maintainer Jehan recently has been developing a new project file format for GIMP.

XCF has been GIMP’s primary project format since 1997, and it has served many users well. Over time however, we’ve observed more and more limitations of the binary XCF format. Among other issues, it does not easily support very large or complex projects, such as the multi-page and animation features currently planned for GIMP 3.6.

The new project file format will follow a more common “zipped XML” structure. While the technical details are still being designed and implemented, this change will allow for faster saving since we’ll only need to update parts of the file instead of the whole thing each time. It will also set the stage for much desired features such as auto-saving, which will now be much more feasible.

That said, XCF is not going away! Backwards compatibility is important to us, and we will continue to support loading XCFs in all future versions of GIMP. (For instance, we’re quite proud that a XCF file made by a small company for their logo in 1998 still renders the same way in the latest version of GIMP)

However, going forward we will only add support for saving/loading new features in the new project file format once it is finalized.

Остальное на опеннет расширили и углубили.

Распаковать куда-то ZIP

Зачем распаковывать весь архив, если можно вынуть 2 файла? (Точнее, 1 XML сразу, 1 PNG позже.)

Распарсить огромный XML (даже если они там не будут хранить картинки, всё равно XML - самое говно для парсинга, кто вообще им сказал что это отличная идея)

Если аналог ODT, там будет список слоёв и история правок. И текстовые элементы.

И можно пример долго парсящегося XML? lxml 10-мегабайтные текстовые FB2 парсит быстрее, чем они читаются с диска.

В XML найти какие картинки отвечают за этот слой

Xpath такой медленный?

Распарсить картинку Сменить там пиксель Сохранить PNG

Время на ручное редактирование оценить не берусь. Время распаковки deflate-ом на порядок меньше времени сжатия. Скорость сжатия zlib — 50-100 Мб/с на 1 ядре Ryzen 7 по первой попавшейся ссылке. Есть библиотеки в несколько раз быстрее.

Сохранить новый XML, потому что XML нельзя править «in place», там надо весь DOM перестраивать и сохранять, потому что текст и сдвиг

У меня это самая длительная операция при автоматической правке HTML скриптами на Python.

Создать новый ZIP на диске где-то рядом

Просто скопировать все части старого кроме изменённых файлов.

И если они повторят подход Криты и Фотошопа, будут ещё шаги — создать битмап текущего видимого состояния, сжать его в PNG, записать в ZIP.

Таким образом, самые затратные операции — сжатие XML и битмапов deflate-ом и запись на диск. Чем это хуже любого другого формата?

Но да, я XML тоже считаю избыточным.

P.S. Хотя SVG — тоже XML. Возможно, хотят взять что-то из него.

нет там подробностей

Я спросил на случай, если кто-нибудь тут знает.

По моей ссылке выше подробностей хоть и тоже негусто, но всё же чуть побольше: https://pasqualepillitteri.it/en/news/11717/gimp-new-file-format-29-years-xcf

А, ну вот:

with a structure similar to the one used by other creative software.

Криту вычёркиваем. :)

Зачем распаковывать весь архив

Просто скопировать все части старого кроме изменённых файлов.

А запаковывать обратно Вася Пушкин будет? Словарь собирать, сжатие делать? Ну и да, офигенная идея будет мне на диск срать копией того же самого, с чем сейчас работаешь. Диски и память же сейчас дешевая.

А запаковывать обратно Вася Пушкин будет? Словарь собирать, сжатие делать?

Отличие ZIP от tar.gz — все файлы в архиве сжимаются независимо. Поэтому же не имеет значения порядок файлов в архиве. PNG, кстати, сжимать нет смысла — тот же deflate, вероятно, той же библиотекой :) То есть копируем неизменившиеся сжатые файлы, пишем 2 новых PNG, добавив метаданных, сжимаем и пишем 1 XML, правим заголовок нового ZIP, стираем старый. Если битмапы гораздо больше XML, большую часть времени потратим просто на копирование.

Какие форматы кроме BMP и PPM позволяют модифицировать растровые изображения без перезаписи? :)

позволяют модифицировать растровые изображения без перезаписи? :)

Нет смысла хранить изображения в формате со сжатием внутри архива, который не будет добавлять из-за этого сжатие. С тем же успехом можно было делать .tar.gz.

Отличие ZIP от tar.gz — все файлы в архиве сжимаются независимо

Да плевать, что там независимо. Вы распаковали это говно целиком для работы в /tmp/gimp-xxx. У вас больше нет данных о том, как были запакованы файлы исходно. Сжиматься будет обратно весь субкаталог, а не «вот тут мы жмём, вот тут не жмём, вот тут на голову надеваем»

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

Вы распаковали это говно целиком для работы в /tmp/gimp-xxx. У вас больше нет данных о том, как были запакованы файлы исходно.

Что, при распаковке уничтожается исходный архив? GIMP-Roguelike? :) Хардкорные художества? :)

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

Какие программы так умеют?

Какие программы так умеют?

Што? Вы понимаете, о чём я? Степень сжатия PNG - N, степень сжатия архивом поверх PNG - M, степень сжатия BMP архивом - X. X > N, X ~= M. Какой смысл проводить работу по сжатию дважды? Чтобы что? Чтобы потом весь PNG перекодировать если один пиксель изменился?

with a structure similar to the one used by other creative software.

Криту вычёркиваем. :)

Почему?

Потому что похожая структура, а не прямо вот критовская.
Да и потому что KDE. :)

https://pasqualepillitteri.it/en/news/11717/gimp-new-file-format-29-years-xcf

Text layers imported from a PSD now become editable text inside GIMP, no longer flat images.

Отлично. 5 лет назад мне этого очень не хватало.

Потому что похожая структура, а не прямо вот критовская.

Могут сделать надмножество имеющегося.

Или вообще имели в виду ODT.

Ну полистай катрены Нострадамуса тогда.

степень сжатия архивом поверх PNG

Зачем сжимать PNG? Обычно его пакуют в режиме Store, добавляют ~16 байт информации.

Степень сжатия PNG - N, степень сжатия архивом поверх PNG - M, степень сжатия BMP архивом - X. X > N, X ~= M.

Алгоритм один, поэтому для битмапов N=X. Палитры в PNG не сжимаются, но там десятки или сотни байт. И вообще, индексированные PNG сейчас очень редки.

Чтобы что? Чтобы потом весь PNG перекодировать если один пиксель изменился?

Я повторяю вопрос: если тебя так возмущает сжатие ради 1 пиксела, какие программы так не делают?

Использовать XML для хранения картинок.

Ты это пишешь на сайте - тут используется html и картинки. Это буквально то же самое что и «хранение в xml». Ладно бы где-нибудь в irc этот бред откладывал, но тут-то совсем уж кринж.

Да хрен его знает! У старого формата вроде бы тоже есть преимущества.

Комментарии удивили. Неужели никто, никогда не смотрел файлы OpenDocument? Для меня это странно, потому что я их смотрю постоянно, например сегодня смотрел. TotalCommander > Ctrl+PageDown и ты внутри. Картинки отдельно, описание отдельно. Суперудобно, когда нужно по-быстрому выдрать картинки, которые не искажены и не кадрированы. Суперудобно, когда нужно заменить одну картинку другой ничего не меняя (хотя в последних версиях Либры нужно убедиться, что всё прошло успешно).

А ещё сравнивают txt и docx. Джопу с пальцем, что называется. Открываем Либру райтер, пустой документ с курсором. Смотрим Меню > Формат > Символы. Окошко на пять вкладок. В каждой вкладке 10-20 опций. Потом Меню > Формат > Абзац. Окошко на 9 вкладок. Потом Стиль страницы. Потом стиль текста. В общей сложности десятки и сотни опций для одного курсора. И по-другому нельзя. И сравнивать с txt тоже нельзя. Ваш кэп.

Дайте Lab в 16 бит плюс полноценный CMYK. Ну это буквально всё, что мне надо. :)

Неужели никто, никогда не смотрел файлы OpenDocument?

Да хоть проекты той же Krita, у которой такая же структура формата сто лет как (если вообще не изначально).

Но разработчики GIMP ранее в маразме замечены не были

Кхе-кхе GIMP кхе-кхе ToolKit

Извините, кашель чегой-то разошелся.

До первого апреля вроде бы ещё долго.

Но это не шутка. Jehan давно собирался этим заняться, т.к. вопрос уже даже не назрел, а перезрел (сам структура XCF, как я понял, уже довольно таки «жмёт» и становится сложно развиваться, не сломав формат). Ну, вот, занялся.

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

Кхе-кхе GIMP кхе-кхе ToolKit

Так когда его разрабы GIMP’а разрабатывали, он нормальным (относительно) и был. Это когда гномеры взялись, пошло всё по кхе-кхе (похоже, кашель заразен)

Были нормальные кути уже. Просто кто-то (Питер Матисс) решил, что сишечка с классами это весело. Чуваку было даже накласть на несвободность тогдашней кутешной лицензии.

You should understand that the GIMP and GTK weren’t written to fill holes in the software available under the GPL (GNU General Public License) and LGPL (GNU Lesser General Public License). The GIMP was started because I wanted to make a Web page. GTK was started because I was dissatisfied with Motif and wanted to see what it took to write a UI toolkit. These are purely selfish reasons.

NIH-синдром во все поля.