Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Проект GIMP развивает новый формат изображений, идущий на смену XCF"	+/–
Сообщение от opennews (??), 24-Авг-26, 12:21
Разработчики графического редактора GIMP сообщили о работе над новым форматом изображений, который придёт на смену формату XCF, обеспечивающему сохранение всех данных, сопутствующих работе над изображением, включая сведения о слоях, выделенных областях, каналах и выставленных направляющих. Отмечается, что формат XCF имеет ряд ограничений и плохо подходит для больших или сложных проектов, таких как многостраничные и анимированные изображения, которые планируют реализовать в ветке GIMP 3.6... Подробнее: https://www.opennet.me/opennews/art.shtml?num=66124
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 24-Авг-26, 12:21	–16 +/–
Лучше бы psd поддерживали на нормальном уровне
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #3, #4, #11

2. Сообщение от Alladin (?), 24-Авг-26, 12:28	+4 +/–
а потом узнаешь что psd тоже не очень
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #41

3. Сообщение от Аноним (3), 24-Авг-26, 12:28	+5 +/–
это задача адобе поддерживаь свой формат на нормальном уровне
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

4. Сообщение от limafresh (ok), 24-Авг-26, 12:34	+1 +/–
А что, у GIMP комплекс неполноценности по сравнении с Photoshop? Почему Photoshop можно иметь свой формат, а GIMP должен только подстраиваться под чужой?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #5, #7

5. Сообщение от Аноним (5), 24-Авг-26, 12:36	–7 +/–
потому что psd это стандарт
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #6, #9, #24, #34, #37, #57

6. Сообщение от Аноним (6), 24-Авг-26, 12:36	+6 +/–
Это выдумка маркетологов и корпорастов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #8

7. Сообщение от Аноним (7), 24-Авг-26, 12:38	+/–
действительно, зачем им подстраиваться под OpenDocument
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #13

8. Сообщение от Аноним (8), 24-Авг-26, 12:39	–5 +/–
Это факт. Так же, как и docx/xlsx/pptx. Он, конечно, может не нравиться, но факт — вещь упрямая.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #23

9. Сообщение от limafresh (ok), 24-Авг-26, 12:42	+3 +/–
Только потому что его положение Photoshop на рынке и потребители воздвинули в "стандарт". По такой логике любого монополиста можно назвать "стандартом" и отрицать возможность альтернатив.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #21, #40, #46

10. Сообщение от anonymous (??), 24-Авг-26, 12:42	+/–
Может я глуп и ничего не понимаю в пиксельных редакторах, но как они собираются хранить битмапы в xml? <point x="0" y="0"><color r="120" g="120" b="0"/></point> <point x="0" y="1"><color r="102" g="120" b="0"/></point> и так миллион раз?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #14, #15, #17, #19, #20, #22, #25, #35, #39

11. Сообщение от Аноним (21), 24-Авг-26, 12:45	+/–
За этим в Krita.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

12. Сообщение от tkzv (ok), 24-Авг-26, 12:46	+/–
> набор файлов с разметкой XML, упакованных в ZIP-архив. Расширят спецификацию критовского KRA, или создадут что-нибудь несовместимое?
Ответить | Правка | Наверх | Cообщить модератору

13. Сообщение от limafresh (ok), 24-Авг-26, 12:47	+/–
Не нашёл в новости ничего про подстраивание, только > по аналогии с OpenDocument, будет использовать набор файлов с разметкой XML, упакованных в ZIP-архив ключевое слово "по аналогии". Т.е. просто возьмут ту же идею без копирования формата.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

14. Сообщение от Аноним (21), 24-Авг-26, 12:48	+/–
А как в binary, по-твоему?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

15. Сообщение от tkzv (ok), 24-Авг-26, 12:50	+1 +/–
Либо base64, либо в виде очень длинных 16-ричных чисел. HTML с base64 в IMG понимают современные браузеры. Либо как ODT — битмапы отдельными файлами PNG. Или что умеет особые цветовые пространства.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

16. Сообщение от Аноним (17), 24-Авг-26, 12:51	+1 +/–
Теперь у вас 100500 новых несовместимых стандартов.
Ответить | Правка | Наверх | Cообщить модератору

17. Сообщение от Аноним (17), 24-Авг-26, 12:52	+/–
Твои битмапы будут упакованы в zip архив в новости написано.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #18, #59

