The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Dropbox опубликовал реализацию алгоритма сжатия изображений Lepton

14.07.2016 21:31

Разработчики из компании Dropbox представили новый алгоритм сжатия изображений без потерь, применяемый для обеспечения экономии дискового пространства при хранении пользовательских изображений, уже сжатых в формате JPEG. Lepton позволяет сократить размер изображения JPEG в среднем на 22% без потери информации и с возможностью полностью бит в бит воссоздать исходный файл. Библиотека с реализацией алгоритма и сопутствующий набор утилит распространяется под лицензией Apache 2.0.

Реализация отличается высокой производительностью - на системе с CPU Intel Xeon E5 2650 (2.6GHz) сжатие производится со скоростью 5 мегабайт в секунду, а восстановление оригинала со скоростью 15 мегабайт в секунду, что позволяет организовать обработку изображений на лету и использовать Lepton для потоковой отдачи контента. Потребление оперативной памяти при работе с изображением составляет менее 24 Мб. Lepton применяется в Dropbox для хранения около 16 миллиардов изображений, позволяя компании экономить петабайты дискового пространства.

Используемый в Lepton алгоритм сжатия основан на предсказании коэффициентов кодирования в JPEG-блоках и использования предсказанных параметров для увеличения эффективности работы арифметического кодировщика. Напомним, что формат JPEG разбивает изображения на блоки 8×8 пикселей, которые сохраняются в виде 64 знаковых десятибитовых коэффициентов, при помощи которых можно воссоздать блок при помощи дискретного косинусного преобразования (DCT) и уточняющих параметров.

Уменьшение размера хранимых данных достигается благодаря тому, что рассчитанные коэффициенты не записываются как есть, а подвергаются дополнительному арифметическому кодированию (применяется кодировщик VP8), в котором учитываются данные ранее обработанных секций изображения, а результат сохраняется в формате унарного кодирования. Кроме того, коэффициент, отвечающий за параметры яркости (занимает до 8% размера), с высокой долей вероятности может быть предсказан на основании содержимого остальных коэффициентов. Для достижения 100% точности восстановления, Lepton оценивает разницу между предсказанным и фактическим значением и сохраняет только отличия.

