Скорость чтения графических форматов

[debi12345]

Согласен - давайте её победим!

теперь главное не торопиться - и потихоньку, по шагам, с бесконечными пробаами и ошибками - ее победить Вы - в мире опен-сорса.

(если торопитесь и хотите иметь полный функционал [tab-controls, autofit/autotile/...], то лучше переключиться на MSE - Мартин испраляет и добавляет как правило за 1..2 дня)

Добавлено спустя 16 часов 31 минуту 11 секунд:
http://www.likan.uz/uploads/tabflick.7z содержит маленький файл - в нем картинка хранится не в битмапе, а в оригинальном формате. Можете проверить на фликер и задержки из-за рантайм-распаковки

[vitaly_l]

Можете проверить на фликер и задержки из-за рантайм-распаковки

Я всё сделал и у меня перестало мерцать, теперь с мерцанием всё в норме. А вот хранение в оригинальном формате без распаковки - это как?...
Пожалуйста, дайте кусочек кода позволяющего хранить, считывать и просматривать в оригинальном формате?
(либо я просто не понимаю в чём суть понятия: оригинальный формат...)

Кроме того остался без внимания: самый главный вопрос:
Как программисты например XnView - умудряются считывать и выводить jpg весом более 10 Mb,
в 50 раз быстрее чем это делает TImage.Picture.LoadFromFile(); или подобная команда в TBGRABitmap...???

.

[alexey38]

Как программисты например XnView - умудряются считывать и выводить jpg весом более 10 Mb,
в 50 раз быстрее чем это делает TImage.Picture.LoadFromFile(); или подобная команда в TBGRABitmap...???

Ответ общего плана очень простой, в тех утилитах используется более совершенный код и алгоритм декодирования JPEG. Вот и все.
В свое время (было лет 8 назад, компы были слабые) как-то обратил внимание, что разные просмоторщики дают разный вид одних и тех же фоток. Как-то смотрел на ACDSee фотки, и вижу, что они какие-то стремные, хотя смотрятся быстро. Открыл их же в просмоторщике от XP, открывалось раз в 10 (а может и в 50) медленнее, но качество было нормальным. Возможно, что в ACDSee были опции, регулирующие баланс между качеством и скоростью, но разбираться не стал, тем более за ACDSee хотят деньги. Я это к тому, что алгоритмы чтения бывают разные. Учитывая, что Вам для просмотра нужен не оригинал изображения, а его масштабированная копия, то тут возникает целая куча алгоритмов, например, можно вначале сформировать полномасштабное изображение, а затем его самым крутым алгоритмом смаштабировать, а можно сразу масштабировать при чтении, причем существует десяток алгоритмов масштабирования.

[vitaly_l]

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

Я так и думал. Вот только как масштабировать изображение, после прочтения я понимаю, а вот как масштабировать до или во время прочтения?

В QT, как выяснилось - для это есть специальный класс QImageReader. Наверняка и для Pascal такую удобную функцию уже давно написали и наверняка есть компонент для Лазаруса. Вот только как этот компонент найти? Поиск не помогает. Уверен кто нить уже сталкивался. Прлииииз отзовитесь - такой компонент многим нужен .

Спасите/помогите

[debi12345]

Я всё сделал и у меня перестало мерцать, теперь с мерцанием всё в норме.

Причем с таб-страницами

либо я просто не понимаю в чём суть понятия: оригинальный формат

Грубо говоря:
Было:
Назначаем TImage.bitmap:= JPEG-file 100KБайт => автоконвертися в bitmap 5Мбайт => все это садится в ресурсы exe-файла = > имеем exe-файл 5+ МБайт.
Стало:
Назначаем TImage.bitmap:= JPEG-file 100KБайт => это садится в ресурсы exe-файл = > имеем exe-файл 100+ КБайт => конверсия в битмар при загрузке программы.

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

В моем тест-примере используется аавтомасштабирование. Если его скорость и качество Вас устаивает, то посмотрите код MSEgui при задействовании опции TImage.bitmap.alignment += al_fit.

[vitaly_l]

конверсия в битмар при загрузке программы

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

