| 1.3, Black Paladin (?), 22:27, 20/10/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Либо теряем точки либо теряем цвет. Я бы использовал 251*8 бит как 2008 точек с однобитовой глубиной цвета, которую, конечно нужно очень качественно усреднить при сжатии.
Какие варианты предложат коллеги?
| | |
| |
| 2.29, axe (??), 19:47, 21/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
наверное все же один байт на базовый цвет и 2000 точек.
Это наивно, получившийся блоб можно ужать каким нибудь LZW - получится гораздо меньше 251 байта, поэтому можно на цвет выделить битов поболее. А вообще - gif, jpeg, png рулит - все уже придумано до нас
| | |
|
| 1.4, Аноним (-), 22:32, 20/10/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– | |
>DLI
у которого закрыты не только исходники, но даже неизвестно ничего об используемых алгоритмах и формате данных.
| | |
| |
| 2.16, rshadow (ok), 23:51, 20/10/2013 [^] [^^] [^^^] [ответить]
| +13 +/– |
 очевидно там зашито единственное вручную подобранное изображение =)
| | |
|
| 1.6, Аноним (-), 22:50, 20/10/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Есть же Алгоритм (да-да, с большой буквы) Бабушкина!
Фильм "Клик" — 1020B!
| | |
| |
| |
| 3.30, axe (??), 21:20, 21/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> И к нему плеер размером 1.4Гб ?
нет, составной ключ к архиву на 2Гб
| | |
|
|
| 1.7, bircoph (ok), 22:56, 20/10/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 Я без очков не вижу разницы между всеми 4 картинками, кроме небольшого изменения цветовой палитры последних двух.
| | |
| |
| 2.20, Аноним (-), 03:27, 21/10/2013 [^] [^^] [^^^] [ответить]
| +5 +/– |
> Я без очков не вижу разницы между всеми 4 картинками, кроме небольшого
> изменения цветовой палитры последних двух.
Да... вам надо к окулисту. Ну или монитор надо протереть уже наконец.
| | |
|
| 1.9, Наивный чукотский юноша (?), 23:05, 20/10/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
<sarcasm> А вообще это превосходный формат для игр на современных консолях. Можно существенно ужимать ресурсы практически без искажения графики. И сглаживание не потребуется. </sarcasm>
| | |
| 1.11, kurokaze (ok), 23:20, 20/10/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
 Абсолютно дебильное сравнение.
Основную массу видео при использовании кодеков такого типа составляют P- и B-кадры, соответственно качество опередяется качеством просчета motion compensation.
Тут мы видим качество упаковщика I-кадра. Отлично. Он может быть бесконечно хорош, но если motion compensation сделано дубово, то качество в общем будет хуже существующих кодеков.
Короче разводка для лохов. Маркетинг итить.
| | |
| |
| 2.18, arisu (ok), 01:23, 21/10/2013 [^] [^^] [^^^] [ответить]
| +4 +/– |
 > Короче разводка для лохов. Маркетинг итить.
хипстеры нонче очень котируют всё, где упоминаются всякие «твиттеры» и прочая бесполезная фигня.
| | |
| 2.21, Аноним (-), 03:33, 21/10/2013 [^] [^^] [^^^] [ответить]
| +/– | |
> Короче разводка для лохов. Маркетинг итить.
Тем не менее, I-кадр выступает референсом и хорошо бы чтобы он был покачественнее, но весил при этом поменьше. Иначе качественной картинки не видать.
Современные кодеки умеют ставить относительно мало I-кадров в потоке, но тут лезет иная проблема: в случае сбоев реиснхрон очень длительный, перемотка - жутко тормозит, т.к. если I-кадры идут каждые 1000 кадров, то юзер отмотавший на I+500 кадров нарвется на нужду задекодировать I-кадр и 500 кадров P и B типа за ним. Что очень сильно доставляет, ибо минимум несколько секунд интенсивной нагрузки на проц пока плеер усиленно декодирует 500 кадров (в нормальном виде это почти 20 секунд видео). Поэтому желание сильно экономить на I-кадрах приводит к граблям с которыми сталкивались юзеры div3 и тому подобного, когда на весь мувик 5 I-кадров и черта с два такой мувик вообще перемотаешь "на 22 минуты 46 секунд". Окажется что все 22 минуты и 46 секунд от 1-го I кадра декодироват - во атас :).
| | |
| 2.31, Челъ (?), 22:09, 21/10/2013 [^] [^^] [^^^] [ответить]
| +/– |
Вот-вот. Как вообще можно говорить о сжатии изображения видеокодеком? Можно сделать видеокодек сделать который изображения одним битом жмёт без потерь, когда имеем стоячий кадр.
| | |
|
| 1.25, Xasd (ok), 11:21, 21/10/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 помоему -- самое касественное получилось в варианте Img2twit...
...ну а то что не видно лица на картинке -- тыг это наоборот хорошо :-)
| | |
| 1.33, Тузя (ok), 08:46, 22/10/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Реализация HEVC очень плохая. Я вижу артефакты дискретного косинусного преобразования, сильная урезка высокочастотных характеристик, скачки яркости на границах макроблока. DLI тоже использует ДКП, это видно по аналогичным квадратным артефактам, но квантование более умное, видимо делается с учетом предварительного размытия. img2twit, видимо, вейвлетен, а вейвлетные разложения плохо держат низкий битрейт, но, в свою очередь, не пересекаются с патентами MPEG LA. Плохо то, что помимо игаженных luma-характеристик, chroma-тоже поплыла.
| | |
|
