abbra: (Default)
Бойцы из НезлойИмперии пытаются родить новый формат изображений, WebP. За основу взят кодек VP8 и контейнер RIFF. Желание поскорее использовать VP8 для замены JPEG так велико, что бойцы совсем забыли вторую важную часть любого внятного формата изображений: хранение мета-данных. Я даже могу представить, что ими двигало: предложенные четыре блока мета-данных ICMT, ICOP, IART, INAM без какой-либо спецификации содержимого (кодировка, ожидания по структуре, ...) явно базируются на аналогичных блоках из спецификации PNG.

Если посмотреть на проблему серьезнее, то EXIF+IPTC+XMP сегодня описывают порядка нескольких сотен тегов. Если для каждого из них выделять отдельный блок в контейнере, указывать точные структуры хранения и кодирования, то загнутся реализаторы, а формат просто никто не будет внятно поддерживать.

Игнорирование мета-данных в изображениях в данном контексте отражает общий подход клиентской стороны гугловцев. Лишь относительно недавно в Picasa появилась полноценная поддержка XMP. Параллельного слияния тегов из разных контейнеров у них нет до сих пор (например, title/description могут храниться во всех трех указанных выше типах хранилищ мета-данных в одном изображении -- что делать, если пользователь хочет изменить title, какое из хранилищ будет приоритетным, как изменить данные в остальных?). Теперь Хром хочет ускориться за счет уменьшения объема перекачиваемых данных (это единственная фича, которую объявляют стоящей для себя разработчики WebP). Для браузеров мета-данные в изображениях бесполезны, API доступа к таким данным в рамках спецификаций W3C просто отсутствуют. Вот и рождается очередной контейнер-недоконтейнер. WebM, кстати, тоже поддержку мета-данных зажилил.
abbra: (Default)
Бойцы из НезлойИмперии пытаются родить новый формат изображений, WebP. За основу взят кодек VP8 и контейнер RIFF. Желание поскорее использовать VP8 для замены JPEG так велико, что бойцы совсем забыли вторую важную часть любого внятного формата изображений: хранение мета-данных. Я даже могу представить, что ими двигало: предложенные четыре блока мета-данных ICMT, ICOP, IART, INAM без какой-либо спецификации содержимого (кодировка, ожидания по структуре, ...) явно базируются на аналогичных блоках из спецификации PNG.

Если посмотреть на проблему серьезнее, то EXIF+IPTC+XMP сегодня описывают порядка нескольких сотен тегов. Если для каждого из них выделять отдельный блок в контейнере, указывать точные структуры хранения и кодирования, то загнутся реализаторы, а формат просто никто не будет внятно поддерживать.

Игнорирование мета-данных в изображениях в данном контексте отражает общий подход клиентской стороны гугловцев. Лишь относительно недавно в Picasa появилась полноценная поддержка XMP. Параллельного слияния тегов из разных контейнеров у них нет до сих пор (например, title/description могут храниться во всех трех указанных выше типах хранилищ мета-данных в одном изображении -- что делать, если пользователь хочет изменить title, какое из хранилищ будет приоритетным, как изменить данные в остальных?). Теперь Хром хочет ускориться за счет уменьшения объема перекачиваемых данных (это единственная фича, которую объявляют стоящей для себя разработчики WebP). Для браузеров мета-данные в изображениях бесполезны, API доступа к таким данным в рамках спецификаций W3C просто отсутствуют. Вот и рождается очередной контейнер-недоконтейнер. WebM, кстати, тоже поддержку мета-данных зажилил.
abbra: (Default)
Статья во вчерашней International Herald Tribune, посвященная FLAC: http://www.iht.com/articles/2007/09/05/business/ptend06.php
Довольно неплохая статья для мейнстримовой прессы, освещающая проблематику сжатия музыки без потерь на примере свободных алгоритмов, форматов и ПО.
abbra: (Default)
Статья во вчерашней International Herald Tribune, посвященная FLAC: http://www.iht.com/articles/2007/09/05/business/ptend06.php
Довольно неплохая статья для мейнстримовой прессы, освещающая проблематику сжатия музыки без потерь на примере свободных алгоритмов, форматов и ПО.

April 2016

S M T W T F S
     12
3456789
1011121314 1516
17181920212223
24252627282930

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 22nd, 2025 09:34 am
Powered by Dreamwidth Studios