помогите с форматом jpeg!
Решил я как-то раз написать просмотрщик жпегов, покопался в нете нашёл кое-что и вроде кое-как разобрался
со всем этим. Когда я начал проверять код на картинке 8x8 обнаружилась следующая вещь, с которой я понятия не имею что делать.
А дело вот в чём.
При чтении из файла вектора из 64 элементов всё нормально, затем деквантование(умножение на постоянный вектор, записанный в файле) и элементы в блоке 8x8 отличаются немного от исходных, но так и должно быть ведь сжатие с потерями, но после обратного ДКП блоки начальный и расшифрованный совсем не похожи, что тут можно сделать. ДКП вроде правильно, по крайней мере если не менять коэффициенты, то при обратном ДКП получается то же самое. В чём же тут может быть ошибка?
Буду очень ждать ответов, потому что уже изрядно намучился с этим. Только просьба не давать линков на готовые либы и всё такое, там тоже самое не работающее. Так что если кто знает где у меня ошибка подскажите пожалуйста!!!!!
Что значит совсем не похожи? Они и не должеы быть похожи, т. к. Вы применяете IDCT к уже изменной (в результате квантования) матрице.
Совсем не похожи, я думаю из примера всё будет яно.
Вот соответственно прямое и обратное ДКП.
А вот пример изображения 8X8 - каринка сверху зелёная снизу синяя:
это компонента Cb
исходная MCU
44 44 44 44 44 44 44 44
44 44 44 44 44 44 44 44
44 44 44 44 44 44 44 44
44 44 44 44 44 44 44 44
255 255 255 255 255 255 255 255
255 255 255 255 255 255 255 255
255 255 255 255 255 255 255 255
255 255 255 255 255 255 255 255
данные, прочитанные из файла
176 0 0 0 0 0 0 0
-770 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
270 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
-192 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
128 0 0 0 0 0 0 0
а это после ДКП, но без квантования(без потери данных)
172 0 0 0 0 0 0 0
-765 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
269 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
-179 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
152 0 0 0 0 0 0 0
и результат обратного ДКП той MCU, что записана в файле.
42 42 42 42 42 42 42 42
48 48 48 48 48 48 48 48
40 40 40 40 40 40 40 40
46 46 46 46 46 46 46 46
253 253 253 253 253 253 253 253
4 4 4 4 4 4 4 4
252 252 252 252 252 252 252 252
2 2 2 2 2 2 2 2
ошибка только в обратном ДКП т.к. не должно быть 2-к и 4-к, первыее 4 строки тоже отличаются но это допустимо, а вот последние...
А у вас исходная картинка была 8x8?
Пробовал и другие матрицы, в частности были матрицы-примеры, взятые из каких-то книг и прочих примеров из нета. В них всё было нормально, т.к. это были фрагменты фото и цвета там плавно изменяются, а в моём примере есть резкий переход и результат соответствующий. Я смотрел эту картинку,сохранённую ACDSee в редакторе, увеличенную во много раз и действительно там цвета отличаются, но они практически не заметны, особенно если смотреть нормальный размер. Но у меня получаются разноцветные горизонтальные полосы.
Да картинка 8x8.
Пробовал и другие матрицы, в частности были матрицы-примеры, взятые из каких-то книг и прочих примеров из нета. В них всё было нормально, т.к. это были фрагменты фото и цвета там плавно изменяются, а в моём примере есть резкий переход и результат соответствующий. Я смотрел эту картинку,сохранённую ACDSee в редакторе, увеличенную во много раз и действительно там цвета отличаются, но они практически не заметны, особенно если смотреть нормальный размер. Но у меня получаются разноцветные горизонтальные полосы.
Обычно матрицы для Cb и Cr набираются через строку или как среднее значение блока 2x2, т. е. из матрицы 16x16 Вы получите одну рабочую 8x8.
172 0 0 0 0 0 0 0
-765 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
269 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
-179 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
152 0 0 0 0 0 0 0
вот что получается после ДКП но без деления на коэф-ты таблицы квантования;
176 0 0 0 0 0 0 0
-770 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
270 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
-192 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
128 0 0 0 0 0 0 0
а вот из файла, они одинаковые засчет остатка от деления на квантованные коэф-ты( Round(172/11)=16, 16*11=176, Round(-765/11)=70,70*11=770,
Round(269/30)=9,9*30=270 ...
Данные, прочитанные из файла верные, но вот преобразование не верно.
Но на сколько я помню формулы ДКП не сложные.
На глюк с коэффициентами не похоже.
Эти 2-ки и 4-ки получаются из-за перегрузки UCHAR-а, когда после ДКП нужно увеличить значения на 128.
Теперь всё вроде бы нормально, но вот скорость...
А вы случайно не знаете про быстрое ДКП AA&N по-моему называется. Там гораздо меньше умножений и сложений. Я использую этот метод как он есть в jpeglib-е, но там что-то про смещение или умножение на 8 сказано, только я не разобрался что точно, может вы знаете о чём там речь, было бы совсем не плохо иметь в своём арсенале этот метод.
Да действительно глюк в реализации, и как это я сразу не догадался в чём ошибка.
Эти 2-ки и 4-ки получаются из-за перегрузки UCHAR-а, когда после ДКП нужно увеличить значения на 128.
Теперь всё вроде бы нормально, но вот скорость...
А вы случайно не знаете про быстрое ДКП AA&N по-моему называется. Там гораздо меньше умножений и сложений. Я использую этот метод как он есть в jpeglib-е, но там что-то про смещение или умножение на 8 сказано, только я не разобрался что точно, может вы знаете о чём там речь, было бы совсем не плохо иметь в своём арсенале этот метод.
У меня возникала мысль про смещение на 128, но не предал этому значение.
А что именно вас интересует про БДКП? Реализация?
Я больше как-то с БПФ имел дело. Но насколько помню БДКП основано на БПФ.
Если вам не сложно выложите код БПФ может это то же что БДКП.
Может быть они и похожи, если честно я не знаю про БПФ. Реалзация БДКП у меня есть jpeg-овская, но она просто так работает неверно, что-то про умножение там написано, но я не разобрался с этим.
Если вам не сложно выложите код БПФ может это то же что БДКП.
Могу выслать материалы по FFT Вам на мыло. Но это не то же самое что и DCT.
Картинка 1024x768 грузится секунд 8 наверное - я в шоке, при этом даже совсем без ДКП около 3 секунд. Как же это всё оптимизировать-то ведь чтение битов из файла по-моему уже быстрее не сделать разве что на ассемблере. Загрузка такого изображения даже обычным windows-ским просмотрщиком порядка секунды а то и меньше. Может вы можете что-нибудь посоветовать сделать со скоростью.
Да нет тогда спасибо, не надо. Буду искать в нете.
Картинка 1024x768 грузится секунд 8 наверное - я в шоке, при этом даже совсем без ДКП около 3 секунд. Как же это всё оптимизировать-то ведь чтение битов из файла по-моему уже быстрее не сделать разве что на ассемблере. Загрузка такого изображения даже обычным windows-ским просмотрщиком порядка секунды а то и меньше. Может вы можете что-нибудь посоветовать сделать со скоростью.
Ну, тут трудно что-либо конкртеное посоветовать. Для чтения файлов можно попробовать использовать отображение в память (file mapping), может тут можно выиграть.
А как Вы делаете вывод считанной картинки?
HBITMAP bmp=CreateCompatibleBitmap(dc1,Width,Height),oldbmp;
oldbmp=(HBITMAP)SelectObject(MemDC,bmp);
if(!::SetDIBits(MemDC,bmp,0,Height,p,&bi,DIB_RGB_COLORS))
TextOut(dc1,200,200,"Failed To SetDib",16);
BitBlt(dc1,0,0,Width,Height,MemDC,0,0,SRCCOPY);
SelectObject(MemDC,oldbmp);
DeleteObject(bmp);
DeleteObject(oldbmp);
DeleteDC(MemDC);
::ReleaseDC(window,dc1);
p - указатель на матричу точек.
Это всё происходит очень быстро.
А насчёт filemapping они что не в оперативу разве грузятся. А если так то это не поможет. Дело не в загрузке файла в память, а именно в скорости чтения битов ну и ДКП естественно.
Это всё происходит очень быстро.
А насчёт filemapping они что не в оперативу разве грузятся. А если так то это не поможет. Дело не в загрузке файла в память, а именно в скорости чтения битов ну и ДКП естественно.
Наверное стоит поэксперементировать с файлами.
Конечно же основной выигрышь буден на ДКП. Что же касается чтения битов из файлов, то на мой взгляд есть смысл в разумной буферизации, т. к. я тоже на этом как-то раз подсел. А релизация на ассемблере... Мне вспоминаются слова одного своего учителя, он говорил, что если грамотно реализовать мат. формулу, то в принципе разницы не будет. Хотя довольно часто приходиться наталкиваться на споры о выигрышее в скорости, при реализации на ассемблере.
А что там можно буферизовать при чтении бит даже не представляю, если честно.
Может вы подскажите, даже небольшой выигрыш в скорости был ба очень кстати.
На ассемблере я бы написал, да увы не знаю его.
А что там можно буферизовать при чтении бит даже не представляю, если честно.
Может вы подскажите, даже небольшой выигрыш в скорости был ба очень кстати.
Как я понимаю, тему топика мы исчерпали. Лучше пишете теперь в мыло.
Последнее, что я хотел спросить.
Может у вас есть какие-нибудь линки на методы быстрого ДКП(что-то вроде LL&M или AA&N), или вы сами знаете что-нить об этом?
Да, наверное, исчерпана.
Последнее, что я хотел спросить.
Может у вас есть какие-нибудь линки на методы быстрого ДКП(что-то вроде LL&M или AA&N), или вы сами знаете что-нить об этом?
Ваш e-mail?
Если у вас есть что-нибудь по быстому ДКП пришлите пожалуста, в нете я не могу найти ничего полезного.