Есть быстрее сжатия, чем JPEG?
есть ли алгоритм сжатия, который быстрее, чем JPEG, но хорошо поддерживается? Я знаю о jpeg2000, но из того, что я слышал, это не намного быстрее.
Edit:для сжатия.
Edit2: он должен работать на Linux 32 бит, и в идеале он должен быть на C или c++.
6 ответов
jpeg кодирование и декодирование должно быть очень быстро. Вам будет трудно найти более быстрый алгоритм. Если это медленно, ваша проблема, вероятно, не формат, а плохая реализация кодировщика. Попробуйте кодер из libavcodec на .
у вас есть инструкции MMX/SSE2, доступные в вашей целевой архитектуре? Если это так, вы можете попробовать libjpeg-turbo. Кроме того, вы можете сжать изображения с чем-то вроде zlib, а затем передавать фактическое сокращение на другую машину? Обязательно ли фактическое сжатие изображений с потерями происходит на самом встроенном устройстве?
в каком контексте? На ПК или портативном устройстве?
из моего опыта у вас есть JPEG, JPEG2000, PNG и ... Ну, вот и все для "хорошо поддерживаемых" типов изображений в широком контексте (с потерями или нет!)
(Ура, что GIF на своем пути.)
JPEG2000 не быстрее вообще. Это кодирование или декодирование, которое недостаточно быстро с jpeg? Вероятно, вы могли бы быть намного быстрее, делая только 4x4 FDCT и IDCT на jpeg.
трудно найти какую-либо документацию по ijg libjpeg, но если вы используете это, попробуйте снизить настройку качества, это может сделать его быстрее, также, кажется, есть быстрый вариант FDCT.
кто-то упомянул libjpeg-turbo, который использует инструкции SIMD и совместим с обычным libjpeg. Если это вариант для вас, я думаю, вы должны попробовать его.
Я думаю, что алгоритмы сжатия на основе вейвлетов в целом медленнее, чем те, которые используют DCT. Возможно, вам стоит взглянуть на форматы JPEG XR и WebP.
вы можете просто изменить размер изображения на меньший, если вам не требуется полная точность изображения. Усреднение каждого блока 2x2 в один пиксель очень быстро уменьшит размер до 1/4.