Comments 46
Почти все функции, упомянутые вами, есть в TIFF. А те, которых нет — можно добавить, благо формат расширяемый.
Вот только из за всего этого преферанса с куртизанками компактностью этот формат никак не может похвастаться :(
Вот только из за всего этого преферанса с куртизанками компактностью этот формат никак не может похвастаться :(
Почему? Делается заголовок, в 4-8 байт, в котором указываем, то у нас дальше: простой jpeg, или raw, или ещё что, или всё в куче, со всеми плюшками (новый формат). Если это аватарка 100х100 пикселей, то 4 лишних байта погоду не сделают, а формат один и тот же по сути.
TIFF замечательный формат, но это формат для хранения и обработки данных, но никак не для публикации. Хотя в нём есть поддержка JPEG компрессии но всё же в нем есть поддержка и несжатых форматов. А зачем формату для публикаций поддержка несжатых форматов? Кроме того, где в TIFF'е поддержка стерео, областей с переменной плотностью пикселей? А как сказать, что это изображение является панорамой 180 градусов по горизонтали и 90 по вертикали и задать окно для просмотра? И что насчёт HDR?
Никто не мешает хранить в TIFF стерео. Введите тег для карты глубин и храните. Аналогично со всем остальным. HDR — без проблем, TIFF позволяет хранить 16 бит на компоненту цвета и даже 32, если не ошибаюсь.
Конечно никто не мешает, но никто и не способствует этому. TIFF, как я уже сказал выше замечательный формат, но благодаря своим возможностям он слишком тяжёлый, перегруженный. Это его недостаток. К примеру, может кто не в курсе, но HTML — это упрощённая версия языка SGML (по крайней мере на тот момент, когда он только создавался). Именно благодаря своей простоте он завоевал популярность и стал стандартом в Интернете. Ну, а уже потом стали добавлять в него дополнительные теги, появились стили и прочее. Что касается 16 бит на компоненту или даже 32, то я противник такого подхода. В самом начале статьи я указал на чёткое разделение форматов для хранения и обработки и публикации. Именно благодаря своей недоделанности, обрезанности JPEG и стал таким популярным. Если бы он хранил цвет в 16 бит или 32 бит на канал, он бы весил в несколько раз больше (и не 2 или 4, а гораздо больше). Мне больше по душе идея формата FJPEG, упомянутая в статье.
Это вы не в курсе.
HTML не является более простым подмножеством более сложного языка SGML, он всего лишь был построен по его принципам, то есть их нельзя противопоставлять как «простое» и «сложное» и делать вывод, что именно потому HTML завоевал популярность. Плюс, у HTML практически не было альтернатив, за то была поддержка со стороны разработчиков browser-ов.
А ваше «четкое разделение» на презентационные форматы и форматы для хранения — высосано из пальца.
HTML не является более простым подмножеством более сложного языка SGML, он всего лишь был построен по его принципам, то есть их нельзя противопоставлять как «простое» и «сложное» и делать вывод, что именно потому HTML завоевал популярность. Плюс, у HTML практически не было альтернатив, за то была поддержка со стороны разработчиков browser-ов.
А ваше «четкое разделение» на презентационные форматы и форматы для хранения — высосано из пальца.
HTML и XML произошли от SGML. HTML — это приложение SGML, а XML — это подмножество SGML, разработанное для упрощения процесса машинного разбора документа. Другими приложениями SGML являются SGML Docbook (документирование) и «Z Format» (типография и документирование).
Насчёт поддержки со стороны разработчиков веб-браузеров — не было тогда ещё браузеров. Просто не было. Был только один NCSA Mosaic.
А насчёт разделения, так это я тут с Вами соглашусь — большинство не видит разницы, однако для меня разница существенна.
Насчёт поддержки со стороны разработчиков веб-браузеров — не было тогда ещё браузеров. Просто не было. Был только один NCSA Mosaic.
А насчёт разделения, так это я тут с Вами соглашусь — большинство не видит разницы, однако для меня разница существенна.
Я тоже умею цитировать википедию, но та цитата, которую вы привели, не опровергает того, что я написал применительно к HTML. SGML сам по себе языком разметки гипертекстовых документов не является, так что говорить о том, что HTML — это «упрощенная версия» SGML — совершенно неверно. Также как было бы неверным назвать, скажем, Pascal упрощенной версией английского языка, основываясь на том, что в Pascal используются слова, позаимствованные из английского, и точно также разделяемые пробелами и знаками препинания.
Про историю HTML — вы ее тоже знаете плохо. Первый вариант HTML был разработан еще в 1990м году неким Tim Breners-Lee, работавшим с CERN, и эта разработка использовалась в его программе HyperMedia Browser/Editor, которая была написана для рабочих станций NeXt. Одновременно была разработана начальная версия HTTP — hypertext transfer protocol, специально для нужд доступа к гипертекстовым документам, а также CERN httpd для размещения таких документов. Потом, для этой инфраструктуры (язык разметки и серверное приложение) было написано еще одно средство, ViolaWWW являвшееся, фактически, первым browser-ом в нынешнем понимании этого слова — со стилями и скриптами.
А уже потом господа Marc Andreessen и Eric Bina начали разработку своего клиентского приложения под Windows — NCSA Mosaic для уже существовавшей пару лет сложившейся «мировой паутины». И у них другой альтернативы кроме поддержки уже начавшего развиваться HTML не было.
Другой ветвью развития интерактивных сервисов был gоpher, но это совсем-совсем другая история, которая очень быстро прекратилась.
Про историю HTML — вы ее тоже знаете плохо. Первый вариант HTML был разработан еще в 1990м году неким Tim Breners-Lee, работавшим с CERN, и эта разработка использовалась в его программе HyperMedia Browser/Editor, которая была написана для рабочих станций NeXt. Одновременно была разработана начальная версия HTTP — hypertext transfer protocol, специально для нужд доступа к гипертекстовым документам, а также CERN httpd для размещения таких документов. Потом, для этой инфраструктуры (язык разметки и серверное приложение) было написано еще одно средство, ViolaWWW являвшееся, фактически, первым browser-ом в нынешнем понимании этого слова — со стилями и скриптами.
А уже потом господа Marc Andreessen и Eric Bina начали разработку своего клиентского приложения под Windows — NCSA Mosaic для уже существовавшей пару лет сложившейся «мировой паутины». И у них другой альтернативы кроме поддержки уже начавшего развиваться HTML не было.
Другой ветвью развития интерактивных сервисов был gоpher, но это совсем-совсем другая история, которая очень быстро прекратилась.
Это только у меня возникло ощущение, что происходит смешивание «мух и котлет»? Мне кажется, что надо разделять понятия формат представления изображения и структура контейнера для данных изображения. То есть, к примеру, использовать контейнер TIFF, который, как правильно заметили выше, достаточно универсален (Никон и Канон хранят в нем RAW) и само изображение или несколько изображений в формате, предлагаемом, например, вот здесь.
Прошу прощения, Bef и сопутствующие форматы нормально описаны на их старом ресурсе, а на новом оставили только маркетинговую пургу.
Спасибо за ссылку, ознакомился с форматом. Не впечатлил. В сравнении с HDR или Open EXR, конечно, выглядит получше, но с тем же FJPEG, упомянутом в статье выглядит довольно громоздким. Я бы назвал его продвинутым форматом для работы с HDR, но на роль формата для публикаций в Сети он (на мой взгляд) не тянет. К тому же HDR его единственная сильная сторона.
Работу с изображением можно разбить на несколько этапов:
-Получение изображения
-Хранение изображения
-Передача изображения
-Воспроизведение изображения
Для каждого этапа свои особенности и требования, поэтому, по-хорошему, нужен свой способ (формат) представления изображения для каждого этапа.
Bef разрабатывался как формат хранения сжатого изображения в режимах lossless или visual lossless, а, в комплекте с Def и Bch, становился удобным для применения различных алгоритмов обработки изображения (изменение яркости/контрастности, ресайза и т. д.).
-Получение изображения
-Хранение изображения
-Передача изображения
-Воспроизведение изображения
Для каждого этапа свои особенности и требования, поэтому, по-хорошему, нужен свой способ (формат) представления изображения для каждого этапа.
Bef разрабатывался как формат хранения сжатого изображения в режимах lossless или visual lossless, а, в комплекте с Def и Bch, становился удобным для применения различных алгоритмов обработки изображения (изменение яркости/контрастности, ресайза и т. д.).
В результате всех этих расширений получится что-то типа swf. А что, в нём уже можно реализовать большую часть «хотелок», есть анимация, и альфа, можно внедрить поясняющие метки и ссылки, можно сделать разную плотность пикселей и совместить растр и вектор. Есть внедрённые шрифты. Более того, это будет работать уже сейчас, и даже во многих браузерах. Но — это не формат изображения, а уже целое приложение. Хотя тут и есть определённая неопределённость границ.
Согласен с Вами. Так оно и есть. Однако на чём бы я хотел заострить внимание. Когда не было GIF'а и JPEG'а большинство и не думало, что такие возможности, как малый размер, анимация или теги EXIF будут доступны. Однако сейчас мы ими пользуемся. Я думаю, надеюсь, что лет через 10-20 многое из того что я написал будет доступно прямо из коробки, т.е. фотоаппараты будут настолько умны, что сделают сами панорамный стерео снимок, построют карту глубины, распознают какие объекты находятся в кадре и сделают на них ссылки и сожмут изображение так, чтобы по-возможности не потерять именно главных деталей (надписей, лиц и т.д.). Нужно думать об этом уже сейчас, чтобы получить это в будущем.
а как же старый добрый формат PICT (сейчас уже сгинувший), но в свое время произведший на меня огромное впечатление хранением в одном файле и векторных и растровых данных (с любой глубиной цвета и\или анимацией) и даже текстовых блоков и звуковых комментариев
оффтоп
bat — это не формат вообще. В крайнем случае это просто текст (Пишу не в личку, а то вдруг для кого тоже открытием станет). А вообще понятие «формат» достаточно расплывчатое.
Отчего же? Тогда и HTML и XML тоже не форматы?
Как я уже упомянул: понятие формата растяжимо. Лично для меня любой читаемый текст — будь то html, java, cpp — это просто текст (не требующий специфичных преобразований для читаемого отображения). Всё остальное есть бинарные данные, сформированные по определённому формату: заголовок файла, паддинг, секции и т.д.
Я понимаю, что текстовые файлы тоже могут быть составлены по определённым правилам (формату, если хотите). Но это другой формат — на другом уровне абстракции.
Ну понятию 'формат' можно дать вполне конкретное определение — набор правил по отношению к данным. Какие -то форматы могут являться подмножеством другого формата, например, формат 'дата', являясь текстовым форматом, еще описывает его ограничения в виде '##.##.####'.
У вас же почему-то все текстовые форматы обобщились, а различные форматы имеют только бинарные данные.
Другой вопрос, является ли данный формат форматом изображения, если в нем уже можно хранить звуки, кусочки видео в место анимации и простенькие скрипты для интерактивности? Или же это уже формат медиаприложения. Ведь по сути вы предлагаете использовать тот же алгоритм JPEG, просто упакованный в другой контейнер.
У вас же почему-то все текстовые форматы обобщились, а различные форматы имеют только бинарные данные.
Другой вопрос, является ли данный формат форматом изображения, если в нем уже можно хранить звуки, кусочки видео в место анимации и простенькие скрипты для интерактивности? Или же это уже формат медиаприложения. Ведь по сути вы предлагаете использовать тот же алгоритм JPEG, просто упакованный в другой контейнер.
Не совсем так. Я предлагаю хранить в одном файле в основном одно изображение (если не считать стерео и слои). Плюс хранить текстовую информацию (ссылки, подписи, ссылки на изображения, звук и видео), но сами медиа-файлы — это отдельные файлы. Что же касается конкретно моих предложений именно по графическому формату, то это поддержка FJPEG и переменная плотность пикселей (моё ноу-хау). Что то никто не затрагивает этот вопрос, а для меня лично он крайне интересен. Кроме того я нигде не видел и не слышал об идее использовать такие качества как видимое изображение, изображения в УФ или ИК или буфер глубины в одном файле. А тем не менее, если бы был такой формат, пусть даже основанный на JPEG это несколько изменило бы возможности отображения фотографий. Например, вместо курсора мыши был бы человечек, причём его размер был бы пропорционален расстоянию до точки под курсором.
Не знаю, почему вы решили, что переменное разрешение изображения — ваше «ноу-хау» — публикации по этой теме были еще в 1995м году.
Если вы чего-то не видели, то это не значит, что этого нет. В задачах геоинформатики вовсю используются многоканальные снимки (хранящиеся в GeoTIFF или HDF-EOS), которые могут содержать изображения одновременно в видимом и инфракрасном диапазоне, а также, при желании, и карту высот поверхности.
Если вы чего-то не видели, то это не значит, что этого нет. В задачах геоинформатики вовсю используются многоканальные снимки (хранящиеся в GeoTIFF или HDF-EOS), которые могут содержать изображения одновременно в видимом и инфракрасном диапазоне, а также, при желании, и карту высот поверхности.
Не знаком с такими публикациями. Был бы благодарен за ссылку. Насчёт того что я что то не знаю — это верно. Однако Вы видимо не до конца понимаете о чём я писал в статье. Всё о чём я писал где то было и есть — по отдельности. И очень часто в научных проектах (тот же Ваш HDF-EOS). Я же сторонник того чтобы эти качества были доступны в бытовых приборах и форматах.
Публикации находятся по ключевым словам «variable resolution image», например.
Для того, чтобы какие-то возможности были доступны в «бытовых приборах», нужны не новые форматы (изобретение велосипеда), а поддержка существующих форматов.
Приведу вам яркий пример. Есть всем известный способ сжатия видео MPEG. У него есть некоторое количество вариантов, которые различаются способом кодирования, частотой кадров, способом представления цвета. Возможности устройств с поддержкой MPEG-кодирования плавно и постепенно, следуя за растущей производительностью, перемещаются из профессиональной и узкоспециальной сферы в область бытовых устройств. Еще единицы лет назад запись видео в full HD разрешении и с цветовой передискретизацией 4:2:2 была возможностью исключительно профессионального оборудования. Сейчас — уже нет. Потому что формат — один, различаются только его опции. Собрали инженеры новую камеру с более мощным процессором, изменили программисты firmware пару констант в настройках кодера, и вот вам «качества, доступные в бытовых приборах».
То, что в данный момент какой-то формат хранения данных используется только в научном применении (но используется), не делает его хуже ни на грамм, а только лучше (из-за уже существующих библиотек, которые его поддерживают). Программный код кодеров и декодеров — безличен, на нем не стоит штамп «использовать только в науке».
А если нагородить для этого какой-то новый формат, о котором никто не слышал, то в массовый продукт он точно не попадет.
Для того, чтобы какие-то возможности были доступны в «бытовых приборах», нужны не новые форматы (изобретение велосипеда), а поддержка существующих форматов.
Приведу вам яркий пример. Есть всем известный способ сжатия видео MPEG. У него есть некоторое количество вариантов, которые различаются способом кодирования, частотой кадров, способом представления цвета. Возможности устройств с поддержкой MPEG-кодирования плавно и постепенно, следуя за растущей производительностью, перемещаются из профессиональной и узкоспециальной сферы в область бытовых устройств. Еще единицы лет назад запись видео в full HD разрешении и с цветовой передискретизацией 4:2:2 была возможностью исключительно профессионального оборудования. Сейчас — уже нет. Потому что формат — один, различаются только его опции. Собрали инженеры новую камеру с более мощным процессором, изменили программисты firmware пару констант в настройках кодера, и вот вам «качества, доступные в бытовых приборах».
То, что в данный момент какой-то формат хранения данных используется только в научном применении (но используется), не делает его хуже ни на грамм, а только лучше (из-за уже существующих библиотек, которые его поддерживают). Программный код кодеров и декодеров — безличен, на нем не стоит штамп «использовать только в науке».
А если нагородить для этого какой-то новый формат, о котором никто не слышал, то в массовый продукт он точно не попадет.
Нет, не форматы. Это языки разметки (текста — в случае HTML и данных вообще — в случае XML).
Когда речь идет о языках, термин «формат» употребляется только в обобщенном смысле, в фразах вроде такой: «Данные могут быть представлены в форматах DBF, CSV, XML»
Когда речь идет о языках, термин «формат» употребляется только в обобщенном смысле, в фразах вроде такой: «Данные могут быть представлены в форматах DBF, CSV, XML»
В статье упомянули о стереофото, вот как его можно смотреть без очков, специальных мониторов и т.п., может кого-то заинтересует…
Таблица в начале статьи отчасти неверна, так как PNG умеет и анимацию (APNG) и добавление метаданных.
Всегда хотелось чтобы был формат с прозрачностью как у пнг и сжатием как у джпг, очень бы пригодилось многим «криворуким сайтописателям», которые пихают в дизайн пнг-шки размером 3-5мб О_о
WebP?
ru.wikipedia.org/wiki/WebP не пишут ни слова о прозрачности… она точно там есть?
Посмотрите английскую, там сказано, что поддерживает. Или вот.
А ещё есть JNG (можно рассматривать как подмножество MNG).
Но ни webp, ни mng/jng не поддерживаются большинством браузеров. webp преимущество только в том, что его поддерживает достаточно распространённый Chrome.
А ещё есть JNG (можно рассматривать как подмножество MNG).
Но ни webp, ни mng/jng не поддерживаются большинством браузеров. webp преимущество только в том, что его поддерживает достаточно распространённый Chrome.
WebP постоянно развивает сейчас Гугл, поэтому и устаревшая информация. WebP поддерживает сжатие с потерями и прозрачностью, сжатие без потерь, анимацию и другое…
Вы поставили всё с ног на голову.
Форматов для хранения чего угодно сейчас достаточно (и, к слову, не надо загонять их в рамки весьма сомнительной классификации по назначению). Сами служебные структуры того же TIFF достаточно скромны по объему, если сравнивать их с тем содержимым, которое в нем хранится. И он не имеет какого-либо особого «предназначения». Уже сейчас в TIFF можно положить что угодно, например, HDR-изображение с плавающей точкой; LDR-thumbnail, сжатый LZW; полноразмерное цветное LDR- изображение, сжатое JPEG2000 без потерь; карту глубины в восьмибитном bitmap-е и для полной радости — векторный контур какого-нибудь объекта в сцене. Расходы объема на описание и разделение этих секций будут мизерными, если сравнивать их с самими данными.
Проблема в поддержке этих самых форматов, а не в том, что нужен еще какой-то новый формат. Исторически сложилось, что в browser-ах поддерживался тот набор, который есть сейчас, вот и всё. А изобретать велосипед, в данном случае, бессмысленно.
Форматов для хранения чего угодно сейчас достаточно (и, к слову, не надо загонять их в рамки весьма сомнительной классификации по назначению). Сами служебные структуры того же TIFF достаточно скромны по объему, если сравнивать их с тем содержимым, которое в нем хранится. И он не имеет какого-либо особого «предназначения». Уже сейчас в TIFF можно положить что угодно, например, HDR-изображение с плавающей точкой; LDR-thumbnail, сжатый LZW; полноразмерное цветное LDR- изображение, сжатое JPEG2000 без потерь; карту глубины в восьмибитном bitmap-е и для полной радости — векторный контур какого-нибудь объекта в сцене. Расходы объема на описание и разделение этих секций будут мизерными, если сравнивать их с самими данными.
Проблема в поддержке этих самых форматов, а не в том, что нужен еще какой-то новый формат. Исторически сложилось, что в browser-ах поддерживался тот набор, который есть сейчас, вот и всё. А изобретать велосипед, в данном случае, бессмысленно.
Напротив, я считаю что в этом есть очень даже большой смысл. Служебные структуры малы и что? Это достоинство? А кто мешает сделать формат с еще более экономными служебными структурами? Формат TIFF имеет предназначение для обработки, вёрстки, дизайна. Он слишком сложный, полная поддержка его слишком дорого обходится программисту. А то, что он может инкапсулировать JPEG или другие форматы, на мой взгляд, не является никаким достоинством. Ибо их то поддержку всё равно придётся реализовывать.
Вы об этом и сами пишите, собственно должны понимать, что проще создание нового неразбухшего формата, с новыми эффективными алгоритмами, но не на все случаи жизни (издательство, обработка или публикация в Сети), а для конкретных задач. Именно благодаря таким ограничениям до сих пор живы JPEG и GIF или, например, MP3. В то же время универсалы (см. посты выше про PNG, JNG, MNG) сидят на скамейке запасных.
Но время идёт, сейчас нужны новые форматы, с поддержкой новых свойств и я думаю, мы скоро их увидим.
Вы об этом и сами пишите, собственно должны понимать, что проще создание нового неразбухшего формата, с новыми эффективными алгоритмами, но не на все случаи жизни (издательство, обработка или публикация в Сети), а для конкретных задач. Именно благодаря таким ограничениям до сих пор живы JPEG и GIF или, например, MP3. В то же время универсалы (см. посты выше про PNG, JNG, MNG) сидят на скамейке запасных.
Но время идёт, сейчас нужны новые форматы, с поддержкой новых свойств и я думаю, мы скоро их увидим.
Вы зациклились на «предназначениях». А их не существует в каком-то строгом виде.
А про устройство web у вас вообще очень странные представления. Доля PNG по сравнению с GIF очень велика и постепенно растет — тормозила этот процесс только ситуация с IE.
А JNG, MNG и прочее — это как раз примеры того, что кто-то, подобно вам, пытался изобрести велосипед, только «чуть лучше прежнего».
А про устройство web у вас вообще очень странные представления. Доля PNG по сравнению с GIF очень велика и постепенно растет — тормозила этот процесс только ситуация с IE.
А JNG, MNG и прочее — это как раз примеры того, что кто-то, подобно вам, пытался изобрести велосипед, только «чуть лучше прежнего».
Уважаемый, скорее это Вы зациклились на TIFF'е. Если кто то их (предназначений) не видит, то это не моя проблема. Просто для многих это очевидно. Никто не публикует статьи с изображениями в формате BMP, никто не вставляет на сайт логотипы в формате HDR, ну или может я не те сайты посещаю. Что касается PNG, то это очень и очень противный формат, говорю Вам как профессиональный фотограф, специализирующийся на создании виртуальных туров с видео вставками. Смотри комментарии пользователя ZweiAndersdenkenden выше. А то что кто то, даже не обязательно я, пытается изобрести велосипед, то это очень хорошо, благодаря таким людям и происходит движение вперёд.
«Противный формат» — это просто шедевр аргументации. Если какой-то криворукий школьник-верстальщик не знает, для чего он, то это его проблемы, а не формата. В чём вы еще предлагаете хранить графические элементы оформления веб-страницы с восьмибитным цветом и восьмибитным каналом прозрачности? И ваша квалификация профессионального фотографа тут совершенно не при чем, да и вы ее уже продемонстрировали своим userpic-ом:
— прозрачность потерялась по дороге, при конвертировании в JPEG? А использовали бы PNG, такой проблемы бы не было.
— прозрачность потерялась по дороге, при конвертировании в JPEG? А использовали бы PNG, такой проблемы бы не было.
Насчёт шедевра — пожалуйста! Насчёт криворукого — спасибо! Я человек не обидчивый, но если мне в упор говорят обидные слова, пытаясь аргументировать детскими фразами, я иногда обижаюсь. Что касается Вашего
«В чём вы еще предлагаете хранить графические элементы оформления веб-страницы с восьмибитным цветом и восьмибитным каналом прозрачности?»
то перечитаете статью, может Вы постите на совсем другую тему?
А насчёт моей квалификации, то Вы мне просо льстите. Если Ваш банный лист — это шедевр Ренессанса то я умолкаю.
«В чём вы еще предлагаете хранить графические элементы оформления веб-страницы с восьмибитным цветом и восьмибитным каналом прозрачности?»
то перечитаете статью, может Вы постите на совсем другую тему?
А насчёт моей квалификации, то Вы мне просо льстите. Если Ваш банный лист — это шедевр Ренессанса то я умолкаю.
Вы невнимательно читали или все же обижаетесь.
«Криворукий школьник-верстальщик» — это тот, кто бездумно использует только PNG и у которого, по выражению ZweiAndersdenkenden, получаются PNG по 3-5 Мб. Что не мешает другим успешно использовать правильно возможности этого формата.
Детская фраза про «противный формат» получилась у вас, а не у меня, вы ее сами написали.
Статью я читал, но она не содержит ни одного внятного аргумента, почему новый формат должен решить все те проблемы (часть из которых лежит в области отсутствия должной квалификации разработчиков) и почему конкретно все существующие форматы плохи. С числами, сравнением возможностей, сравнением поддержки разными программными средствами. Без этого аргументация о мифическом предназначении — пустословие.
На то, что мой банный лист — шедевр, я не претендую ни коим образом, но он, объективно, нормально отображается на любом фоне, тогда как у вашего userpic с этим очевидные проблемы, связанные, очевидно, с вашей фанатичной (то есть не имеющей под собой объективных аргументов) ненависти к формату PNG и верой в то, что эти проблемы могут быть решены только чем-то таким, о чем вы пишете в статье.
В подобную фанатичность легко поверить, глядя даже на вашу манеру обращения — нарочитое «Вы», употребляемое упорно против существующих правил (общение в сети в форме комментариев не является личной перепиской, адресованной непосредственно кому-то), хорошо коррелирует, например, с руководящим принципом «все не в ногу, один я в ногу».
«Криворукий школьник-верстальщик» — это тот, кто бездумно использует только PNG и у которого, по выражению ZweiAndersdenkenden, получаются PNG по 3-5 Мб. Что не мешает другим успешно использовать правильно возможности этого формата.
Детская фраза про «противный формат» получилась у вас, а не у меня, вы ее сами написали.
Статью я читал, но она не содержит ни одного внятного аргумента, почему новый формат должен решить все те проблемы (часть из которых лежит в области отсутствия должной квалификации разработчиков) и почему конкретно все существующие форматы плохи. С числами, сравнением возможностей, сравнением поддержки разными программными средствами. Без этого аргументация о мифическом предназначении — пустословие.
На то, что мой банный лист — шедевр, я не претендую ни коим образом, но он, объективно, нормально отображается на любом фоне, тогда как у вашего userpic с этим очевидные проблемы, связанные, очевидно, с вашей фанатичной (то есть не имеющей под собой объективных аргументов) ненависти к формату PNG и верой в то, что эти проблемы могут быть решены только чем-то таким, о чем вы пишете в статье.
В подобную фанатичность легко поверить, глядя даже на вашу манеру обращения — нарочитое «Вы», употребляемое упорно против существующих правил (общение в сети в форме комментариев не является личной перепиской, адресованной непосредственно кому-то), хорошо коррелирует, например, с руководящим принципом «все не в ногу, один я в ногу».
Я недавно открыл для себя формат webp. Отличная штука, которая экономит много места, если нужна прозрачность в картинке. Благо библиотеки на с++ есть для его чтения.
Будущее цифровой фотографии, как мне кажется и по крайней мере, в массовом бытовом сегменте — видеосъемка со сверхвысоким разрешением.
Уже сейчас FullHD — кадры 2 мегапикселя, 10-15 лет назад кадры ФОТОграфий были меньше.
Ну и куча возможностей — хочешь, почувствуй атмосферу ситуации с видео, хочешь — рассматривай детали на любом кадре и печатай, хочешь — реконструируй сцену в 3D.
Уже сейчас FullHD — кадры 2 мегапикселя, 10-15 лет назад кадры ФОТОграфий были меньше.
Ну и куча возможностей — хочешь, почувствуй атмосферу ситуации с видео, хочешь — рассматривай детали на любом кадре и печатай, хочешь — реконструируй сцену в 3D.
Sign up to leave a comment.
Будущее цифровой фотографии