Если его скорость и качество Вас устаивает

Наверно максимально правильно описать задачу так. ===> Меня качество изображений почти вообще не интересует, одну качественную картинку можно и подождать загрузку... мне по существу - нужно быстро получить много иконок изображений и форматы у меня разные, а не только jpeg.
PS: я же - художник , не бейте меня сапогами, я всё прощу ...


.

[debi12345]

Это безусловно увеличивает скорость работы с картинкой, но замедляет скорость запуска программы

Думаю, что выигрыш 4+Мбайт/1_большая_картинка_картинка (фон, сплэшскрин,..) размера файла программы стОит замедления 0.1 секунды замедления при загрузке.

[vitaly_l]

размера файла программы стОит замедления 0.1 секунды замедления при загрузке.

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


.

[debi12345]

Нужно максимально быстро получить много иконок больших изображений, а не сохранять эти изображения в файле

Создать много TImage умеющих эффективно данусамплить/ресайзить. Домучаете эту (оптимизацию TImage) тему БЕЗ ТРЮКОВ, ХИТРОСТЕЙ И УПРОЩЕНИЙ (тип отказа от табов) - сообщество скажет большое спасибо

[alexey38]

Вот только как масштабировать изображение, после прочтения я понимаю, а вот как масштабировать до или во время прочтения?

Чтение в память 10 Мб файла на современном компе - это мгновение, доля секунды. А вот разбор файла - тут уже нужно выбирать алгоритмы.

Добавлено спустя 1 минуту 26 секунд:

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

То есть Вам нужны некие preview, тогда нужен алгоритм упрощенного парсинга графического формата.

[debi12345]

В Вашем случае нужно наверное оптимизировать TImageList.

А вот разбор файла - тут уже нужно выбирать алгоритмы.

XnView 100% использует префетч (фоновую загрузку и масштабирование).

Добавлено спустя 2 минуты 1 секунду:

тогда нужен алгоритм упрощенного парсинга графического формата.

На все форматы не напасешься. Есть построчно декодирууемые, а есть и те,что декодируются целиком.

Добавлено спустя 3 часа 11 минут 41 секунду:
Посмотрел, что делает XNView когда заходит в новую папку с картинками :
- он даунсэмплит (ресайзит) их не отображая, и сделанные превьюшки вместе с путями к файлам заносит в специальную SQLITE3 БД, и отображает превьюшки уже из этой БД.

Вот и весь секрет Вы хотите такой огород городить ?

Добавлено спустя 50 минут 7 секунд:
Хм.. универсального быстрого ресайзера на все форматы нет, лучший из них - нефришный от Интела. Хотя некотрые форматы (например JPEG) позволяют заказать коэффицинт уменьшения до загрузки файла-картинки - напрмер через параметр вызова к форматной DLL.

Добавлено спустя 19 минут 42 секунды:
http://www.likan.uz/uploads/manyimages.zip содержит прогу для превьюинга JPEG-ов в текущем каталоге программы. Наверное это максимум на что спсобны FP{image}-юниты (Мартин пришет что они далеко не идеальны по части пиксельного доступа). Также стандарный подход (внутренняя TImage-конверсия в BMP с ресайзингом на канвасе) приводит к огромным затратам RAM (распаковка JPEG-2-BMP) - это тестовая прога жрет 150М на 45-ти 100К JPEG-ах.

[vitaly_l]

(ресайзит) их не отображая

Я немного про другое, если Вы станете смотреть в XnView большие изображения полноэкранно, то легко заметить, что задержки при переключении от одного изображения к следующему в XnView - практически незаметно. Если такой-же полноэкранный движок сделать из одного только Timage, то загрузка тех-же файлов - будет заметно медленнее. Возможно дело в масштабировании, но я пробовал: не масштабировать и не выводить изображения, и всё равно загрузка - происходят медленнее, чем у XnView. Очевидно априори заложена какая-то распаковка и медленная дешифровка. А мне действительно ПРИНУДИТЕЛЬНО - нужно сделать множество маленьких изображений, например из 1000000 изображений(про иконки я просто привёл аналогию - наверняка люди уже готовили подобное), тобиш - множество уменьшенных картинок - это целевая функция и больше всего времени тратится именно на чтение и распаковку файла в битмап. Хотя с другой стороны, XnView и тот же Windows - довольно долго делают иконки, когда их заставляешь их готовить принудительно. Но большие изображения они читают быстрее. Дело наверно, в алгоритме интерпретации.

