Аналог ACDSee по скорости

← →
Ландграф Павел © (2005-05-11 21:16) [0]

вобщем делаю сабж, но не "чтобы было", меня ACDSee полностью устраивает, а делаю типа фотоальбома где будут различные разделы, в том числе и ХХХ где надо ставить пароль и кодировать картинки, но енто все вступление.
Теперь вопрос=) в каталоге более 100 jpeg`ов высоких разрешений, и загрузка каждой фоты около 1~2сек, что напрягает, кешировать не получается, сдуру сделал кеширование 30 фоток, дык енто дело заняло 2 гб оперативки=) Можно конечное кешировать след. и предыдущую картинку по списку в потоке, но а если я захочу тыкнуть не на следующую по списку, а на последнюю, тогда смысл ентого кеширования будет полезен тока в режиме слайд-шоу, но как же сделать быструю загрузку как в ACDSee, вывод делаю через directdraw, так что все упирается в быстрой загрузке текстуры... мож какой юнит jpeg на асме есть?

← →
Gero © (2005-05-11 21:20) [1]

> сдуру сделал кеширование 30 фоток, дык енто дело заняло
> 2 гб оперативки

У тебя, что по картинки по 70 мб?
А вобще кешировать на диске нужно, а не в памяти.

← →
Ландграф Павел © (2005-05-11 21:34) [2]

jpeg в памяти хранится как битовый образ, т.е. те самые 70 мегов!
а смысл кешировать на диске? перегонять в bmp что ли и сохранять для того чтобы не перегонять постоянно из jpeg в bmp?! дык енто глупо, и размеры таких кеш файлов будут как и в памяти по несколько гигов...

← →
Gero © (2005-05-11 21:44) [3]

> jpeg в памяти хранится как битовый образ

Jpeg хранится в памяти так, как захочет программист.

> а смысл кешировать на диске?

Кешировать имеет смысл только уменьшенные копии изображений.

← →
Ландграф Павел © (2005-05-11 21:53) [4]

>Jpeg хранится в памяти так, как захочет программист.
Я имел ввиду в виде загруженных текстур, а текстуры в directdraw хранятся битовой матрицей, конечное есть всякие аппаратные сжатия, но енто уже лишнее в этой задаче.
А хранить jpeg в памяти енто ничего не даст, ибо надо еще раскодировать и загрузить...

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

← →
Deka © (2005-05-12 11:32) [5]

Меньший объем загрузится быстрее - поэтому JPEG. Скорость памяти гораздо выше скорости диска - поэтому хранить в памяти JPEG, а не Bitmap из него полученный. А ACDsee на этом-же фотоальбоме работает так как ты хочешь? Щелкаешь любую картинку и она мгновенно ее разворачивает на экран?

← →
Ландграф Павел © (2005-05-12 17:12) [6]

Да, именно так, так-с..
Тада открываем каталог, запускаем поток, который будет все jpeg`и грузить в память, если их более 100 процедура будет не из быстрых, тада как сделать если открыли каталог и ткнули на последний jpeg в списке, который еще не успел прогрузиться, ведь в ACDsee нет никаких табличек "подождите", хотя можно блокировать скрул со списком файлов до того места где мы успели загрузить... пожалуй так и попробую...
Кстати, в ACDSee если нажать refresh на открытой картинке, то он ее аккуратненько сглаживает (если она открыта в уменьшеном масштабе), какой есть алгоритм чтобы сгладить не с сильным размазыванием, но и быстрый?

← →
programania © (2005-05-12 19:44) [7]

Для ускорения загрузки Jpeg можно использовать
TJPEGScale = (jsFullSize, jsHalf, jsQuarter, jsEighth);
грузить сначала не jsFullSize и показывать все равно большая картинка в экран не влезет,
а потом jsFullSize уже незаметно пока что-то не нажмут
и вначале делать масштабирование не качественно но быстро, а потом уже улучшено
Это заметно и в ACDSee когда картинка через секунду после показа вдруг как-то хорошеет
и все что загружено кешировать в памяти в виде миниатюр
для повторного быстрого некачественного показа и даже сбрасывать на диск или пристраивать к оригиналу.
Это и ACDsee делает когда открывает новую папку, то долго работает с диском
и создает какую-то базу, зато потом быстро открывает и показывает.
Но на современном компьютере С2.8 даже без всех этих ухищрений
картинки в 2500*2000 1.5-2mb показываются меньше чем за 1 сек. со сглаживанием и во весь экран
а с ухищрениями вообще десятые доли,
за это время человек и не заметит что ему подсунули jsEighth и stretchDraw,
а пока рассмотрит уже можно успеть и качественно.

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

← →
XProger © (2005-05-13 03:01) [8]

Ландграф Павел,
Берём в лапки ASM и описание формата JPEG. И вперёд с песней! Если обгонишь по скорости ACDSee - вечная тебе память в сердцах любителей XXX ;)

← →
Sapersky (2005-05-13 11:10) [9]

Берём в лапки ASM и описание формата JPEG. И вперёд с песней!

Есть уже... Intel Jpeg Library называется.

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

попробую, мож правда тормоза из-за долгого доступа к винту...

Аналог ACDSee по скорости Найти похожие ветки