18. Сообщение от tkzv (ok), 24-Авг-26, 12:55	+2 +/–
> Твои битмапы будут упакованы в zip архив в новости написано. Если каждый 3-байтый пиксель расписывать в 58 байт, deflate не поможет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #36

19. Сообщение от Аноним (19), 24-Авг-26, 12:55	+/–
Действительно, как хранят битмапы в HTML?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

20. Сообщение от llolik (ok), 24-Авг-26, 12:56	–1 +/–
<bitmap id='uuid:xx-xxxx-xxxx-xxxxxx'>   <color_space>rGBA</color_space>   ... /* ещё какие-нибудь данные */   <stream> /* поток данных */</stream>   </bitmap> Примерно, так как-нибудь, например.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #28, #44

21. Сообщение от Аноним (21), 24-Авг-26, 12:57	–1 +/–
Главное, поддерживается рабочим софтом. Ну, не хуже, чем фш соседних версий. Гимп в перечень софта для работы, понятно, не очень вписывается, но к чему создавать лишние неудобства.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

22. Сообщение от Аноним (22), 24-Авг-26, 13:02	+1 +/–
Точно так же, как это хранит Word. Там DOCX - это zip-архив, в котором лежит XML и ещё кучка файлов, в том числе - внедрённые картинки прямо в том формате, в котором их внедрили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #55

23. Сообщение от Аноним (23), 24-Авг-26, 13:13	+1 +/–
В гос- и полугосконторах их уже успешно заместили на ODF.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #26, #45

24. Сообщение от Аноним (23), 24-Авг-26, 13:16	+/–
А где .psd ещё используется, кроме ФЖ ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

25. Сообщение от Аноним (23), 24-Авг-26, 13:18	+/–
Отдельным файликом в общем архиве. Всё, как в ODF.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

26. Сообщение от Albertio (ok), 24-Авг-26, 13:18    Скрыто ботом-модератором	+/–
Да да, поэтому-то доки просят принести в .doc даже не .docx, а про другие форматы там и не слыхали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #38

27. Сообщение от Аноним (-), 24-Авг-26, 13:19	+/–
> будет использовать набор файлов с разметкой XML, >  упакованных в ZIP-архив. > Детали реализации пока находятся в разработке, но предполагается, что новый формат > ускорит операции сохранения Вот прям XML и ZIP? Ускорит что-то? Предполагаааааается?! Господи, откуда такие в гимп поналезли. Они это XML вообще пробовали парсить чтобы рассказывать как это круто и быстро?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #30, #47, #49, #51

28. Сообщение от Аноним (-), 24-Авг-26, 13:30	+/–
> Примерно, так как-нибудь, например. Да, теперь попробуй читауть в ЭТОМ - хотя-бы 200 байтов из середины битмапа. А, про ускорение чтения и работы - никто не говорил?! :). Да и формат ZIP для рандомных записей никто никогда не делал так то. И вообще - парсинг более-менее крупного битмапа станет не слишком пресным и быстрым занятием. Это не только SAX-style брейнфак - но еще и из зипаря к тому же. Можете попробовать конечно парсинг в стиле DOM - но тогда терабайт оперативки понадобится. А уж сколько вулнов можно в XML-based - это песня. Например, можно вложить дохреналиард тегов в друг друга и посмотреть - что будет дальше. Да, это кстати работает. Некоторые наиболее прошареные парсеры даже законопатили. Немного и криво. Про размер и число элементов и вовсе упоминать неудобно. А в зипе к тому же еще и zip bomb будет просто изумительный. Так что если вы кой-как наскребли терабайт оперативы - можно будет и десяток терабайт затребовать весьма компактным файлом. А потом залить такой ассет кому-нибудь с автопарсингом - посмотреть как ему такое вообще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #42

29. Сообщение от Аноним (29), 24-Авг-26, 13:31	+/–
Еще в нулевых об этом заявляли. Смотрю, они быстрые ребята.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #50

30. Сообщение от Ъ (?), 24-Авг-26, 13:38	+/–
> Они это XML вообще пробовали парсить В GIMP давно уже есть поддержка OpenRaster, тот же самый XML/ZIP.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

31. Сообщение от Аноним (31), 24-Авг-26, 13:40	+/–
Че как там пгыщавые дизайнеры, пользуете гимп?
Ответить | Правка | Наверх | Cообщить модератору

34. Сообщение от Аноним (34), 24-Авг-26, 13:49	+/–
Стандарт центра сертификации и стандарт на psd в студию.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

