Существуют ли нематематические алгоритмы уменьшения изображения более чем в 4 раза?
ПРореживание через пиксель дает боле-менее нормальные результаты для фотографий.
А вот как относительно честно уменьшить больше - не представляю. В смысле, если не использовать математику, а только механику.
А гугл предлагает исключительно математику.
А у меня с математикой напряг. 5 мегапиксельная фотография закачивается на экран аж 5 секунд. Это при том, что джпегфайл с картинкой уже лежит в памяти. Полагаю, математическое масштабирование добьет всё окончательно.

Что-то совсем не ясно, что значит - "не использовать математику, а только механику".

Вы бы все-же рассказали подробности. 5 мегапискелей - это, грубо говоря, 15 мегабайт. Куда Вы их льете, что аж 5 секунд времени это занимает? Что за платформа и т.д.?

Пять мегапикселей в джпеге. Сам файл - 1.2 мега.
Платформа 9261 атмел.
5 секунд занимает преобразовать 1.2 мега джпег в RGB.

Тут выяснилось, что если в блоке 16 на 16 оставлять только 1 бит, тоже получается фото рассмотреть. Если придираться, то конечно видно. А так- вроде как ничего.

есть 4 отсчета, нужно получить 3. Интерполируем до 12 - 4-е группы по 3. Переразбиваем на 3 группы. В каждой группе находим сумму отсчетов и делим на их количество. Так по строчкам и по столбца... Редко где я это еще не предлагал... Такое масштабирование фактически не обратимое, но практически - таки да ...

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

А, блин... Кстати, в jpeg можно все сделать по простому, если маштабировать в 2^n раз. Просто для уменьшения изображения в 2 раза делаем IDCT размером 4*4 (вместо 8*8), естественно, беря только 16 нужных коэффициентов (остальные - отбрасываем). Для уменьшения в 4 раза - IDCT размером 2*2 и пользуем только 4 коэффициента. Все, должно летать. Особенно, если в 4 раза. А если в 8 - так одна постоянка остается



Кстати, размер выходной bmp огласите.

Это-то все понятно.
Щас попробовал блок 16 на 16 точек превратить в одну точку путем нахождения среднеариф. всех цветов (для каждого отдельно).
Все получилось замечательно, только ярксть упала значительно.
Попробовал чисто арифметически ее поднять - результат ухудшился.
---
Размер БМП 2048 на 1536. Размер файла точно 1.7 мега. Закачиваю файлы снаружи по DBGU (115Kбит). Довольно долго. Минуты 3.
Отображаю 480 на 272. 24 бита. Остальное просто складирую.

Так в чем тогда проблема-то? Нам непонятно.

Просто не ожидал, что если оставить одну точку из 256, то изображение останется. А оно - осталось.
Вот в этом и была проблема. Не думал, что решение в лоб, в наглую будет приемлемым.

Так доведите же его до логического конца. Не берите среднее по квадрату 16*16, а в четырех квадратах 8*8, которые составляют этот большой квадрат, не делайте IDCT, а просто возьмите нулевые коэффициенты. И возьмите среднее от них. Это равносильно тому среднему, которое Вы вычисляете.

Ааа, правда, у Вас еще цвет. Я так понимаю, 4:2:2? Ну тогда будет так: для Y - взять среднее из 4х DC-коэффициентов, а для U и V - взять просто соответствующий DC-коэффициент. Не надо делать IDCT, а потом усреднять. Вот и все.

Это тоже понятно теперь. Но у меня коэфициенты уменьшения могут быть разными. Хуже того - могут меняться в процессе. Типа, щас хочу всю посмотреть, а щас хочу середину без уменьшения. Ну, как в просмотрщике фоток. Тогда каждый раз джпег декодировать заново. Хоть IDCT не весь считать, зато хаффмана двигать - весь. А так как памяти - их есть у меня - то буду из бмп скалить. Всё быстрее.

Кроме того у меня исходные джпеги могут быть произвольными. Разных субсамплингов. И вструмливать в алгоритм забубенный скалинг как-то не так.

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

Извиняюсь, если не в тему. А медианная фильтрация не для таких случаев (масштабирование изображения) как раз используется?

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

У меня вообще-то даже не КПК или фотик, а даже простая радиостанция. Чисто обычная CB. Босс приказал встроить возможность просматривания фоток. И типа, заодно, раз уж будешь трахаться, то пусть и МП3 воспроизводит...

Кроче, это вполне левая, чисто маркетинговая функция. Тем более конечная реализация будет не на арме, а я даже еще не знаю на чем.

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

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