Ладненько... :-))) Погладим, что получится -- платку заказал универсальную под LPC3250, 2478 и 1768.

Rst, ты за прошедшую пятилетку повзрослел и можешь вытерпеть прямое обращение, или только "Вы" ?
Ведь к Господу в "Отче наш" мы обращаемся на Ты !.. И дети ко всем

По-прежнему очень актуален вопрос кратких исходников для jpeg2000 и всего прочего сжимательного, 20К для монохромного jpeg мне очень нравятся !
Хоть можно в отладчике походить и обозреть своими старыми мозгами, что же там на самом деле происходит !
А Жасперы и ОпенГугловый проект (очень похожие по своим каталогам) лишь замутняют понимание (кроме всех пожираемых ресурсов) вместе со всеми "направляющими х.з. куда" спецификациями на нехороших языках (которые тоже можно изложить в 5 раз короче и на порядок понятней), это слишком большая цена за вход в "мафиозные сжатые круги".
Надо "русской" стороне сопротивляться всем западным извра-методам, переводить больше всего, "познавшим всю прелесть" писать методички на форумах, типа этого, по кафедрам, "не лягать" под этих отщепенцев и "тягателей одеяла под себя" испокон веков, учить их уму-разуму, свои стандарты придумывать, на 2 порядка более простые, и сразу к ним C-VHDL-реализацию публиковать -- так оно приличней для русскоязычного народа !
Неужели все так и довольствуются Жасперами "для бедных" -- типа бус и погремушек для индейцев от Колумба, и никто не выцепил самую суть для отдачи братьям по разуму ?

jpeg2000 сжимает лучше за счёт арифметического кодера, причём учитываются значения окружающих точек.
И не забываем про полнокадровый Вавелет в двух направлениях.

Blackfin561@500MHz сжимал цветной кадр 640*480 за 13 секунд - широкое поле для оптимизации...

лучшесть jpeg2000 в значительной степени притянута за уши. Можно полюбопытствовать в гугеле и убедиться в этом.
Что касается поля оптимизации, то его практически нет. Причина прозаична - обработке подвергается каждый бит в каждом отсчете преобразования.

Так что имеет смысл 100500 раз подумать, стоит ли выигрыш в снр на 2-3 дб при приемлемом качестве картинки неимоверного роста объема вычислений...

кто мешает тогда в обычном jpege вместо хаффмана арифметический кодер использовать?
после убирания нулей в RLE гистограмма не такая узкая чтобы заметная разница была из-за того, что хаффман позволяет только целое количество бит/символ, а арифметический - дробные.


радости от полнокадрого вэйвлета? просто теперь артефакты сжатия будут не в виде квадратиков 8х8, а в виде замыливания всего кадра.
то что там по циферкам каких-то лишних пара дБ добавятся, на глаз не особо заметно.


что-то очень уж долго, не должно там разницы с обычным jpegом быть в 200 раз быть.

Там же наверное Жасперная библиотека была с замутнением процесса через тучу вложенности и float ?
Клянусь клятвенно, если разберусь по куче исходников, где трудно выцепить, где же там основной объём работы прячется, и оптимизируется всё в один файл, тапа как у Rst, продолжить его приличную традицию "Бог велел делиться", несмотря на то, что у нас на фирме "интеллектуальная собственность всех работников принадлежит руководству".
В связи с санкциями очень хотелось бы аппаратный кристалл кодека видео во всякие крутые форматы -- "jpeg у всех есть", как тут давно написано, просто на всю страну можно, думаю, организовать потребность в десятки тысяч годовых экземпляров, чем в дорогие ПЛИС всё толкать, объединение опять же пойдёт на пользу перед лицом внешних проблем. Технологии штамповки ж у нас есть хотя бы 15-летней давности, когда зарождались ADV2** всякие ? Чем каждому сидеть в уголке и свою косточку грызть -- которых западенцы нам накидали для разъединения ?
Интерфейсы у Рус-hard-кодека могут быть попроще "ад"-ских -- 2-направленная 8-битная шина к ПЛИС типа ULPI и 32-битная к процессору или AMB-е, никакого особо программирования и заливки 32 К кода в SoC -- пнул размеры и тип кодирования и побежал данные совать-доставать...

> кто мешает тогда в обычном jpege вместо хаффмана арифметический кодер использовать?

Наружу хочется компатибельное видео, как записалось в девайсе -- так и выдавать потребителю на просмотр, без дополнительных преобразований и писания своих кодеков. Хотя если у кого есть реализации под обычные проигрыватели -- опять же "Прошу Паны !".

Арифметическое кодирование считается более медленным из-за своей нетабличности, не уверен насчёт "каждый бит в каждом отсчете" после беглого знакомства -- вроде ж надо утоптать 1 коэффициент вэйвлета к предыдущим в отрезок в соответствии с текущей весовой долей и позицией, всё в целых числах, для ПЛИС/ASIC такая задача должна быть детской из-за параллельности, ну а в проце частота больше, деления только не у всех есть быстрые, но можно опять же через умножение-сдвиг выкрутиться.

Лет 20 назад - мешали лицензионные и вычислительные ограничения, сейчас - используют то, под что есть готовые библиотеки.



Ну мы тут тестировали несколько сторонних кодеков, и как-бы не пара Дб да и на глаз разница в очевидна:




Не должно, но 10 секунд из 13 занимало именно арифметическое сжатие, так что оптимизацию надо с него начинать...

разница на глаз очевидна, только несмотря на то, что надпись сименс в углу и кусок желтого крана в правом нижнем углу и кромки бетонных плит выглядят заметно чётче, у чувака пропала часть уха, куда-то делись зубы, и лицо выглядит весьма помятым (тени на морде) и появились узоры на каске, так же и отдельные дефекты на бетонной плите в виде небольших чёрных точек пораждают вокруг себя весьма заметные артефакты. а нерезкие границы вроде каста/бетон или куртка/бетон сильно размазаны.
то есть при формальных 6дБ разницы по цифиркам, сказать что картинка в стала в два раза лучше ну никак нельзя.
просто артефаты стали другими, и на некоторых картинках будут мало заметны, а на некоторых выглядят даже хуже.

индусские примеры выложенные на сайте ADI дают 50 тактов на пиксель для всего jpega, и 40-190, а в среднем 50-100 тактов на символ для арифметического энкодера, так что раза в 3 разницы еще можно поверить, но не в 200.

_pv, поправьте, если ошибаюсь, но jpeg2000 в отличии от классического (ISO 10918-1:1994) позволяет область лица, заранее определенную прочими алгоритмами, сжать с меньшим коэффициентом сжатия. В современных фотоаппаратах, вроде, кодирование так и происходит.

Добавлю, что практически в любой книге про сжатие фото/видео при описании объективных метрик указывается несовершенство этих методов именно в контексте субъективного человеческого восприятия лиц, человеческих глаз и т.п.

Поэтому надо, конечно, как-то более комплексно сравнивать или с оговорками.

Сообщение отредактировал x736C - Sep 19 2014, 06:24