ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Пятница
26 апреля
653813 Топик полностью
Николай Коровин (18.02.2016 16:17 - 16:40, просмотров: 111) ответил fk0 на GIF картинку как есть, так и показывать. Ибо там сжатие соседних кадров. Иначе ж памяти не напасёшься. Если всё же напасёшься, то вот тебе столбовой путь:
Кстати, чертовски разумно. Или, как вариант, тупо сделать свой RLE, если цветов мало — будет а-фи-генное сжатие. Алгоритм: делается N+1 цветов, где «лишний» цвет означает «не перерисовывать кадр». Сжимается по RLE первый кадр, а каждый следующий сжимается по RLE с оглядкой на неоднозначность: у нас же есть предыдущий кадр, поэтому те области, которые совпадают по цвету, можно закодировать как серию цвета «не перерисовывать», а можно — как серию цвета «белый», например, если там был белый и стал белый тоже. И смотреть, какая серия получается длиннее — та, где втупую кодировали цвет кадра (если однородная полоска стала длиннее — эффективнее кодировать её цвет втупую), или та, где кодировали разницу (если неоднородный элемент рисунка остался на своём месте — эффективнее его покрыть одной длинной серией цвета «не трогать»). Ну, и выбирать для каждого случая более эффективный вариант. Для 68×64 явно не нужен сложный формат с фреймами и хедерами, а вот блоб RLE — самое оно, самое оно. Там уже пора экономить на формате и парсере, но при этом оставлять сжатие примерно уровня GIF. UPD: картинка прилагается. Реализации, по беглым прикидкам, тут на один чих %)
image