Скорее всего для Лазаруса, есть независимые компоненты наподобии QImageReader, для QT- говорят он моментально превращает изображения в маленькие изображения. Значит и Лазарус может, т.к. машинные коды - одинаковые и всё зависит только от грамотности алгоритма. Я в графических алгоритмах - слаб и умею только основываться на готовых решениях.

Тобишь, мне нужен уже готовый компонент не основанный на TPicture, а имеющий своё начало <== вот его-то я и ищу.


.

[debi12345]

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

XNview очевидно создает (специальным встренным конвертером) маленькие превьюшки и заносит их как BLOB-поля в БД. Видимо такжен вычисляет и запоминает там же хэши файлов - чтобы обнуруживать их изменения и персоздавать превьюшки. Отоброажает првьюшки уже из этих маленьких BLOB-ов - это кроме ускорения отрисовки позволяет экономить ОЗУ. Также XNview рисует првьюшки асинхронно - возможно в отдельных трэдах, поэтому нет глобального "белго экрана ождидания". Конвернул большую картинку в превью, запсал превью в БД и тут его (уже маленький) отобразил.

А мне действительно ПРИНУДИТЕЛЬНО - нужно сделать множество маленьких изображений

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

Добавлено спустя 2 минуты 52 секунды:

Но большие изображения они читают быстрее. Дело наверно, в алгоритме интерпретации.

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

[vitaly_l]

Тогда лучше реально использовать БД для хранения контента этих изображений

Это было бы слишком просто, чтобы задаваться этим вопросом на форуме. Мне нужно конвертировать каждый раз новые.

генерацию превью, а где ее можно сделать в фоновом режиме

Не делает XnView, preview больших изображений - это было-бы слишком накладно для хранения на диске.

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

Всем: заранее и постфактум - благодарен
.

[alexey38]

Я немного про другое, если Вы станете смотреть в XnView большие изображения полноэкранно, то легко заметить, что задержки при переключении от одного изображения к следующему в XnView - практически незаметно. Если такой-же полноэкранный движок сделать из одного только Timage, то загрузка тех-же файлов - будет заметно медленнее. Возможно дело в масштабировании, но я пробовал: не масштабировать и не выводить изображения, и всё равно загрузка - происходят медленнее, чем у XnView. Очевидно априори заложена какая-то распаковка и медленная дешифровка. А мне действительно ПРИНУДИТЕЛЬНО - нужно сделать множество маленьких изображений, например из 1000000 изображений(про иконки я просто привёл аналогию - наверняка люди уже готовили подобное), тобиш - множество уменьшенных картинок - это целевая функция и больше всего времени тратится именно на чтение и распаковку файла в битмап. Хотя с другой стороны, XnView и тот же Windows - довольно долго делают иконки, когда их заставляешь их готовить принудительно. Но большие изображения они читают быстрее. Дело наверно, в алгоритме интерпретации.

То, что я Вам говорю и то, что Вы пишите - это примерно про одно и то же. Условно говоря нужно понять, что TImage не для Ваших целей. И нет ни какого смысла типовой и простой компонент замусоривать узкоспециализированной функцией быстрого парсинга и масштабирования.
Условно говоря Вам нужен некий TSuperImage который считает картинку, и Вы сделаете Draw в TImage для отображения уже нужного Вам формата.

Собственно наличие утилит типа XnView, ACDSee и т.п. говорит о том, что стандартные компоненты не годятся. И тут либо Вам самим все написать, либо искать платную или бесплатную библиотеку. И скорее всего ее не будет на паскале. Но это не страшно, можно найти библиотеку в виде DLL, или сделать DLL на С++ или ином языке. Я для себя сишную матричную математику так прикручивал к паскалю.