https://www.opennet.dev/openforum/vsluhforumID3/108548.html Разработчики из компании Dropbox представили (https://blogs.dropbox.com/tech/2016/07/lepton-image-compression-saving-22-losslessly-from-images-at-15mbs/) новый алгоритм сжатия изображений без потерь, применяемый для обеспечения экономии дискового пространства при хранении пользовательских изображений, уже сжатых в формате JPEG. Lepton позволяет сократить размер изображения JPEG в среднем на 22% без потери информации и с возможностью полностью бит и бит воссоздать исходный файл.<br>Библиотека с реализацией алгоритма и сопутствующий набор утилит распространяется (https://github.com/dropbox/lepton) под лицензией Apache 2.0.<br><br><br>Реализация отличается высокой производительностью - сжатие производится со скоростью 5 мегабайт в секунду, а восстановление оригинала со скоростью 15 мегабайт в секунду, что позволяет организовать обработку изображений на лету и использовать Lepton для потоковой отдачи контента. Потребление оперативной памяти при работе с изображением составляет менее 24 Мб. Lepton применяется в Dropbox д https://www.opennet.dev/openforum/vsluhforumID3/108548.html#99 Mon, 18 Jul 2016 06:49:58 GMT Ну так от этого оригинальная фраза не перестаёт быть враньём для юзеров<br><br>&gt; пару десятков лет назад я объяснял юзерам, что картинки архивировать ненужно, так как их нельзя сжать еще больше никаким из имеющихся алгоритмов<br><br>Если было б написано<br><br>&gt; я объяснял юзерам, что картинки архивировать ненужно, так как нет практического смысла<br><br>То OK<br> https://www.opennet.dev/openforum/vsluhforumID3/108548.html#98 Sun, 17 Jul 2016 21:30:02 GMT бенчмаркинга с разными тестовыми наборами картинок и с разными установками кодэка - не, пока не делали. с взятым для примера - однако видно что скромный процессорный оверхэд(относительно).<br>надо было конечно как у конкурентов из флиф сделать<br>https://docs.google.com/spreadsheets/d/1LxY78fbm47VmrYGTXkBXXitGjhGl32NsuHPH2QXufgA/edit?usp=sharing<br>https://docs.google.com/spreadsheets/d/16ghJEjf_T7TDTOg2WlelnG1SYCsHng6V-1rxdo78YL8/edit?usp=sharing<br>где сразу видно на каком контенте что в каком режиме - выглядит интереснее :=)<br> https://www.opennet.dev/openforum/vsluhforumID3/108548.html#97 Sun, 17 Jul 2016 14:54:29 GMT Если вы, цитируя, не будете выкидывать существенные куски контекста, то вы не потеряете связь.<br><br>&gt; я объяснял юзерам<br>&gt; юзерам<br><br>"Юзерам", Карл!<br> https://www.opennet.dev/openforum/vsluhforumID3/108548.html#96 Sun, 17 Jul 2016 14:48:11 GMT если вам "скорости" то BPG порвет как тузик грелку всех трех, благодаря аппаратной поддержке HEVC в процах и ВК.<br>сабж как и FLIF интрересн предлагаемой неотягощенностью патентами сугубо. по эффективности в обоих смыслах - альтернатив вагон(хотя и тут FLIF на пятки наступает почти всем).<br> https://www.opennet.dev/openforum/vsluhforumID3/108548.html#95 Sun, 17 Jul 2016 13:43:04 GMT из "свободных"(патентно) оно все равно слабее и FLIF и даже отягощенных патентами BPG и Jpeg2000(правда не так отягощенных как античный FIF или чать более новый но ощутимо менее эффективный LWF)<br> https://www.opennet.dev/openforum/vsluhforumID3/108548.html#94 Sun, 17 Jul 2016 13:07:51 GMT по поводу Jpeg-92 до сих пор споры идут кстати.<br>идеальная реализация исходного-то - так и не прижилась. ее только IJG пилит и неплохо пили т кстати(и lossless туда впилили и прочие фичи от jpeg-xr и jpeg2000 частично).<br> https://www.opennet.dev/openforum/vsluhforumID3/108548.html#93 Sun, 17 Jul 2016 13:05:21 GMT не круче BPG увы. даже хуже Jpeg-XR, аэто довольно средне "по современным меркам"<br> https://www.opennet.dev/openforum/vsluhforumID3/108548.html#92 Sun, 17 Jul 2016 13:04:22 GMT лучше бы они "репутацию починили", уволив часть персонала из АНБ, ЦРУ и госдепартамента из менеджмента и инженеров. <br>с инвестициями их заодно<br>ну и гугль заодно - тоже.<br> https://www.opennet.dev/openforum/vsluhforumID3/108548.html#91 Sat, 16 Jul 2016 13:28:38 GMT Да ну, это английский учить надо. Я лучше арч по гайдам установлю и нескучную тему прикручу.<br>