LINUX.ORG.RU

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

 , , ,


0

2

Разработчики графического редактора GIMP сообщили о работе над новым форматом изображений, который придёт на смену формату XCF (wikipedia.org), обеспечивающему сохранение всех данных, сопутствующих работе над изображением, включая сведения о слоях, выделенных областях, каналах и выставленных направляющих. Отмечается, что формат XCF имеет ряд ограничений и плохо подходит для больших или сложных проектов, таких как многостраничные и анимированные изображения, которые планируют реализовать в ветке GIMP 3.6.

Вместо жёстко структурированного бинарного формата новая реализация, по аналогии с OpenDocument, будет использовать набор файлов с разметкой XML, упакованных в ZIP-архив. Детали реализации пока находятся в разработке, но предполагается, что новый формат ускорит операции сохранения, так как при периодическом сохранении потребуется изменять лишь отдельные части файла, без необходимости перезаписывать всё содержимое, и позволит избавиться от усложнений, мешающих реализовать функцию автоматического сохранения.

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

>>> Подробности на OpenNET

★★

Проверено: CrX ()
Последнее исправление: CrX (всего исправлений: 1)
Ответ на: комментарий от s-warus

разбирать ответ когда схема разная в зависимости от поля

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

MirandaUser2 ★★
()
Ответ на: комментарий от PPP328

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

Разве он не поддерживает возможность использования независимых словарей для каждого файла?

andreyu ★★★★★
()
Ответ на: комментарий от PPP328

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

Картинки могут остаться бинарными: каждый слой - свой бинарь. Причем и слои можно разделить на каналы. Эффекты переедут в xml - можно читать глазами, можно делать осмысленный diff.

andreyu ★★★★★
()
Ответ на: комментарий от PPP328

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

Вот этот пункт про XML вроде как ненужен. Изменился то только PNG.

Xintrea ★★★★★
()
Ответ на: комментарий от PPP328

В XML 99.9(9)% хранятся метаданные. Это же проект, а не картинка. А сами бинарные данные в блобах в том же zip-е. Zip умеет в словарь и, соответственно, с каждым файлом архива можно работать, как с отдельным стримом (можно даже степень сжатия разную давать), не пересобирая весь архив и не распаковывая его полностью.

Соответственно, алгоритм: распаковать XML -> распарсить XML -> распаковать стрим с бинарём картинки (не факт, что его вообще сжимали) -> заменить пиксель -> обновить стрим слоя.

Претензий к парсеру вообще не понял: тотже libxml2 парсит мегабайтные XML-ки за миллисекунды. Думаешь там будет настолько суровый XML (даже если туда всю историю запихать)?

SkyMaverick ★★★★★
()
Ответ на: комментарий от SkyMaverick

libxml2

Я всё гадал, кто первый этот кусок кала вспомнит. Который умеет насиловать valgrind во все байтовые отверстия и не освобождать память. А какой там зоопарк версий с разным API. Ууууу.

PPP328 ★★★★★
()
Ответ на: комментарий от PPP328

Я всё гадал, кто первый этот кусок кала вспомнит.

Тем не менее, библиотека чрезвычайно широко используется. Production-ready парсеров XML чуть более, чем дохрена, и я не знаю, что там заюзал Jehan. Код он пока держит в приватной ветке. Как будет код, так будет о чем говорить.

SkyMaverick ★★★★★
()
Ответ на: комментарий от PPP328

Надо 🤦️🤦‍♂️️🤦‍♀️️ тебе и всем кто поставил ☕️☕️. Zip — это почти такой же контейнер, как и tar, только хуже сделанный (стандарт ничего про кодировку не говорил изначально, права и метаинформация не поддерживается), но в отличии от tar zip это контейнер в котором файлы не склеиваются в один жирный SOLID файл, а после жмутся, а лежат каждый рядышком с оглавлением. И когда ты добавляешь файл, то единственное изменение происходит с самим файлом и словарём, который сам по себе очень мал и служит оглавлением. Остальное добро вообще никак не меняется. Он NonSolid и не имеет поддержки Solid как tar не бывает Non Solid и потому меняется только хвост (конец файла). Единственная проблема, если у тебя в архиве 1 000 000 мелких файлов лежат. Тогда словарь будет крупный (для каждого файла свои записи).

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 1)

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

Это OpenRaster из 2006 года?

Eshkin_kot ★★
()
Ответ на: комментарий от Eshkin_kot

Это OpenRaster из 2006 года?

Чем он отличается от .kra?

И сколько программ его понимают, помимо Krita, GIMP, MyPaint and Scribus?

question4 ★★★★★
()

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

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

Но если это зип, наверняка придётся перепаковывать… Что совсем не быстро?

anonmyous ★★★
()
Ответ на: комментарий от anonmyous

Но если это зип, наверняка придётся перепаковывать… Что совсем не быстро?

Если сделают как в Крите, там каждый слой — отдельным PNG, а общая структура документа и текст — в XML. То есть неизменившиеся слои можно не перепаковывать. А Deflate по нынешним временам работает быстро. Хотя сжимает не очень.

question4 ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.