Форум SAS.Планета

vdemidov писал(а):Ну если не морочить голову с размерами изображения, тоесть если большой джепег можно распаковать целиком в память, и не писать красивый GUI, то готов написать. Даже с произвольным сдвигом окна. И время работы будет сравнимое со временм иросчета средней якркости и контрастности.

Ну так велкам! Кто там просил-то алгоритма, чего-то его давно не видать...
PS: а как будем обрабатывать, если битмап не лезет в память полностью? Или - возьмем глобальней - если битмап во много раз больше размера ОЗУ?

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

vdemidov писал(а):Я просто не знаю можно ли получить из джепега сколько-то строк изображения не распаковывая целиком все в память.

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

vdemidov писал(а):Что-то не слышно задававшего вопрос. Или он все понял, или это было не слишком нужно

Скорее всего второе.

Только что чуть-чуть почитал про JPG. Там должно быть достаточно просто распаковывать полосками по 8 пикселей:
Цитата из Википедии:

Далее цветовые каналы изображения, включая черно-белый канал Y, разбиваются на блоки 8 на 8 пикселей. Каждый блок подвергается дискретно-косинусному преобразованию.

vdemidov писал(а):Только что чуть-чуть почитал про JPG. Там должно быть достаточно просто распаковывать полосками по 8 пикселей:
Цитата из Википедии:

Далее цветовые каналы изображения, включая черно-белый канал Y, разбиваются на блоки 8 на 8 пикселей. Каждый блок подвергается дискретно-косинусному преобразованию.

А теперь прочитайте написанное ДО и написанное ПОСЛЕ этих строк.

Было бы неверно судить о всем формате лишь по паре строчек из середины алгоритма упаковки оного. Разбиение на блоки - лишь одна из многих операций, не первая и не последняя - и она уже сделана кем-то, и Вы на этот процесс сейчас уже не можете повлиять, если у вас уже готовая картинка именно в ЖПЕГе, в которой картинке Вам и надо искать. Вам придется провести все обратные процедуры, чтобы поиметь все те исходные данные (за минусом потерь, разумеется). То есть - распаковать ЖПЕГ.

Спорить не буду, но думаю получить картинку потоково по 8 строк я бы смог.

vdemidov писал(а):Спорить не буду, но думаю получить картинку потоково по 8 строк я бы смог.

Пробуйте.
PS: Вас не смущает, что даже приведенная Вами цитата оперирует понятием "блока", а не "линией" и уж тем более не "пикселем" - а далее идет общая упаковка всего этого добра? Намекните мне пожалуйста алгоритм выделения из ЖПЕГ-файла ПРЕДПОСЛЕДНИХ 8 линий (Y-16....Y-9 включительно) на 50% их длины (по 25 процентов в обе стороны от центра) без затрагивания\распаковки всего предыдущего\последующего массива (и в идеале - даже без обращения к ЖПЕГ-заголовку)? В БМП/РАВ это всё делается элементарно, например.
Спасибо.

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

vdemidov писал(а):Так что весь вопрос в наличии декодера, который может распаковывать постепенно не храня всю битмапку целиком. Другое дело, что готового я такого не знаю, а искать или писать самому просто не вижу смысла.

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

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

Parasite писал(а):
Впрочем, судя по всему - тема умерла, так как запросившего алгоритм уже давненько тут не видать. Предлагаю пока что закруглить тут с обсуждением, если вопрошающий вдруг появится и продолжит тему - мы все это заметим, и там уж видно будет...

Всем привет. Честно говоря, когда я задал вопрос, то не думал, что решение такое сложное; казалось бы, задача не такая уже и уникальная и нерешаемая: найти рисунок в большем рисунке. Понимаю, что это из области OCR, но ведь это же не новинка. Если действительно нет готового решения, то тогда всем спасибо.

P.S. Если все-таки у кого-нибудь это получится, буду весьма признателен.