35. Сообщение от Аноним (34), 24-Авг-26, 13:50	+/–
Сверху zip.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

36. Сообщение от Аноним (34), 24-Авг-26, 13:52	–1 +/–
Deflate обязателен?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

37. Сообщение от Alladin (?), 24-Авг-26, 13:53	+/–
стандарт кого или чего? адоб фотошопа?, ну да у них это стандарт, а гимп и другие причем тут?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

38. Сообщение от Аноним (23), 24-Авг-26, 13:54	+/–
У нас не просят. Вся разрабатываемая КД в ODF после 2022.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

39. Сообщение от Alladin (?), 24-Авг-26, 13:55	+/–
миллион раз и сожмем:) я думаю что у них будет zip в котором будут xml файлы и куски битмапов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

40. Сообщение от ИмяХ (ok), 24-Авг-26, 13:55	+/–
>>любого монополиста можно назвать "стандартом" Так ведь именно так зачастую стандарты и создаются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

41. Сообщение от Аноним (41), 24-Авг-26, 13:58	+/–
В мире линукса не должно быть совместимости, надо постоянно что-то новое делать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #56

42. Сообщение от llolik (ok), 24-Авг-26, 14:00	+/–
>> Примерно, так как-нибудь, например. > Да, теперь попробуй читауть в ЭТОМ - хотя-бы 200 байтов из середины > битмапа. А, про ускорение чтения и работы - никто не говорил?! А сейчас в бинарном формате (по сути наборе структур, которые тоже надо двигать) так это дохрена быстрей, да? > И вообще - парсинг более-менее крупного битмапа станет не слишком пресным и > быстрым занятием. Это не только SAX-style брейнфак - но еще и > из зипаря к тому же. Кто сказал, что zip не будет распковываться в начале тракта и паковаться в конце? > А уж сколько вулнов можно в XML-based - это песня. Кто сказал, что они будут кастомный парсер городить, а не использовать хоть GLib-овский, хоть любой сторонний (тотже Expat)? Вообще, кода ещё нет. Ну, вернее, Jehan его пока в приватной ветке держит. Как будет код, так будет о чём говорить. И да, примерно у дохрена программ такой-же формат хранения и они вот как-то справляются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #52

43. Сообщение от Аноним (51), 24-Авг-26, 14:01	–1 +/–
> Вместо жёстко структурированного бинарного формата новая реализация, по аналогии с OpenDocument, будет использовать набор файлов с разметкой XML, упакованных в ZIP-архив. Звучит блевотно, как и 3ий гимп на вид.
Ответить | Правка | Наверх | Cообщить модератору

44. Сообщение от Аноним (41), 24-Авг-26, 14:02	+/–
> <stream> /* поток данных */</stream>   И привет, мир! Если раньше какой-нибудь почти бесконечный bmp можно было мапнуть напрямую в память и работать мгновенно с нужными кусочками по необходимости, то теперь одна только загрузка будет по полчаса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #48

45. Сообщение от Аноним (8), 24-Авг-26, 14:02	+/–
1) не от хорошей жизни 2) зашёл сейчас на РосСтат (более гос- и быть не может) — выгрузка в XLSX. Очень успешно заместили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #54

46. Сообщение от Аноним (8), 24-Авг-26, 14:03	+/–
Альтернативы никто не отрицает. Но либо им придётся учитывать монополиста, либо так и оставаться маргиналами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

47. Сообщение от llolik (ok), 24-Авг-26, 14:04	+/–
> Господи, откуда такие в гимп поналезли Всего-то мужик 20 лет GIMP мейнтейнит и один из основных его разработчиков. Не то что аноним опеннета :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

48. Сообщение от llolik (ok), 24-Авг-26, 14:06	+/–
>> <stream> /* поток данных */</stream> > И привет, мир! Если раньше какой-нибудь почти бесконечный bmp можно было мапнуть > напрямую в память и работать мгновенно с нужными кусочками по необходимости, > то теперь одна только загрузка будет по полчаса. Что мешает мапнуть, как связанный слой (справка: он в проекте не хранится)?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #53

49. Сообщение от Аноним (41), 24-Авг-26, 14:06	+/–
> откуда такие в гимп поналезли Это те самые, которые кинули гтк-2 и начали 3 и 4.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

50. Сообщение от Аноним (23), 24-Авг-26, 14:06	+/–
А то. Сколько на GTK 3 переходили!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