Для повышения безопасности в реализации применяется фильтр seccomp, блокирующий выполнение системных вызовов, за исключением системных вызовов для чтения и записи в уже открытые файловые дескрипторы. Надёжность работы алгоритма проверена путем побитового сравнения восстановленных после кодирования изображений на коллекции из 4 миллиардов фотографий.

  1. Главная ссылка к новости (https://blogs.dropbox.com/tech...)
  2. OpenNews: Представлен FLIF, новый формат сжатия изображений без потерь
  3. OpenNews: Инженеры Dropbox представили новый алгоритм сжатия видео и изображений без потерь
  4. OpenNews: Доступен MozJPEG 3.0, высокоэффективный кодировщик JPEG-изображений от проекта Mozilla
  5. OpenNews: Создатель QEMU и FFmpeg предложил новый формат изображений BPG
  6. OpenNews: Представлен ImageZero, новый lossless-кодек для изображений
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: image, lepton, dropbox
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (81) Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, VoDA (ok), 21:39, 14/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Круто предсказывают! ))) На 22% )))
     
     
  • 2.22, Аноним999 (ok), 00:41, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Главное, что не  Lipton.
     
     
  • 3.38, KroTozeR (ok), 10:11, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Позор!!! Го зубрить школьный учебник физики за 11 класс, раздел "Квантовая физика" по слову "Лептон"!
     
     
  • 4.41, YetAnotherOnanym (ok), 10:25, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +10 +/
    Два чая этому джентльмену.
     
     
  • 5.87, Ваганыч (?), 19:15, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Два чая Lipton, я надеюсь? ;)
     
  • 4.63, Аноним (-), 12:43, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Квантовая физика в школьном учебнике? Ее походу на 3 курсе универа проходят.
     
     
  • 5.86, qwe (??), 18:33, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Представьте себе, по программе много что есть.
     
  • 1.2, Аноним999 (ok), 21:44, 14/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –10 +/
    Лучше бы ДропБокс починил отображение их значка на панели в КДЕ4.
     
     
  • 2.6, Шарп (ok), 22:09, 14/07/2016 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Зачем что-то чинить для KDE4, если все сейчас пользуются KDE5?
     
     
  • 3.8, Аноним999 (ok), 22:15, 14/07/2016 [^] [^^] [^^^] [ответить]  
  • –13 +/
    > Зачем что-то чинить для KDE4, если все сейчас пользуются KDE5?

    Покажи мне этих всех.
    И покажи кто ещё на KDE4 или ранее. И посчитай кого больше. К ним прибавь тех, кто платил за увеличение диска и сидит на КДЕ4.
    Многим нужна стабильность, а не КУбунту с новыми зондами. Особенно, если уже заплатил бабло за то, чтобы работало.
    А в ДропБоксе не чинят проблемы даже для платников, а занимаются каким-то алгоритмом сжатия.
    ВЫПОЛНИ ЛЮДЯМ ЧТО ОБЕЩАЛ, А ПОТОМ ЖМИ ЧТО ХОЧЕШЬ,

     
     
  • 4.11, Аноним (-), 22:20, 14/07/2016 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Ну мне лично плевать на существование дропбокса, кде, линукса и их проблемы, а новый алгоритм для общего пользования это полезно
     
     
  • 5.37, Аноним (-), 10:04, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Пользователь бзд?
     
     
  • 6.43, scorry (ok), 10:29, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Скорее виндовоз.
     
     
  • 7.45, Аноним (-), 10:42, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Скорее виндовоз.

    Но у нас иконка есть! И всегда была. И лично я Дропбоксу ничего не платил.


     
  • 4.39, iPony (?), 10:15, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > кто платил за увеличение диска и сидит на КДЕ4.

    А ты посчитал? Я вот уверен, что их процент от тех кто деньги заносит будет сравним с нулем.

     
  • 3.82, Аноним (-), 16:58, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Зачем вообще что то чинить на КДЕ, если есть Гном?
     
  • 2.53, вася (??), 11:18, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    юзай lxde
     
  • 2.83, Аноним (-), 18:15, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Багрепорт отправляли?
     
  • 2.92, Аноним (-), 16:04, 17/07/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    лучше бы они "репутацию починили", уволив часть персонала из АНБ, ЦРУ и госдепартамента из менеджмента и инженеров.
    с инвестициями их заодно
    ну и гугль заодно - тоже.
     
  • 1.4, Аноним (-), 22:04, 14/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Молодцы, хорошо сделали.
     
     
  • 2.23, Аноним999 (ok), 00:42, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > Молодцы, хорошо сделали.

    Ты уже сжимал?

     
     
  • 3.57, tyuiop (?), 12:19, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Ну я сжимал

    2934224 153.jpg
    2262558 153.lep

     
     
  • 4.62, tyuiop (?), 12:33, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати, текущая версия большие jpg-и (14MB и выше точно) не берёт

    Worker thread out of memory.

    linux x86_64, RAM 8GB.

     
  • 2.95, Аноним (-), 16:43, 17/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    из "свободных"(патентно) оно все равно слабее и FLIF и даже отягощенных патентами BPG и Jpeg2000(правда не так отягощенных как античный FIF или чать более новый но ощутимо менее эффективный LWF)
     
  • 1.9, Роман (??), 22:15, 14/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +11 +/
    0_о Пегий Дудочник??
     
     
  • 2.28, Кирилл72 (?), 03:28, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, я тоже об этом подумал)
     
  • 2.30, _KUL (ok), 06:10, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    было бы упоминание про хранение кодированный байтов у всех юзеров по p2p, тогда точно было бы очень эмоционально
     
  • 2.47, rshadow (ok), 10:47, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Лучше перевод от Кураж-Бомбей посмотри.
     
     
  • 3.84, Аноним (-), 18:15, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Лучше без перевода.
     
     
  • 4.91, Аноним Анонимович Анонимов (?), 16:28, 16/07/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да ну, это английский учить надо. Я лучше арч по гайдам установлю и нескучную тему прикручу.
     
  • 1.13, angra (ok), 22:43, 14/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    А пару десятков лет назад я объяснял юзерам, что картинки архивировать ненужно, так как их нельзя сжать еще больше никаким из имеющихся алгоритмов.
     
     
  • 2.14, Харитон (?), 22:48, 14/07/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Откройте дросселя xz. Змеи джепеги где-то также... Может медленнее разве что.

     
     
  • 3.15, Харитон (?), 22:50, 14/07/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Откройте для себя xz. Жмет джепеги где-то также... Может медленнее разве что.

    Ого автозамена.

     
  • 3.17, Аноним (-), 23:47, 14/07/2016 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Проорал.
     
  • 3.24, angra (ok), 00:56, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да что вы говорите. Взял первые пять попавшихся jpg,
    -rw-r--r--  1 root root  143826 Jul 15 00:44 0000002001343333813.jpg
    -rw-r--r--  1 root root  125867 Jul 15 00:44 0000003001364870370.jpg
    -rw-r--r--  1 root root  173707 Jul 15 00:44 0000007001352314836.jpg
    -rw-r--r--  1 root root 1821217 Jul 15 00:44 0000008001434405836.jpg
    -rw-r--r--  1 root root   13368 Jul 15 00:44 0000009001339602756.jpg

    xz -9 -e
    -rw-r--r--  1 root root  143892 Jul 15 00:44 0000002001343333813.jpg.xz
    -rw-r--r--  1 root root  125912 Jul 15 00:44 0000003001364870370.jpg.xz
    -rw-r--r--  1 root root  173776 Jul 15 00:44 0000007001352314836.jpg.xz
    -rw-r--r--  1 root root 1570456 Jul 15 00:44 0000008001434405836.jpg.xz
    -rw-r--r--  1 root root   13296 Jul 15 00:44 0000009001339602756.jpg.xz
    Итого для трех увеличение объема вместо сжатия, 0.5% на четвертом и только на одном огромном jpeg удалось получить 13%.

     
     
  • 4.32, Anonymous2 (?), 08:52, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ого, картинки от рута...

    Нода в докере?

     
     
  • 5.46, Аноним (-), 10:47, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Ого, картинки от рута...

    Порнуху рута никто не увидит кроме самого рута! Подозреваю, там что-то с тентаклями.


     
     
  • 6.52, Аноним (-), 11:09, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > -rw-r--r--
    > r--
    > никто не увидит
     
     
  • 7.56, Аноним (-), 12:12, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Мда, теряю сноровку, мля.. :(
     
     
  • 8.60, angra (ok), 12:28, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Сейчас скажу страшное для вас обоих, возможность просмотреть файл определяется не только правами на него, но и правом eXecute на всех папках по пути к нему. Админы нашлись.
     
  • 5.58, angra (ok), 12:24, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Время модификации ни на какие мысли не наводит?
     
     
  • 6.73, Аноним (-), 13:52, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Всё произошло в течении одной минуты? Ну, может у него не АМД?
     
  • 2.29, x0r (??), 04:15, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Откройте для себя paq (paq8px)
     
     
  • 3.48, Аноним (-), 10:48, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Откройте для себя paq (paq8px)

    И ещё какую-нибудь неведомую муйню откройте. Нужно больше альтернативы!


     
     
  • 4.80, _ (??), 16:14, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не понял предъявы. Знать - всй равно полезно.
    А так ... дык даже Dropbox липки бзерам не отдаёт, где то там у себя в кишках перекодирует взад.
     
  • 4.88, Zarat (ok), 23:05, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Все, кто раньше, хоть сколь нибудь, детально интересовались сжатием данных, знают об архиваторах класса paq, как алгоритмах, получающих призовые места по уровню сжатия, и входящие в базовую поставку программы PeaZip (по моему мнению лучший архиватор с GUI под Линкус, другое дело Линукс и архиватор с GUI плохо сочетаются). Более того не удивлюсь если за базу Лептона брали именно алгоритмы класса paq, так как те тоже базируются на предсказании очередного символа нейронными сетями. Возможно просто подогнали модели предсказания с данных общего назначения на данные именно изображений. К тому же облегченные варианты сжатия данных общего назначения paq - lpaq (по моим давним тестам) показывали неплохую производительность - в зависимости от уровня сжатия в 10-20 раз медленнее xz -z9e.
    Вот более детальное исследование алгоритма предсказания в Лептоне было бы интересно.

    Так что здесь, очередной школьник опять пролетает

     
     
  • 5.89, Crazy Alex (ok), 00:33, 16/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, то есть paq будет медленнее Lepton раз в 5-10, как минимум. Всего-то. Что логично, так как никаких нейронных сетей в нём нет. Вам, собственно, алгоритм выше описали.
     
     
  • 6.96, Аноним (-), 17:48, 17/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    если вам "скорости" то BPG порвет как тузик грелку всех трех, благодаря аппаратной поддержке HEVC в процах и ВК.
    сабж как и FLIF интрересн предлагаемой неотягощенностью патентами сугубо. по эффективности в обоих смыслах - альтернатив вагон(хотя и тут FLIF на пятки наступает почти всем).
     
  • 3.65, Аноним (-), 12:50, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это который будет сжимать так долго (а разжимать ещё дольше!), что за это время выйдет срок службы винчестера?
     
  • 2.33, soarin (ok), 08:53, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А пару десятков лет назад я объяснял юзерам, что картинки архивировать ненужно, так как их нельзя сжать еще больше никаким из имеющихся алгоритмов.

    Да и пару десятков лет, естественно можно было сжать сжатые картинки.
    Вопрос же как всегда в целесообразности - крошечный выигрыш при лишних действиях от пользователя и затраченного времени не особо покатит.

     
     
  • 3.67, angra (ok), 12:56, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Пару десятков лет назад rar, zip, arj могли очень редко дать 1% сжатия на картинке, но чаще всего вместо этого приводили к увеличению занимаемого места. На большом количестве мелких картинок от архивации было больше пользы, чем от сжатия, но смысла все равно не имело. В отличии от сабжа.
     
     
  • 4.70, Аноним (-), 13:18, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Пару десятков лет назад rar, zip, arj могли очень редко дать 1%
    > сжатия на картинке, но чаще всего вместо этого приводили к увеличению
    > занимаемого места.

    А сейчас что-то изменилось? Ну, кроме версий этих архиваторов.


     
     
  • 5.74, angra (ok), 13:57, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Новость прочитать не пробовал?
     
     
  • 6.75, Аноним (-), 14:02, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Новость прочитать не пробовал?

    Не, я не сжимаю картинки. У меня даже в iCloud всё хранится несжатое.

     
     
  • 7.76, Led (ok), 14:23, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Не, я не сжимаю картинки. У меня даже в iCloud всё хранится несжатое.

    Макофилы любят большие?

     
     
  • 8.77, Аноним (-), 14:53, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Да. Мы не жмёмся.
     
     
  • 9.81, _ (??), 16:16, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Да. Мы не жмёмся.

    На вазелин? :-)

     
  • 7.78, scorry (ok), 15:45, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Новость прочитать не пробовал?
    > Не, я не сжимаю картинки. У меня даже в iCloud всё хранится
    > несжатое.

    Типа спецом разжимаешь, что ли?

     
  • 4.79, soarin (ok), 15:51, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Пару десятков лет назад rar, zip, arj (три)
    > никаким из имеющихся алгоритмов.

    Какая связь?

     
     
  • 5.97, Ordu (ok), 17:54, 17/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Если вы, цитируя, не будете выкидывать существенные куски контекста, то вы не потеряете связь.

    > я объяснял юзерам
    > юзерам

    "Юзерам", Карл!

     
     
  • 6.99, iPony (?), 09:49, 18/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так от этого оригинальная фраза не перестаёт быть враньём для юзеров

    > пару десятков лет назад я объяснял юзерам, что картинки архивировать ненужно, так как их нельзя сжать еще больше никаким из имеющихся алгоритмов

    Если было б написано

    > я объяснял юзерам, что картинки архивировать ненужно, так как нет практического смысла

    То OK

     
  • 2.34, shpaker (ok), 08:54, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • –6 +/
    Пару десятков дет назад? Юзерам? Это в каком году? В сорок пятом?
     
     
  • 3.35, тоже Аноним (ok), 09:01, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +10 +/
    Напечатайте это себе на футболке. Люди при встрече с вами будут хоть как-то подготовлены...
     
     
  • 4.49, Аноним (-), 10:53, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Ну, пару десятков лет назад ведь не было ещё никаких компьютеров же ж!
    Я сейчас подумал, первому Думу ведь 23 года уже. А весёлая нынче уже школота, правда? Интересно, а дисковым телефоном оно бы смогло воспользоваться?


     
     
  • 5.68, тоже Аноним (ok), 13:12, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Советским - смогло бы. А вот хлипким китайским кокос не расколешь.
     
     
  • 6.71, Аноним (-), 13:25, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Советским - смогло бы. А вот хлипким китайским кокос не расколешь.

    Во!
    http://www.3dnews.ru/assets/external/illustrations/2012/09/11/635006/iclassic
    Но тут тоже не до кокосов. Вот этими вот..
    http://www.macdigger.ru/wp-content/uploads/2016/06/patriot-1.jpg
    Ой, не то!


     
  • 1.18, Аноним (-), 23:49, 14/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > сжатие производится со скоростью 5 мегабайт в секунду, а восстановление оригинала со скоростью 15 мегабайт в секунду

    На чём?

     
     
  • 2.19, кругомогорожено (?), 00:01, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    На 5 и 15 мегабайтах в секунду, соответственно.
     
  • 2.21, Штунц (?), 00:12, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > На чем?

    На кластере из квантовых компьютеров

     
  • 2.50, Аноним (-), 10:55, 15/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > На чём?

    Ну явно не на вашем дисководе.

     
  • 1.26, cmp (??), 01:52, 15/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    То есть, оклонения от статистического дефолта, показали бы этот дефол, интересно котик или селфи с утиными губками))
     
  • 1.27, Аноним (-), 02:59, 15/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >>коллекции из 4 миллиардов <приватных> фотографий

    магнет пожалуйста

     
  • 1.31, Аноним (-), 07:20, 15/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Так вот почему у них картинки по полчаса скачиваются?
     
  • 1.40, iv (?), 10:21, 15/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Потребление оперативной памяти при работе с изображением составляет менее 24 Мб.

    Независимо от размера картинки, архитектуры и оси?

     
     
  • 2.98, Аноним (-), 00:30, 18/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    бенчмаркинга с разными тестовыми наборами картинок и с разными установками кодэка - не, пока не делали. с взятым для примера - однако видно что скромный процессорный оверхэд(относительно).
    надо было конечно как у конкурентов из флиф сделать
    https://docs.google.com/spreadsheets/d/1LxY78fbm47VmrYGTXkBXXitGjhGl32NsuHPH2Q
    https://docs.google.com/spreadsheets/d/16ghJEjf_T7TDTOg2WlelnG1SYCsHng6V-1rxdo
    где сразу видно на каком контенте что в каком режиме - выглядит интереснее :=)
     
  • 1.42, Аноним (-), 10:27, 15/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а чё дрмный интел а не амд ? или свет клином
     
  • 1.59, anonymous (??), 12:25, 15/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Чем это лучше packjpg?
     
     
  • 2.90, Crazy Alex (ok), 01:03, 16/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    По сжатию примерно на том же уровне.
    По скорости - мне сложно судить, так как под 32 бита Lepton не собрался. Но если экстраполировать мои результаты на Intel Xeon E5 2650 - то на одном ядре packjpg может выдать сжатие примерно в те же 5 МБ/с. Без AVX, которые Lepton использует при возможности.

    НО. packjpg - симметричный - распаковка занимает столько же, сколько и упаковка.

     
  • 1.85, Barafu (?), 18:20, 15/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Хоронили JPEG, порвали 3 стандарта.
     
     
  • 2.94, Аноним (-), 16:07, 17/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    по поводу Jpeg-92 до сих пор споры идут кстати.
    идеальная реализация исходного-то - так и не прижилась. ее только IJG пилит и неплохо пили т кстати(и lossless туда впилили и прочие фичи от jpeg-xr и jpeg2000 частично).
     
  • 1.93, Аноним (-), 16:05, 17/07/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    не круче BPG увы. даже хуже Jpeg-XR, аэто довольно средне "по современным меркам"
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:


    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру
    Hosting by Ihor