The OpenNET Project / Index page

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

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 3.0
Короткая ссылка: https://opennet.ru/44787-image
Ключевые слова: image, lepton, dropbox
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (81) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | 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 1... большой текст свёрнут, показать
     
     
  • 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 +/
    Сейчас скажу страшное для вас обоих, возможность просмотреть файл определяется н... текст свёрнут, показать
     
  • 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 +/
    Все, кто раньше, хоть сколь нибудь, детально интересовались сжатием данных, знаю... большой текст свёрнут, показать
     
     
  • 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:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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