Развивается новый формат сжатия изображений FLIF (http://flif.info/) (Free Losless Image Format), опережающий по уровняю сжатия PNG и lossless-режимы форматов BPG (https://www.opennet.dev/opennews/art.shtml?num=41198), JPEG2000 и WebP (https://www.opennet.dev/opennews/art.shtml?num=36563). Исходные тексты утилит и библиотеки для работы с форматом FLIF доступны (https://github.com/jonsneyers/FLIF) под лицензией GPLv3. Заложенные в формат технологии распространяются на условиях безвозмездного использования и не требуют патентных отчислений.
В основе FLIF лежит статистический алгоритм контекстно-адаптивного двоичного арифметического кодирования MANIAC (Meta-Adaptive Near-zero Integer Arithmetic Coding), который является одним из вариантов алгоритма CABAC (https://ru.wikipedia.org/wiki/CABAC) (Context-Adaptive Binary Arithmetic Coding), также используемого при кодировании видео H.264. Во FLIF поддерживается прогрессивное чересстрочное кодирование (progressive interlacing), позволяющее отобразить эскиз изображение на основании части данных, постепенно увеличивая качество по мере загрузки. Любой загруженный начальный блок сжатого файла может быть использован как закодированное с потерями изображение, сопоставимое (http://flif.info/example.php) по качеству с обычными форматами кодирования с потерями. Последующие данные уточняют модель и доводят её до представления полностью аналогичного исходному варианту.
<center><iframe width="640" height="360" src="https://www.youtube.com/embed/ByH7RMsMxBY?rel=0" frameborder="0" allowfullscreen></iframe></center>
По уровню сжатия FLIF, при тестировании на коллекции разнородных изображений (использовались тесты WebP (https://developers.google.com/speed/webp/docs/webp_lossless_... в среднем на 35% превосходит PNG (для оптимизированных PNG на 26%), на 37% JPEG 2000, на 15% WebP и на 22% BPG. Формат FLIF хорошо справляется с различными видами изображений, не требуя дополнительного тюнинга параметров кодирования. Например, для специфичных видов изображений (BPG и JPEG 2000 оптимальны для медицинских фотографии, PNG для штриховых рисунков, PNG и WebP для карт и т.п.) FLIF также опережает (https://docs.google.com/spreadsheets/d/16ghJEjf_T7TDTOg2Wlel... конкурентов в среднем на 10%. По скорости кодирования и декодирования текущая реализация FLIF пока отстаёт от других форматов.<center><a href="http://flif.info/comparison.png"><img src="https://www.opennet.dev/opennews/pics_base/0_1443769211.png&q... style="border-style: solid; border-color: #606060; border-width: 1px;max-width:100%;" title="" border=0></a></center>
Из возможностей FLIF можно отметить поддержку прозрачности, анимации, глубину цвета в 16 бит на канал, режим очень быстрого декодирования в пониженном разрешении. В планах возможность интеграции метаданных (EXIF, профили ICC profiles, XMP), поддержка цветовых пространств (CMYK, YCbCr), режим сжатия с потерями, обеспечение поддержки в web-браузерах и оптимизация производительности.
URL: https://github.com/jonsneyers/FLIF
Новость: http://www.opennet.dev/opennews/art.shtml?num=43074
Можно увеличить место на винте, пожав картинки.
Проблема то актуальная. Популярная картинка может генерировать терабайты трафика.
http://i.imgur.com/wU8sdky.png?1
Оно то да.
А вот где используется в реальной жизни картинка без сжатия?
Если звук без жатия еще имеет какую-то нишу, то картинка, только в виде raw для специалистов по фотографии. Я думаю, они не будут для экономии места пережимать в FLIF ибо это время, и нужно только для бекапа...
Это скорее всего узкая ниша типа медецины, геодезии и всяких военных направлений, где важнее достоверность, чем объем...
>> Это скорее всего узкая ниша типа медецины, геодезии и всяких военных направлений, где важнее достоверность, чем объем...Одного это уже на годы вперед хватит. :)
>>> Это скорее всего узкая ниша типа медецины, геодезии и всяких военных направлений, где важнее достоверность, чем объем...
> Одного это уже на годы вперед хватит. :)Оно то так, но почему-то все пользуют ogg, mp3, jpeg, png... Про видео вообще молчу.
Это массовое решение.
Некоторые пользуют flac и иже с ними. Для личного пользования. Их процент малый. Про картинки - в основном только RAW.Железа (фотоаппарат, сканер, звукозапись), которое сразу пишет в flac или другой алгоритм сжатия без потерь (картинка, звук и т.д.) я что-то не припоминаю.
Софта который активно с такими форматами без перекодировки работает(позволяет их изменять, обрабатывать) тоже малова-то. В основном только конечное пользование: просмотр, прослушивание...Надеемся, что терабайтная флешка через 5 лет станет так же популярна как 10 лет назад мегабайтная. А процессоры в бытовом железе будут на лету жать в эти форматы лучше чем джепег или огг. Тогда это станет нормой.
ПиСя: Кстати жаль нет сравнения сжатия относительно xz.
тестанул XZ:$ls -l P9172593.*
--- 3818620 P9172593.JPG
--- 23971389 P9172593.tif$ xz P9172593.tif
ls -l P*
--- 3818620 P9172593.JPG
--- 13791152 P9172593.tif.xzнеплохо пожало тиффку сделаную из джепега, почти в два раза.
оригинальной raw-картинки жалко нет под рукой.
Но жало несколько секунд на двухядерном ноутбуке(похоже одно ядро только работало)
Разжимало быстрее. секунду где-то.
xz однопоточный. если надо использовать несколько ядер есть pxz, архив итоговый получается такой же, а время сокращает сильно (я бекапы теперь так и делаю), tar тоже может его понимать как параметр для архивации.
> xz однопоточный. если надо использовать несколько ядер есть pxz, архив итоговый получается
> такой же, а время сокращает сильно (я бекапы теперь так и
> делаю), tar тоже может его понимать как параметр для архивации.вау. буду знать. полезность. про tar я знал...
> если надо использовать несколько ядер есть pxz, архив итоговый получается такой жеПомнится, автор писал, что всё-таки чуть толще, но обычно ненамного.
из man xz:-T threads, --threads=threads
Specify the number of worker threads to use. Setting threads to a special value 0 makes xz use as many threads as there are CPU cores on the system. The actual number of
threads can be less than threads if the input file is not big enough for threading with the given settings or if using more threads would exceed the memory usage limit.Currently the only threading method is to split the input into blocks and compress them independently from each other. The default block size depends on the compression
level and can be overriden with the --block-size=size option.Threaded decompression hasn't been implemented yet. It will only work on files that contain multiple blocks with size information in block headers. All files compressed in
multi-threaded mode meet this condition, but files compressed in single-threaded mode don't even if --block-size=size is used.
> Железа (фотоаппарат, сканер, звукозапись), которое сразу пишет в flac или другой алгоритм сжатия без потерь (картинка, звук и т.д.) я что-то не припоминаю.Звуковые платы и сканеры выдают поток без сжатия. Плееры с rockbox'ом тоже могут писать без сжатия. Хорошие фотоаппараты выдают - raw или tiff.
> Софта который активно с такими форматами без перекодировки работает(позволяет их изменять, обрабатывать) тоже малова-то. В основном только конечное пользование: просмотр, прослушивание...
gimp/audacity/avidemux/blender и весь остальной софт, ориентированный на создание и обработку мультимедиа. Многие 3d-шники рендерят анимацию как серию png, так как это самый переносимый способ получения видео без сжатия с альфа каналом.
> Оно то так, но почему-то все пользуют ogg, mp3, jpeg, png... ПроСам PNG перечислил.
>> Оно то так, но почему-то все пользуют ogg, mp3, jpeg, png... Про
> Сам PNG перечислил.Ах, без _сжатия_, а не без _потерь_… Ну, имелось в виду же пережать то, что не сжато с потерями.
>>Некоторые пользуют flac и иже с ними. Для личного пользования. Их процент малый.Фигню сморозил. Купи диск любимой группы и увидишь, что там будет lossless.
Вот только диски-то сейчас покупают разве что очень-меломаны, большинство же довольствуется мрЗ. И то некоторые меломаны предпочитают винил, а он, извините, lossy, потому что аналоговый.
наоборот :) это оцифровка аналога порождает ошибки и приближения..
man Теорема Котельникова.
Все звуки в мире аналоговые. Что теперь, на аудиокассеты писать? И как быть с тем, что записанное в 30-50 годы прошлого века (слушаю Джаз, лаундж и т.п.) на слух звучит заметно хреновей, хотя и писалось на супер-пупер аналог? Включаешь современную запись - как сидишь в студии рядом с группой. И глубина, и ширина... Правда души меньше, но это уже субъективно.
картографические архивы.. медицинские архивы.. поля распаханные давно, а тут новые тракторы.. где-то обязательно перейдут со временем.
Тут рулит и педалит JPEG2000, причем часто используется режим с потерями.
Чуваки просто не понимают, что когда разрешающая способность ниже, чем максимальные потери, то уже не важно будет сжатие или нет.Это как с бытовыми музыкальными проигрывателями и колонками/аудиокартами, качество которых зачастую недостаточно для воспроизведения flac, а покупатели не готовы платить за аппаратуру требуемого качества. Вот и получается, что flac это на 99% дешёвые по-ты.
flac — это возможность конвертации в любой формат с потерями по необходимости. я, например, использую исключительно ворбис, а качаю исключительно флаки. желающим делать ворбис из mp3 — привет.
Откройте для себя уже opus.
Или его в слаке до сих пор нет?
не проецируй: пользователи слаквари умеют собирать из исходных текстов.
> не проецируй: пользователи слаквари умеют собирать из исходных текстов.Уметь и делать отнюдь не одно и тоже. :-)
Предлагаете после замены аппаратуры выкинуть коллекцию и создавать заново? Плюс лосслесс позволяет не задумываться, достаточно ли хорошо сжатие - а то выяснить, ниже разрешающая способность или нет - задача нетривиальная.Хотя, что это я - клоуну отвечаю? А не пошёл бы он лучше в цирк, прыгать там по команде дрессировщика.
Ну да, ну да... А при покупке автомобиля нужен 5-тонный грузовик (ну а вдруг понадобиться), способный разгоняться до 300 км/ч (ну а вдруг). Чё, под каждую задачу свою машину создавать.
Ваша аналогия не совсем корректна, лучше подходит аналогия с гаражом: если в будущем есть большая вероятность покупки машины бОльших габаритов, чем та что уже есть, то лучше сразу построить гараж с запасом.А так согласен, нужно все выбирать исходя из задачи:
для плеера в шумных условиях - mp3/vorbis 192-320kbps
для аудиокниг - 128kbps вполне хватает
для хорошей музыкальной коллекции - flac
> Ваша аналогия не совсем корректна, лучше подходит аналогия с гаражом: если в
> будущем есть большая вероятность покупки машины бОльших габаритов, чем та что
> уже есть, то лучше сразу построить гараж с запасом.
> А так согласен, нужно все выбирать исходя из задачи:
> для плеера в шумных условиях - mp3/vorbis 192-320kbps
> для аудиокниг - 128kbps вполне хватает
> для хорошей музыкальной коллекции - flacНе, кто бы спорил, что лучше быть здоровым и богатым, чем бедным и больным. Но у нас тут, в Сибири, 7000 руб на лишний 2Тб винт как бы играют роль. Это как бы 2 недели еды на 1го человека. Если экономить. Поэтому разницу в 320 мп3 и 800 кбит флак можно и не заметить, а вот пустое брюхо или синяк от жены - вполне )))
Ну и какбы на плеер замучаешься кидать, если надо по-быстрому скачанное забросить и побежать по-делам, а там вместо 300 Мб VBR будет 1.5 Гб... Так что для понтовозов и ценителей это. Я одинаково не люблю как ламповый др*ч, так и любителей hi-res stereo и прочих флаков, кабелей до колонок толщиной в руку с 99.999 чистотой меди. Делать нечего людям и деньги некуда девать ИМХО.
> Не, кто бы спорил, что лучше быть здоровым и богатым, чем бедным
> и больным. Но у нас тут, в Сибири, 7000 руб на
> лишний 2Тб винт как бы играют роль. Это как бы 2
> недели еды на 1го человека. Если экономить. Поэтому разницу в 320
> мп3 и 800 кбит флак можно и не заметить, а вот
> пустое брюхо или синяк от жены - вполне )))Тут стоит задуматься, а надо ли вам 2TB музыки? Во флаке это примерно 5500ч, если слушать даже по 8ч в сутки, то понадобится 687 дней, чтобы один раз все это послушать.
> Ну и какбы на плеер замучаешься кидать, если надо по-быстрому скачанное забросить
> и побежать по-делам, а там вместо 300 Мб VBR будет 1.5
> Гб...Я для таких целей использую mp3fs.
> Так что для понтовозов и ценителей это. Я одинаково не
> люблю как ламповый др*ч, так и любителей hi-res stereo и прочих
> флаков, кабелей до колонок толщиной в руку с 99.999 чистотой меди.
> Делать нечего людям и деньги некуда девать ИМХО.У каждого свои критерии качества звука. Но как не крути - нельзя выкинуть 75% информации и ничего при этом не потерять.
Flac еще интересен тем, что мало нагружает процессор (примерно в два раза меньше mp3), что может положительно сказаться на времени автономной работы.
> Тут стоит задуматься, а надо ли вам 2TB музыки? Во флаке это
> примерно 5500ч, если слушать даже по 8ч в сутки, то понадобится
> 687 дней, чтобы один раз все это послушать.одно из свойств музыки такое, что её не всегда есть желание слушать «подряд». и ещё одно — что захочется послушать, предсказать не всегда возможно. поэтому лично у меня копится довольно большой объём того, что я могу слушать раз в несколько лет — но, тем не менее, когда я захочу это послушать, желательно это иметь.
это я так, лирическое отступление написал.
> Flac еще интересен тем, что мало нагружает процессор
> (примерно в два раза меньше mp3), что может положительно
> сказаться на времени автономной работы.а вот это, кстати, немаловажно. а ворбис ещё больше ресурсов требует, чем mp3, насколько я помню.
> одно из свойств музыки такое, что её не всегда есть желание слушать
> «подряд». и ещё одно — что захочется послушать, предсказать не всегда
> возможно. поэтому лично у меня копится довольно большой объём того, что
> я могу слушать раз в несколько лет — но, тем не
> менее, когда я захочу это послушать, желательно это иметь.Согласен, но если в течении 5 лет такого желания не возникло, то можно удалять :)
У меня на данный момент 200GB музыки, большая часть - flac. 50% - потенциальные кандидаты на удаление. Музыку я очень люблю и дом проектирую с учетом архитектурной акустики (в будущем будет домашняя студия звукозаписи). Но музыки, которую интересно слушать больше пары раз, не так уж и много. Раньше собирал полные дискографии, затем стал оставлять только интересные альбомы, теперь не считаю святотатством удаление неинтересных треков с альбома. Бывает что из всего творчества группы остается один-два трека.> а вот это, кстати, немаловажно.
Важно, но не всегда. Например у sansa zip/clip общее потребление по питанию падает только на 10-15%.
> а ворбис ещё больше ресурсов требует, чем
> mp3, насколько я помню.Да. А opus еще больше, но возможно он еще не полностью оптимизирован.
> Согласен, но если в течении 5 лет такого желания не возникло, то
> можно удалять :)не факт. я, например, Янку очень редко слушаю, но когда хочется — тут лучше, чтобы была под рукой, потому что совсем не то настроение, чтобы искать, качать…
> Но музыки, которую интересно слушать больше пары раз, не так уж
> и много. Раньше собирал полные дискографии, затем стал оставлять только интересные
> альбомы, теперь не считаю святотатством удаление неинтересных треков с альбома. Бывает
> что из всего творчества группы остается один-два трека.я пока что держу дискографии — в основном потому, что обычно не хватает терпения прослушать все альбомы и оставить только самые интересные. :-) с другой стороны, я сейчас и музыки‐то качаю совсем немного: как оказалось, я собрал вполне достаточно, чтобы найти в коллекции что‐нибудь на любое настроение. благо, это не современные видеоигры, можно переслушивать много раз совершенно без потери удовольствия.
> Да. А opus еще больше, но возможно он еще не полностью оптимизирован.
к счастью, в опусе музыки ещё не видел. а вот в ворбис кодирую, потому что по идеологическим причинам не люблю mp3.
> к счастью, в опусе музыки ещё не видел. а вот в ворбис
> кодирую, потому что по идеологическим причинам не люблю mp3.У opus сжатие еще сильнее, чем у vorbis. С открытостью тоже вроде все в порядке.
Его минусы - больше грузит проц и меньше распространенность/поддержка.
> У opus сжатие еще сильнее, чем у vorbis.насколько помню, это компенсируется уменьшеным диапазоном. впрочем, могу ошибаться, давно любопытствовал.
> насколько помню, это компенсируется уменьшеным диапазоном. впрочем, могу ошибаться, давно
> любопытствовал.Нет, он субъективно звучит лучше, при одинаковом битрейте.
http://www.opus-codec.org/comparison/
http://listening-test.coresv.net/results.htm
спасибо.
> У каждого свои критерии качества звука. Но как не крути - нельзя
> выкинуть 75% информации и ничего при этом не потерять.
> Flac еще интересен тем, что мало нагружает процессор (примерно в два раза
> меньше mp3), что может положительно сказаться на времени автономной работы.Да ладно уж, 75% ))) Видел сравнение mp3 320 и flac. Перекодировали в wav и из одного вычли другое. Получились частоты выше 17 КГц. Вы слышите такое? Я нет. Если конечно врубить синус только 17 КГц на хорошей акустике, да громкость выкрутить раза в 2-3 больше обычной, то какой-то пиии и можно услышать. Но при обычном прослушивании высокие частоты кроме того что хуже "усваиваются" ухом, так ещё и маскируются более низкими, как например голос маскируется звуком проезжающего поезда. Поэтому те кто более-менее "шарит" понимают что в реальной музыке на средней громкости они выше 14 КГц не услышат. И некоторые даже довольствуются широкополосными динамиками, которые выше 14 не играют, зато вся остальная полоса более ровная. Но это лирика ))
У меня сейчас 212 Гб музыки. Если перевести во флак, будет Гб 600. Плюс бэккап, получаем 1.2 Тб. Плюс ещё на твердые носители надо это всё нарезать периодически, ну не доверяю я жестким дискам самое ценное ) Даже на двуслойках у меня много места это всё занимает, а тут в 3 раза больше...
> Да ладно уж, 75% ))) Видел сравнение mp3 320 и flac. Перекодировали
> в wav и из одного вычли другое. Получились частоты выше 17
> КГц.Не так все просто. mp3 320 меньше flac в 3-5 раз. 22kHz / 17kHz = 1.3 раза. Где все остальное? Да и даже их нельзя просто так срезать - в этот диапазон (18-22kHz) выносится шум, вызываемый борьбой с ошибкой округления (noise shaping).
> Вы слышите такое? Я нет. Если конечно врубить синус только
> 17 КГц на хорошей акустике, да громкость выкрутить раза в 2-3
> больше обычной, то какой-то пиии и можно услышать.Согласен - выше 16-17 kHz малозначимые детали (верхние обертона).
> Но при обычном
> прослушивании высокие частоты кроме того что хуже "усваиваются" ухом, так ещё
> и маскируются более низкими, как например голос маскируется звуком проезжающего поезда.Некорректный пример - у поезда и средние частоты громче голоса. Но согласен, эффект маскировки есть, но работает он иначе. Психоаккустика помогает выделить основные детали и второстепенные. Но это не значит, что можно пожертвовать второстепенным и никто этого не заметит. Все зависит от ситуации и что бы не гадать, а не потерял ли что-то любимый трек/альбом, проще хранить его во flac.
> Поэтому те кто более-менее "шарит" понимают что в реальной музыке на
> средней громкости они выше 14 КГц не услышат. И некоторые даже
> довольствуются широкополосными динамиками, которые выше 14 не играют, зато вся остальная
> полоса более ровная. Но это лирика ))Как любитель ШП, отмечу что полоса у них не ровная, больше подкупает относительная точечность излучения и высокая чувствительность.
> У меня сейчас 212 Гб музыки. Если перевести во флак, будет Гб
> 600. Плюс бэккап, получаем 1.2 Тб. Плюс ещё на твердые носители
> надо это всё нарезать периодически, ну не доверяю я жестким дискам
> самое ценное ) Даже на двуслойках у меня много места это
> всё занимает, а тут в 3 раза больше...Так может лучше удалить лишнее? В вашем случае это будет существенно эффективнее любого сжатия.
Да не найду я это всё во флаке, что за годы собрал, как раз удаляя лишнее. С местом-то нет проблемы. Просто поспорить чуток хотелось ))
Если разница в затратах между этим монстром и малолитражкой на двоих - копейки, то именно так и предлагаю.А впаривать кучу "вариантов", которые реально ничем не отличаются - это привычка ублюдков вроде Майкрософта с их версиями винды.
> картографические архивы.. медицинские архивы.. поля распаханные давно, а тут новые тракторы..
> где-то обязательно перейдут со временем.не, там или FIF, LWF или ECW или лютая проприетарь под которую плагины даже для GIMP и xnview полусырые(из 7 специфичных для медицины и 4 для космоса - только три поддерживаются). зато часть алгоритмов обработки из - заюзана в части фильтров )
> Проблема то актуальная. Популярная картинка может генерировать терабайты трафика.
> http://i.imgur.com/wU8sdky.png?1Открой для себя кэширующие прокси.
Нельзя просто так взять и "увеличить место на винте". Жесткий диск имеет заданную ёмкость. Можно лишь освободить ранее заданное место за счёт более эффективного сжатия файлов.Твой кеп.
Товарищ имел ввиду свободное место на винте. И мне любопытно, ты выпендриться решил, или просто тугой?
Надо стараться правильно излагать мысли, хоть некоторым это затруднительно.
Больше, больше стандартов!
где ты видишь слово "стандарт" в тексте новости?
Существование формата подразумевает наличие стандарта, описывающего этот формат.
> Больше, больше стандартов!Ещё 10 лет назад хомячки вроде тебя орали - даешь больше, больше выбора!
Каптча 01000 подверждает.
Очень неплохие результаты.
Хотелось бы сравнение FLIF с BPG.
Сравнение с BPG есть в новости, читайте внимательней
> Очень неплохие результаты.
> Хотелось бы сравнение FLIF с BPG.зависит от сжимаемого но от 1/5 до 1/4 выигрыша и от него, что СОлидно на мой взгляд. круче только античный FIF наверное в режиме с плавающей точкой и без ограничений по сложности и длительности кодирования, дефолтных(вэйвлетные алгоритмы - сильно пожиже хотя стастичные/однокадровые вариации dirac/shroedinger-а и покрытого мхом snow/nut-а - нехило и тут смотрятся)
... является одним из вариантов алгоритма КАБАК, хм, должно сработать!
Это не просто Кабак.
Это Маньяк на базе Кабака!
Маньяк вышедший из Кабака :)
Модератор, вычисли всех этих по IP и отправь в цирк.
Учитель наш Кун говорил: "Не пошутишь - и не весело".
был еще недавно imagezero формат
"Алгоритм маньяк, являющийся одним из вариантов алгоритма кабак"А еще говорят, что у кодеров нет чувства юмора
"Кодеры" имеют к разработке таких алгоритмов отношение чуть менее чем 0.
Это computer science, в России малоизвестное.
>Это computer science, в России малоизвестное.все с точностью до наоборот :)
т.е. кодек жмет без потерь лучше чем jpeg с потерями?
Но дольше!
Мне кажется, что уже пора вводить новый способ передачи мультимедийных данных от сервера к браузеру: если графический формат не поддерживается, то браузер запрашивает у сервера программу для декодирования.
И получает пару мегабайт малвари.
Браузеров не так уж и много. Можно завести репозиторий с подписанными кодеками, которые, при необходимости, скачивались автоматически.
Натурально, вы не понимаете. Если создатели браузеров хотят поддерживать форматы, то они поддерживают форматы, а если не хотят - то и все описанные вами странные телодвижения в браузере реализовывать никто не будет.
В репу могут добавлять независимые разрабы
В репу кто угодно может, а вот в браузер - нет.
Хороший вариант, но мне почему-то не нравится следующий шаг: "...и исполняет ее на компьютере пользователя, не зная, что она на самом деле делает".
Пустое предубеждение, конечно. Разве сервер, отдающий картинки, может прислать в ответ на такой запрос, что-то, кроме программы для декодирования?
Так браузер может ограничить возможности декодера: читать данные из полученного файла, выводить результат декодирования в строго заданный буфер и ничего больше.
А кофе принести, пока декодер работает, браузер не может?
Весь контроль, который есть у браузера над произвольным кодом, ограничивается управлением входом и выходом.
Ну,еоретически так обрезать декодер можно, а на практике - сначала хзахотят доступ к SSE, потом - к GPU, потом решат, что нужен DRM со взаимодействием с аппаратным чипом и дополнитльеными запросами в сеть... и так далее, и тому подобное.В сущности, то, что в браузере есть JS уже очень печально.
> Ну,еоретически так обрезать декодер можно, а на практике - сначала хзахотят доступ
> к SSE, потом - к GPU, потом решат, что нужен DRM
> со взаимодействием с аппаратным чипом и дополнитльеными запросами в сеть... и
> так далее, и тому подобное.ну да, ведь в браузер ещё не встроили «настоящую» виртуальную машину. без виртуальной машины, эмулирующей реальный процессор, браузер неполноценен, ящитаю.
Полагаю лучше бы сделали возможность указывать несколько файлов для одного изображения - варианты в разных форматах и разрешениях, а браузер сам определял в каком разрешении и формате ему удобнее.
Ты явно к ИТ отношения не имеешь... Думаешь кто-то будет пересохранять файлы, тратя время и место на диске, лишь чтобы какой-нибудь бородатый клоун, фанатеющий от своего извращённого понимания "свободы", мог получить файл в истинно-православно-халяльно-свободном формате?
srcset и <picture> это почти то же самое
Над этим уже постебались http://pepelsbey.net/pres/picture/
> Полагаю лучше бы сделали возможность указывать несколько файлов для одного изображения
> - варианты в разных форматах и разрешениях, а браузер сам определял
> в каком разрешении и формате ему удобнее.Собственно это есть даже в стандарте HTTP 1.0 - поле accept
Уже всё украдено. алгоритм декодирования на js, который можно получить из с через Emscripten. Так что проблем с отображением любых форматов нет, есть только проблемы со скоростью этого отображения.
Там даже скорость довольно неплохая, кстати. Но костыль же.
котики.jpeeg.exe?
Уже есть, только ссылка ведет на сайт производителя кодека - а ты уже решаешь - нужен ли он тебе.
> Исходные тексты утилит и библиотеки для работы с форматом FLIF доступны под лицензией GPLv3Не взлетит
>> Исходные тексты утилит и библиотеки для работы с форматом FLIF доступны под лицензией GPLv3
> Не взлетит«Заложенные в формат технологии распространяются на условиях безвозмездного использования и не требуют патентных отчислений.»
Иначе говоря, Вы можете реализовать алгоритм на любом языке под любой лицензией.
>> Исходные тексты утилит и библиотеки для работы с форматом FLIF доступны под лицензией GPLv3
> Не взлетитВзлетит
ещё один формат для облаков
Исходники соблазнительные, один файл всего. Не то что в Webp. А на bpg вообще страшно смотреть -- открываешь, а там libavcodec libavutil x265 треш угар и содомия.Картинка с котиками получилась больше оригинала -- 4.9М flif против 3.2М jpg. Нет, ну конечно меньше, чем 9.8М png, но мне и жпег обещали же!
Читаем внимательно"lossless-режимы форматов ... JPEG2000"
Ой, да. Простите, больше так не буду.
Если они собираются продвигать свой новый формат, то лицензия GPL 3 этому точно будет мешать.
> Если они собираются продвигать свой новый формат, то лицензия GPL 3 этому точно будет мешать.Вы тоже не различаете формат (алгоритм «на условиях безвозмездного использования и не требуют патентных отчислений») и код (реализацию GPL3)?
> Спецификации (алгоритма) нет.Может всё-таки будет… На официальном сайте:
«WARNING: FLIF is a work in progress. The format is not finalized yet.»
> внутреннего API ядраНу нет, ядро не из этого списка, потому что
https://www.kernel.org/doc/Documentation/stable_api_nonsense...
Т.е. никто и не обещает стабильный API в ядре.
> Что толку от таких спецификаций и стандартов? Дети решили поиграть во взрослых:
> придумывают стандарты, пишут спецификации.Стесняюсь спросить – а можно ссылочку на спеки NTFS?
Вот мы и пришли к вопросу что лучше: лекарство, срок годности которого ты не знаешь, или лекарство с просроченным сроком годности.На эту тему (дефицит информации VS недостоверная информация) шутил ещё Льюис Кэролл (автор Алисы в стране чудес): часы, которые стоят, показывают точное время чаще, чем часы, которые спешат на 5 минут.
> Вот мы и пришли к вопросу что лучше: лекарство, срок годности которого
> ты не знаешь, или лекарство с просроченным сроком годности.Т.е. конкретики типа ссылок на доки НТФС – не будет, а будет очередное жонглирование словами. Окай.
> На эту тему (дефицит информации VS недостоверная информация)
Ссылочку на "недостоверную информацию" можно? А то пока выходит "недостаточная/неполная документация некоторых проектов" VS. "индейское национальное жилище вам, а не спеки с доками или, тем более, сырцами!".
>фанатикам то свинина мешает, то DRMне знаю людей кому ДРМ бы не мешала
Нерепрезентативно.
Вот жаль, что ImageZero до ума не довели. Для всяких кэшей картинок в оперативке/на диске было бы в самый раз. Для браузеров, просмотрщиков PDF и подобного.
эх... салабоны...
Где же фрактальное сжатие? я в 90-х на дипломе сжимал круче чем джипег2000
Не отвлекайся, пиши дальше обработку на 1С.
Ну вот к тебе и вопрос тогда - где?
Сжимал.
А расжимал потом?
Придумать свой формат, который жмёт лучше существующего коммерческого - это типовой курсовой/дипломный проект.Лайфхак 1: сделать N вызовов существующих архиваторов с разными настройками, изменить расширение - БИНГО! Теперь можно писать об успехах:
- всех дрюкнул
- создаваемые ТВОИМ алгоритмом архивы совместимы с существующими unpack'ерамиЛайфхак 2. Просишь папу, друга, брата, свата и пр. подписать акт о внедрении. Проверяющие в восторге: у них внедрения в отдельной строке эффективности ВУЗа прописаны.
Т.е. я могу сжимать данные, и при этом не терять?
Именно. Я уже пережимаю JPEG и советую тебе сделать так же.
Я у себя локально пережал все png-шки без потерь с помщью RIOT. Поразило, что размер многих уменьшился аж вдвое. RIOT умеет урезать палитру (нафига, например, нужна труколор-палитра, если файл 256-цветный) и прогоняет получившееся через внешние подключаемые компрессоры типа optipng.
(вздыхает) ещё один. несмотря на интересные фичи… даже у гугеля с вебп не очень как‐то получилось.ой, reference на цпп. тьфу, гадость какая. а казался нормальным проектом.
Там очень понятные и по делу использованные плюсы. Не знаю, что тебе не так.
> Там очень понятные и по делу использованные плюсы. Не знаю, что тебе
> не так.плюсы не так. вот когда у плюсов хотя бы стандарты на манглинг, vmt, вызовы появятся — вот тогда можно будет на плюсах. когда я возьму собраную пять лет назад gcc3 плюсовую библиотеку, и спокойно слинкую с только что написаным плюсовым кодом, собраным gcc5.
мне не сам язык не нравится — хоть на суахили пусть делают, всё равно, — мне не нравится то, что линковка с c++ — это лишние проблемы за мои деньги, как говорится. так что пусть уносит своё поделие назад, и выносит реализацию на «стандартном» языке, то бишь си. или GTFO.
> Там очень понятные и по делу использованные плюсы. Не знаю, что тебе
> не так.а в остальном оно прикольное, конечно. особенно мне понравилась фича с недокачаной анимацией — такой точно ни у кого нет.
Losеless это хорошо, но чаще нужно сжать с потерями. И тут все конкуренты тихо сливаются по сравнению с Dejavu - он в пять раз уменьшает хорошие JPEG (высокого разрешения с фотоаппарата, стоковые фото и подобное). 20% от JPEG - с очень незначительной потерей качества.
>В основе FLIF лежит статистический алгоритм контекстно-адаптивного двоичного арифметического кодирования MANIAC (Meta-Adaptive Near-zero Integer Arithmetic Coding), который является одним из вариантов алгоритма CABAC (Context-Adaptive Binary Arithmetic Coding), также используемого при кодировании видео H.264Есть подозрение, что MPEG LA это дело отчислениями покроет если взлетит.
патенты на арифметику истекли.
Image Compression With an Auto-Indexing and Context-Learning MANIAC
https://drive.google.com/file/d/0BwMTfsYj-_l6eWZWRHg3RGtwQW8...
> анимациизачем?? :-(
>> анимации
> зачем?? :-(иди‐иди, ты флэш обновить забыл.
Написано на божественном C++, а не на Си, - уже огромный плюс.
> Написано на божественном C++, а не на Си, - уже огромный плюс.угу. надо только аглоритм переименовать а то "регуляторы" не поймут. "ишь развелось тут, МАНЬЯКОВ разных! и ходют и ходют, окаянные !! *махнул воображаемой клюшкой*"
А что сейчас самое лучшее в lossy? Чтобы было сравнимо с JPEG по степени сжатия и на сколько это вообще возможно превосходило его по качеству?
> А что сейчас самое лучшее в lossy? Чтобы было сравнимо с JPEG
> по степени сжатия и на сколько это вообще возможно превосходило его
> по качеству?opus
