Посоветуйте алгоритм масштабирования, в сторону уменьшения Опции

[DpInRock]

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

[Rst7]

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

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

[DpInRock]

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

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

[DRUID3]

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

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

[Rst7]

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

5 секунд занимает преобразовать 1.2 мега джпег в RGB.

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

[DpInRock]

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

Сообщение отредактировал DpInRock - Apr 26 2009, 16:40

[Rst7]

Это-то все понятно.

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

[DpInRock]

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

[Rst7]

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

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

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

[DpInRock]

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

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

[Rst7]

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

[rezident]

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

[DpInRock]

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

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

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

[dch]

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

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

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

Причина редактирования: Излишнее цитирование.