Мініатюри графічних файлів
Потрібно зробити програму типу ACDSee. Як краще відображати та робити мініатюри.
Graphic32, ScaleMode = smResize.
Сам страждаю через проблему створення аналога ACDSee (потрібно для застосування на заміну існуючої проги на Clipper). Зробив пробний приклад - виявив, що працює раз на 5 (!) повільніше ACDSee. У форумі "Кололівство Дельфі" кажуть - це проблема GDI і не лікується. До того ж виявив у своєму прикладі баг - при скролінгу в момент завантаження "тумбнайлів" вони потрапляють у довільні місця на формі, хоча дебаггер переконався в правильності завдання координат. Якщо де-небудь знайдеться працюючий приклад - теж був би дуже зацікавлений. Бачив рекомендації використовувати DirectX, але я поки чайник у Дельфі, перегорнув книгу Краснова і зрозумів, що копатися буду дуже довго.
Завантаження через TBitmap досить довге. Потрібно писати свою процедуру завантаження.
Сер MIhey, чи не хочете поговорити в чаті?
ACDSee використовує спеціальну базу даних для мініатюр зображень у якій зберігає зменшені копії у форматі BMP-вже готові для відображення без перетворень/розпакування тощо. Зрозуміти це можна просто змінивши характеристики Thumbnail (обсяг мініатюр наприклад) після чого ACDSee досить довго буде створювати нову кеш базу мініатюр, а згодом швидко працює з вже підготовленими мініатюрами.
Аналог Thumbnail я робив, правда, підтримується тільки BMP-формат, але за аналогією додати будь-який інший проблем не складе. Конкретніше запитуйте у чому проблема, т.к. баги на кшталтНа додаток виявив у своєму прикладі баг - при скролінгу в момент завантаження "тумбнайлів" вони потрапляють у довільні місця на формі, хоча дебаггер переконався в правильності завдання координат.є помилками в коді і без фрагмента вихідникасказати конкретно нічого не можна.
А як вона випереджає, чи не змінився файл?
Найпростіше це звіряти дату створення файлу, його розмір, дату останньої зміни з наявною інформацією в базі, у разі невідповідності проводиться оновлення інформації в базі програми та перемальовування лише необхідних мініатюр. Більш складний варіант полягає в моніторингу "папок, що цікавлять", тобто. пишеться спеціальна служба, що відстежує звернення до файлів і виставляє в базі даних мініатюр вимоги до оновлення зображення, схоже на ACDSee 5.x і вище, застосований такий комбінований підхід.
1. Щодо повільності GDI - це правда, але мені вдалося наздогнати і навіть трохи перегнати ACD See і без DirectX (за масштабуванням, завантаженням і скролігом), причому ACD See теж використовує GDI. 2. У кеш-базі ACD See, мініатюри зберігаються у форматі JPEG, просто ступінь стиснення, а значить і швидкість завантаження можна змінити, зберігання у ВМР не економічне, та й великого приросту в швидкості на сучасних машинах це не дасть. 3. У мене є ідея ДУЖЕ швидкого завантаження мініатюр навіть без кеш-бази, АЛЕ даний принцип працює тільки для JPEG, оскільки заснований на внутрішньому форматі даних, і найголовніше ця ідея ще не випробувана мною.
3. У мене є ідея ДУЖЕ швидкого завантаження мініатюр навіть без кеш-бази, АЛЕ даний принцип працює тільки для JPEG, тому що заснований на внутрішньому форматі його даних, і найголовніше ця ідея ще не випробувана мною.так, читав десь в одній книжці (на кшталт Дарахвелідзt) про те, що JPEG файли дозволяють отримати менше ніж оригінальне зображення швидше, ніж повнорозмірне - це пов'язано з особливостями алгоритму цього стиснення, був начебто приклад, шукати треба. Але для інших форматів цей катер не прокотить :),так бітмапи, TIFF, GIF та інші вимагають повної розпакування зображення в буфер. навантаження добре розподілене між потоками
"так, читав десь в одній книжці (на кшталт Дарахвелідзt) про те, що JPEG файли дозволяють отримати менше ніж оригінальне зображення швидше, ніж повнорозмірне - це пов'язано з особливостями алгоритму цього стиснення"
Ні, я не про це говорю. Те про що ти читав, це збереження мініатюри У ВИГЛЯДІ БІТМАПА у файлі JPEG, не запакованого - це нам не цікаво, так як рідко зустрічається і використовувати дану можливість не економічно для розміру файлу.
Але для інших форматів цей катер не прокотить :), так бітмапи, TIFF, GIF та інші вимагатимуть повного розпакування зображення в буфер.А ти подивися у себе на гвинті який відсоток від загальної кількості зображень займає формат JPEG - я впевнений, що більше 90%.
"IMHO велика перевага ACDSee у правильній багатопоточності проги, за рахунок цього не відчувається "гальм" при роботі, тому що навантаження добре розподілене між потоками"
IMHO, гальма у ACD See - моторошні, і завжди швидше буде виконуватися один потік (наприклад при декодуванні), інша справа - необхідність багатопоточності при створенні мініатюр/галерей зображень.
Mantic0re:1) Напевно все ж таки ти не зовсім мене правильно зрозумів :) Я говорив не про збереження JPEG в бітмап - це робиться дуже просто і всім відомо як, я говорю про інше: якщо зображення 1024x768 зберігається в JPEG, а з неї потрібноотримати картинку розмірами наприклад 100x70 пікселів, тобто можливість відразу отримати з JPEG растр з такою розмірністю, при цьому швидкість розпакування в кілька разів буде вищою ніж при отриманні повнорозмірної картинки, а потім перетворення її до потрібного розміру - ось про що йдеться і в стандарті JPEG спочатку закладалася така можливість, якщо цікаво як це робиться то можу пошукати по книгах і викласти інфу. 2) "Ти програміст, я програміст." них підходить так. цей формат спотворює вихідну картинку - це не завжди влаштовує. 3) А ніхто і не сперечається що один потік виконується фізично швидше ніж кілька на одному процесорі, питання не в чистому швидкодії програми а в суб'єктивному (так як сприймає користувач), так ось на суб'єктивному рівні сприйняття багатопотокові програми (звичайно правильно написані) практично завжди працюють більш "плавно", а звідси виникає відчуття що й швидше. У ACDSee багатопоточність таки використовується під час створення мініатюр, тобто. цей процес виконується у фоновому потоці та дозволяє парралельно нормально працювати з іншими функціями програми без відчутних ривків
CyberStorm: Можеш не шукати книжок - я знаю як це зробити :)
А з приводу: "Ти програміст, я програміст." і дивимося на картинки не так, як наприклад професійні фотомайстри або дизайнери JPEG для них не підходить т.к. цей формат спотворює вихідну картинку - це завжди влаштовує.
Я думаю, що програма "типу ACDSee" (про яку говорилося спочатку) розрахована в більшості своїй на рядового користувача, у якого "на диску більше 90% JPEG". А для професійних фотомайстрівдизайнерів існують професійні програмні продукти, що стоять під тисячу гринів. І якщо на те пішло JPEG дозволяє зберігати зображення і без втрати якості це стиснення називається LossLess JPEG.