Comments 23
Во-первых, интересно было бы увидеть технических деталей. Во-вторых - тестирования. В третьих - как оно планируется работать с софтом нынешним. В-четвёртых, новый формат и версия уже 16. А предыдущая - 12.
И - не ещё один ли это архиватор Бабушкина?
Очевидно, что номер версии - это возраст автора на момент выпуска спецификации. :-D
В настоящее время формат переписывается на c++ для лучшей эффективности, продумывался вопрос совместимости формата, как мне кажется это решается с помощью Fallback Cache. Формат может показать изображение везде, хотя не в полной форме именно как .pi
Формат улучшается, будет переработана структура для лучшей скорости
Он станет универсальным даже для анимации будет
Выглядит как-то толсто, если честно -_-
Это прототип?
Масштабное переиспользование ресурсов, мгновенные «живые» обновления общих активов во всех ссылающихся PIX‑файлах, возможность собирать сцены из распределенных источников (например, из облака или удаленных серверов).
Идея конечно интересная, но тогда нельзя, например, просто скинуть кому-то картинку, если она имеет локальные зависимости
Вам совет автор, проверяйте текст после нейронки. Есть определенные слова, например, как "активы" которые она переводит, но в реальной жизни никто так "ассеты" не называет.
Судя по тому, что я увидел в коде это именно что контейнер, через который идет доступ к изображениям в другом формате. А вот jpeg, png которые вы обозвали просто контейнерами - полноценные форматы изображений со своими алгоритмами сжатия, например.
Профессиональный Графический Дизайн: Реальная альтернатива PSD
Ну если это реальная альтернатива, то где расширение для фотошопа? Может интеграция с Gimp/Krita хотя бы есть? Или может вы собственный паинт хотя бы сделали для него? Что насчёт поддержки непиксельных слоёв: маски, настройки, смарт объекты, текстовые и прочие?
Веб-Разработка
Сравнительные характеристики делали? какой-нибудь progressive PNG vs JPEG XT/XL vs PIX? Время скачки, время до первой отрисовки и вот это вот всё? JS драйвер для обратной совместимости или хотя бы рендеринг на канвас есть?
Тот же вопрос и к геймдеву - где хотя бы простенький пример. Возьмите raylib и сделайте хотя бы простенький платформер с анимациями. Кстати как редактировать анимации? Есть какой-то редактор а ля Asersprite/Libresprite/Spine2D?
терабайты данных
смелое, но ничем не подкреплённое утверждение. попробовали бы хотя бы импорт из того же PSD сделать со здоровенной историей, или ту же kra из krita.
криптографическим хешем для проверки целостности.
не понимаю как это бьётся с вохможностью обновлять ссылки на внешние источники - если внешний ресурс изменился, то хэш по идее инвалидируется, и что происходит дальше? Внешний ресурс тоже должен быть pi и содержать тот хэш в истории или можно сослаться на обычные jpeg/png?
Спека на формат существует только в PDF и только в телеге. Почему не отдельная репо с тестами или хотя бы тестовыми изображениями и простым текстовым представлением? Где тесты, Джонни? Особенно интересует фаззинг тестирование имплементации.
Детальное описание отдельных чанков отсутствует. Зачем-то торчит секция Conclusion, которая опять же не подкреплена ничем.
Благодарю за развернутый комментарий, я понимаю вас, в ближайшее время проект будет развиваться, будет больше практических примеров. Надо все продумать, выпустить документацию
Формат данных это база, по которой можно дать оценку, тесты это вторая часть по которой можно показать преимущество, пока что выглядит бла-бла-бла, неплохо бы свою работу, если вы претендуете на суперэфективный формат дать экспертам на рецензию, а так это выглядит все мягко говоря не очень
by a mandatory cryptographic signature
а зачем там цифровая подпись ещё? оно у вас исполняемым файлом ко всему является? для контроля целостности кажется достаточно простенький sha256 посчитать, вместо упомянутого crc32.
Дорогой друг, ты сильно торопишься. Я понимаю какого это - изобрести что-то инновационное в 14 лет, но прошло время, теперь я также знаю, что такое крах ожидании, разочарование в собственном продукте.
На твоём месте я бы до появления документации на уровне научной статьи с подробнейшим и понятнейшим объяснением процесса, полностью отшлифованным алгоритмом, полным пониманием процесса, уверенности в завершённости, реализации визуализации, сохранения, плагинов для графических редакторов никуда бы не публиковался, разработку бы обсуждал в нешироком кругу ведающих людей.
Не стоит делать столь громкие заявление о революции в 16 лет в статье на 3 минуты просмотра, не обсудив концепцию 10 раз. Ты начал с этим рано. Чем больше людей увидят крах твоих ожиданий, о которых ты заявил публично, тем больше ты разочаруешься в себе, а надо ли так рисковать?
Автору советую прочесть спецификацию формата TIFF. Можно будет почерпнуть много интересного. А, для работы с ним есть открытые библиотеки на C++ --- тоже можно посмотреть, как делается код.
Если интерес останется, то предложил бы ему вступить в группу разработчиков TIFF, куда и предложить какие-то вещи.
Т. е. для общества и самого автора ценнее будет расширить tiff, чем пилить вещь в себе.
Молодец. С чего-то надо начинать.
Мы в 16 тоже написали компилятор для Си с ассемблерными вставками для архитектуры PDP 11, (было реализовано подмножество Си), не все команды), что потом сильно помогало. Интернет тогда был не в свободном доступе, потому пилили автономный проект. Сейчас же можно работать с мировым сообществом, а не отдельно в пещере программировать.
Не проведя аналитику текущих форматов это сразу фейл, все таки стоит пойти в университет и поучится хотя бы этому
Поучиться университету --- всегда почётно! Согласен!
Однако, есть моноформаты (быстрые в программировании), а есть контейнерные форматы, типа TIFF, позволяющие кодировать любые сеточные (растровые) структуры любыми кодеками. Мы обменивались, например, с заказчиками полями, где каждая ячейка была вещественным (Sic!) числом в начале 90-х. Это было уже в стандарте. )) Да, и изучал я это в университете, который до моды 90-х назывался институт. ))
Кто знает отличия институтского образования от университетского (до момента, когда все стали университетами из-за моды западной) смогут тут Вам подсказать.
Ну концептуально напомнило множество форматов с хранением данных о файлах. В Adobe Illustrator есть ссылки на файлы и уровни качества отображения. В блендере линкуется вообще чуть ли ни всё.... Но в итоге это облегчает предпросмотр и редактирование. А конечный объем отображаемых данных при сохранении документа в формат для печати или рендер(3d, видео). Или же полностью загруженная веб страница будет иметь большой вес закэшированных данных. По факту имеем просто контейнер, который обычно разрабатывается индивидуально под пакет софта или софтины. Конечное отображение файла с динамически изменяемым изображением и анимацией за счёт изменяемых атрибутов в итоге сожрёт память. В пример SVG файл с атрибутами в пару сотен килобайт может развернуться в пару сотен мегабайт видео памяти. А это уже другая история....сжатие...алгоритмы....
Эх, а я в своё время случайно придумал то, что на поверку оказалось давным-давно известным base64. Надо было иконки в одной программе хранить в виде текстовых ресурсов. Причём стандартный декодер понял "мой" формат.
Еще можно придумать, что вместо 64 может быть любое натуральное число, вот здесь можно поиграться (и посмотреть исходники): http://kvanttt.github.io/BaseNcoding/
Как я создал формат изображений на уровне png в 16 лет