51. Сообщение от Аноним (51), 24-Авг-26, 14:06	+/–
Получается гипм начнёт сохранять jpeg в zipе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

52. Сообщение от Аноним (-), 24-Авг-26, 14:12	+/–
> А сейчас в бинарном формате (по сути наборе структур, которые тоже надо двигать) > так это дохрена быстрей, да? Внезапно, читануть 200 байтов из середины битмапа можно тупо вычислением нескольких смещений. Попробуй так с XML и сравни... :) > Кто сказал, что zip не будет распковываться в начале тракта и паковаться в конце? А, ну да, декомпресс 100500 гигз в большом проекте наверняка добавит ему скорости :) Кстати так на подумать - ".doc" и прочие XLS и проч - были по сути диск-в-файле. С произвольным содержимым как типа-файлы (или обьекты) в "диске". Мне почему-то кажется что сие можно было читать-писать куда резвей чем зипушник. Особенно с полным декомпрессом и рекомпрессом то. > Кто сказал, что они будут кастомный парсер городить, а не использовать > хоть GLib-овский, хоть любой сторонний (тотже Expat)? Да я ими даже пользовался, но в целом для потенциально больших и навороченных данных это как раз - тот еще брейнфак. А быстро вынуть 200 байтов из середины огромного битмапа без репарсинга станет вообще - малореально. Даже в стиле SAX-парсинга придется весь поток жевать, фиг бы его заранее знает какого размера. Можно конечно заранее размер написать но тут возникнет вопрос доверяем ли мы юзерскому вводу - и проверка этого в стиле вот именно SAX это тоже - брейнфак, увы. А так на подумать - OSM Planet как раз ворочали БОЛЬШИЕ и СЛОЖНЫЕ XML. Забодались в край и родили свой "pbf" в результате. Правда, его схема - фиксированная и априори известная, но это никак не мешает сохранению в него новых, ранее неизвестных, типов данных, атрибутов и проч. Те кто про них не в курсе - могут просто скипать сие. Правда это поточный формат а не формат для быстрого редактирования. Но если мы про рекомпресс и декомпресс всего файла от и до - там аналогично.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

53. Сообщение от Аноним (-), 24-Авг-26, 14:14	+/–
> Что мешает мапнуть, как связанный слой (справка: он в проекте не хранится)? Что такое "связанный слой" в терминах операций с памятью? В случае BMP можно по сути mmap() сделать и далее - работать с вот этим массивом пикселей в памяти напрямую, а это еще и прозрачно сохраняется на диск "по ходу пьесы".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #58

54. Сообщение от fi (ok), 24-Авг-26, 14:14	+/–
а там текст в .csv  )))))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

55. Сообщение от Аноним (-), 24-Авг-26, 14:17	+/–
А так то DOC был - по сути диск в файле, с файлами-объектами внутрях. Только более дружественный к вот именно рандомному доступу, перезаписи и проч чем ZIP и XML. Но - не модно, видите ли, надо что-нить энтерпрайз-грейд запилить было в пику ODF, который тоже на техническом уровне - не шедевр мягко говоря. И получилсь 2 уродца...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

56. Сообщение от Аноним (56), 24-Авг-26, 14:21    Скрыто ботом-модератором	+/–
Не должно быть совместимости так же, как в проприетарях с закрытыми и обмазанными зондами спеках? Ничоси новости...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

57. Сообщение от Аноним (56), 24-Авг-26, 14:22	+/–
ну не знаю, у меня стандартная фотокамера, стандартный телефон, стандартный принтер и стандартный пейнт из коробки не понимают этот ваш "стандартный" PSD
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

58. Сообщение от llolik (ok), 24-Авг-26, 14:27	+/–
>> Что мешает мапнуть, как связанный слой (справка: он в проекте не хранится)? > Что такое "связанный слой" в терминах операций с памятью? В случае BMP > можно по сути mmap() сделать и далее - работать с вот > этим массивом пикселей в памяти напрямую, а это еще и прозрачно > сохраняется на диск "по ходу пьесы". Я о том, что для этого вообще файл проекта парсить не надо. Связанный слой - это ссылка на внешний файл.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

59. Сообщение от anonymous (??), 24-Авг-26, 14:29	+/–
> будет использовать набор файлов с разметкой XML, упакованных в ZIP-архив вот что написано в новости. Никаких png или битмап-файлов в архиве не предусмотрено. Только XML, но это же убиться можно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема