Миниатюры графических файлов.

← →
BlaMyr (2003-11-15 00:51) [0]

Нужно сделать программу типа ACDSee.
Как лучше отображать и делать миниатюры.

← →
Fenik © (2003-11-15 18:00) [1]

TJPEGImage.Scale

← →
Mihey © (2003-11-15 19:21) [2]

Graphic32, ScaleMode = smResize.

← →
Albert (2004-01-17 17:20) [3]

Сам страдаю из-за проблемы создания аналога ACDSee (нужно для приложения на замену существующей проги на Clipper).
Сделал пробный пример - обнаружил, что работает раз в 5 (!) медленнее ACDSee. В форуме "Кололевство Дельфи" говорят - это проблема GDI и не лечится. Вдобавок обнаружил в своем примере баг - при скроллинге в момент загрузки "тумбнайлов" они попадают в произвольные места на форме, хотя дебаггером убедился в правильности задания координат.
Если где-нибудь найдется работающий пример - тоже был бы очень заинтересован. Видел рекомендации использовать DirectX, но я пока чайник в Дельфи, пролистал книгу Краснова и понял, что копаться буду ооочень долго.

← →
Mihey © (2004-01-17 17:27) [4]

Загрузка через TBitmap достаточно долгая. Нужно писать свою процедуру загрузки.

← →
Albert (2004-01-17 17:30) [5]

Сэр MIhey, не желаете ли поговорить в чате?

← →
CyberStorm (2004-01-19 16:03) [6]

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

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

← →
Mihey © (2004-01-19 20:38) [7]

2 CyberStrom:

А как же она опеределяет, не изменился ли файл?

← →
CyberStorm (2004-01-20 07:39) [8]

Самое простое это сверять дату создания файла, его размер, дату последнего изменения с имеющейся информацией в базе, в случае нессответствия производится обновление информации в базе программы и перерисовка только нужных миниатюр. Более сложный вариант заключается в мониторинге "интересующих" папок, т.е. пишется специальная служба отслеживающая обращения к файлам и выставляющая в базе данных миниатюр требования к обновлению изображения, похоже в ACDSee 5.x и выше применен такой комбинированный подход.

← →
Mantic0re (2004-01-20 10:35) [9]

1. Насчёт медленности GDI - это правда, но мне удалось
догнать и даже чуть-чуть перегнать ACD See и без DirectX
(по масштабированию, загрузке и скроллигу),
причем ACD See тоже иcпользует GDI.
2. В кэш-базе ACD See, миниатюры хранятся в формате JPEG, просто
степень сжатия, а значит и скорость загрузки можно изменить,
хранение в ВМР не экономично, да и большого прироста в
скорости на современных машинах это не даст.
3. У меня есть идея ОЧЕНЬ быстрой загрузки миниатюр даже без кэш-базы, НО данный принцип работает только для JPEG, так как основан на внутреннем формате его данных, и самое главное эта идея ещё не опробована мной.

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

← →
CyberStorm (2004-01-20 12:02) [10]

3. У меня есть идея ОЧЕНЬ быстрой загрузки миниатюр даже без кэш-базы, НО данный принцип работает только для JPEG, так как основан на внутреннем формате его данных, и самое главное эта идея ещё не опробована мной.
да, читал где-то в одной книжке (вроде Дарахвелидзt) о том, что JPEG файлы позволяют получить меньшее чем оригинальное изображение быстрее, чем полноразмерное - это связано с особенностями алгоритма этого сжатия, был даже вроде пример, искать надо. Но для других форматов этот катер не прокатит :), так битмапы, TIFF, GIF и другие потребуют полной распаковки изображения в буфер.
IMHO большое преимущество ACDSee в правильной многопоточности проги, за счет этого не ощущается "тормозов" при работе, т.к. нагрузка хорошо распределена между потоками

← →
Mantic0re (2004-01-21 11:09) [11]

2 CyberStorm:

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

Нет, я не об этом говорю.
То о чём ты читал, это сохранение миниатюры В ВИДЕ БИТМАПА в файле JPEG, не запакованного - это нам не интересно, так как редко встречается и использовать данную возможность не экономично для размера файла.

Но для других форматов этот катер не прокатит :), так битмапы, TIFF, GIF и другие потребуют полной распаковки изображения в буфер.
А ты посмотри у себя на винте какой процент от общего количества изображений занимает формат JPEG - я уверен, что более 90%.
Этот формат стал де-факто - ЛИДЕРОМ для хранения изображений фотографического качества (хотя JPEG 2000 - рулит, но его никак не хотят принять :(

"IMHO большое преимущество ACDSee в правильной многопоточности проги, за счет этого не ощущается "тормозов" при работе, т.к. нагрузка хорошо распределена между потоками"

IMHO, тормоза у ACD See - жуткие, и всегда быстрее будет выполняться один поток (например при декодировании), другое дело необходимость многопоточности присутствует при создании миниатюр/галерей изображений.

← →
CyberStorm (2004-01-21 12:21) [12]

Mantic0re:
1) Наверное все же ты не совсем меня правильно понял :)
Я говорил не про сохранение JPEG в битмап - это делается очень просто и всем известно как, я говорю о другом: если картинка 1024x768 хранится в JPEG, а из нее нужно получить картинку размерами к примеру 100x70 пикселей, то есть возможность сразу получить из JPEG растр с такой размерностью, при этом скорость распаковки в несколько раз будет выше чем при получении полноразмерной картинки, а затем преобразования ее к нужному размеру - вот о чем идет речь и в стандарте JPEG изначально закладывалась такая возможность, если интересно как это делается то могу поискать по книгам и выложить инфу.
2) "Ты программист, я программист..." и смотрим на картинки не так, как к примеру профессиональные фотомастера или дизайнеры JPEG для них не подходит т.к. этот формат искажает исходную картинку - это не всегда устраивает.
3) А никто и не спорит что один поток выполняется физически быстрей чем несколько на одном процессоре, вопрос не в чистом быстродейтвии программы а в субъективном (так как воспринимает пользователь), так вот на субъективном уровне восприятия многопоточные программы (конечно правильно написанные) практически всегда работают более "плавно", а отсюда возникает ощущении что и быстрее. В ACDSee многопоточность как раз и используется при создании миниатюр, т.е. это процесс выполняется в фоновом потоке и позволяет парралельно нормально работать с другими функциями программы без ощутимых рывков

← →
Mantic0re (2004-01-22 11:12) [13]

CyberStorm:
Можешь не искать по книжкам - я знаю как это сделать :)

← →
Mantic0re (2004-01-22 11:32) [14]

А по поводу:
"Ты программист, я программист..." и смотрим на картинки не так, как к примеру профессиональные фотомастера или дизайнеры JPEG для них не подходит т.к. этот формат искажает исходную картинку - это не всегда устраивает.

Я думаю что программа "типа ACDSee" (о которой говорилось изначально) расчитана в большинстве своём на рядового пользователя, у которого "на диске более 90% JPEG"..
А для профессиональных фотомастеров или дизайнеров существуют профессиональные программные продукты, стоящие под тысячу гринов.
И если на то пошло JPEG позволяет сохранять изображения и без потери качества это сжатие называется LossLess JPEG.

Миниатюры графических файлов. Найти похожие ветки