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

[debi12345]

И пока ещё рано говорить, что виновата перекодировка, т.к. это не подтверждено.

Виновата - проверено перекодировкой внешними утиллитами (почти самыми лучшими). Безо всякой отрисовки имеем задержки в пол-секунды на один файл.

Клоузсорный софт одако как-то выкручивается - XNview, или http://www.mediaresizer.com/. Жуть как интересно - как они это делают ?

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

Это именно TStream и TFileStream - тормозят загрузку!

Код: Выделить всё

TFileStream.Create(UTF8ToSys('любая картинка2000x2000px.любое расширение'), fmOpenRead or fmShareDenyWrite)

??? Секундные IO-задержки на современных машинах с винтами 150+ MB/sec, большими кэшами и т.п. ?
"Винт" случайно не в PIO-режиме ?

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

UTF8ToSys

Это зачем ? Во 1-х не нужно. Во 2-х - UTF8-конверсия весьма ресурсроемка.

[vitaly_l]

"Винт" случайно не в PIO-режиме ?

пардон, это была ошибка(наверно лазарус не пересчитал проект) - на самом деле Tstream грузится моментально.

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

Безо всякой отрисовки имеем задержки в пол-секунды на один файл.

Это правда - это нужно как-то починить...

[Kemet]

Действительно, Лазарус здесь медленнее на порядок.
Скорее всего затык происходит даже не при распаковке графических форматов, а при размещении результата в памяти.

Добавлено спустя 33 минуты 38 секунд:
Думаю, имеет смысл исследовать графическую библиотеку Vampyre Imaging Library

[vitaly_l]

Vampyre Imaging Library

Они тоже используют, для загрузки - стандартный TGraphic и TPicture - которые собственно и тормозят >>>на порядок...<<< при загрузке.
Неужели нет ни одной самостоятельной независимой библиотеки?
Я самый несчастный в мире Карлсон. Неужели ни у кого нет для меня трёхлитровой баночки вкусного варенья?
Неужели нет ни одной самостоятельной независимой компоненты?

.

[debi12345]

ИМХО, здесь поможет только использование форматно-зависимых понижающих алгоритмов, и на их выходе грузить уже маленькие битмапы в Timage (а раз маленькие де еще готовые битпамы, то и тормознутость TImage никак не скажется).
Кто скажет, какой из опенсорсных (чтобы глянуть в исходники) вьюеров умеет мгновенно рисовать превьюшки, причем для многих форматов ?

[Kemet]

Неужели нет ни одной самостоятельной независимой библиотеки?
Неужели нет ни одной самостоятельной независимой компоненты?

Что значит самостоятельной независимой...
От чего независимой?
Чтобы оперировать графикой разных форматов ее все равно придется считать в битмап (распаковать).
Можно этот процесс несколько оптимизировать, но полностью его исключить не получится. С учетом, что в Дельфи оно вполне нормально работает, в отличии от Лазаруса, то нужно брать напильник.
В принципе, есть же модули
FPReadJpeg, ... Tiff, ...Gif ...
которые и занимаются этим напоямую

[debi12345]

Можно этот процесс несколько оптимизировать,

Для достижения реал-тайм-филинга - не несколько, а в десятки раз

[vitaly_l]

Что значит самостоятельной независимой...
От чего независимой?

Независимой от Timage, точнее от TPicture, т.к. загрузкой распоряжается он.
И все подгружаемые модули - тоже используют родителем TPicture, а TPicture при загрузке тормозит.

[alexey38]

Независимой от Timage, точнее от TPicture, т.к. загрузкой распоряжается он.
И все подгружаемые модули - тоже используют родителем TPicture, а TPicture при загрузке тормозит.

Вопрос. Если Вы заранее с помощью отдельной утилиты или графического редактора сделаете картинки строго того размера, как конкретный TImage или TPicture у Вас на форме, то тоже тормозит? Насколько мой старый опыт (10-15 летней давности) говорит, что работа без масштабирования была быстрой еще тогда. Насколько я знаю, очень медленно реализовано масштабирование, а собственно вывод он очень быстрый.

[vitaly_l]

собственно вывод он очень быстрый

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

И, ввиду того что - любой (из 12 пересмотренных) компонентов является child для TPicture, то
поэтому тормозят(вдвое по отношению к другим IDE) именно при загрузке - абсолютно все графические компоненты.
Так незаметно, а когда нужно загрузить 100-1000 изображений, это торможение очень весомо...

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


.

[alexey38]

Нет. Скорость уже проверяли на нескольких машинах см. топик выше.

Я говорю немного о другом. Вы на форму ставите TImage с размером, например, 800 х 800. И делаете картинки в формате BMP тоже строго 800 на 800, ни 801, ни 799, а именно такие размеры, какие в точках указали для TImage. И делаете испытания в данных конкретных условиях, когда размер изображения в файле на 100% совпадает с размером компоненты на форме. Попробуйте такой частный случай на предмет быстродействия. В Дельфи 10-15 лет назад на компе с частотой 200 МГц с видеокартой на 4 Мб у меня это все работало довольно быстро, а просмотр фотографий (JPEG) тогда был медленным, каждая картинка открывалась 2-5 сек. А если была большая, то и все 10 сек.

[haword]

TPicture не родитель. Родитель TFPImageBitmap. Может я не все прочитал но ты не пробовал загрузить картинку не в TPicture а в TBitmap или TJPegImage и потом уже перенести картинку распакованную на TPicture? Попробуй для тестов открой картинку в TBitmap и засеки время на открытие, потом прорисуй ее на канве формы просто через Form1.Canvas.Draw и засеки время на чем тормоза.

[vitaly_l]

В TBitmap пробовал - результат тот же.
Даже не выводя на Canvas - все графические форматы в Лазарусе тормозят при загрузке в два и более раз.
Проверяется просто. Берётся одна картинка 1000х1000px и перезагружается сто раз (без вывода на Canvas ).
А для сравнения скорости берётся таже картинка и загружается любым известным вьювером и наблюдается что,
даже при условии что, вьювер - отображает картинку, а TBitmap нет - скорость чтения в два и более раз превышает.
И это признали несколько человек. Как так получается?

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


.

[alexey38]

Берётся одна картинка 1000х1000px

1. Какой формат картинки?
2. Пробовали ли делать BMP без компрессии? Размер файла тогда должен быть равен строго 3 000 054 байта (1000*1000*3 + заголовок).
2. После считывания из файла в TImage, TBitMap и др. какие значения полей width и height Вы имеете?

[SeZuka]

По умолчанию jpeg грузится по алгоритму оптимизированному на качество, попробуй примерно так:

Код: Выделить всё

uses
  FPReadJPEG;

{ TForm1 }

procedure TForm1.Image1Click(Sender: TObject);
var
  JPEGImage: TJPEGImage;
begin
  if OpenPictureDialog1.Execute
  then begin
    JPEGImage := TJPEGImage.Create;
    try
      JPEGImage.Performance := jpBestSpeed;
      JPEGImage.LoadFromFile(OpenPictureDialog1.FileName);
      Image1.Picture.Graphic := JPEGImage;
    finally
      JPEGImage.Free;
    end;
  end;
end;


Хотя я особой разницы в скорости не заметил.

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

TStream - тот еще тормоз, попробуй в TFileStrem сделать побайтовое чтение файла для парсинга, успеешь выпить кружку кофе.
Плюс к этому после открытия изображение целиком хранится в памяти в битовом формате (bitmap).
Я тестировали на изображении 10240х7680 размером, в jpeg файл весит 8.5Мб, а в bmp ~750Мб, так вот при открытии этого jpegа, объем памяти занимаемой приведенной выше прогой доходил до ~1.5Гб, после открытия, когда картинка уже показалась на форме, уменьшался до ~750Мб, а при повторной попытке открыть этот же файл, уже вылетает Out of memorry
Хотя при открытии этого же jpega в стандартном просмотрщике Windows, открывается также долго, при открытии доходит до ~500Мб занимаемой памяти, а потом падает до <30Мб и уже после этого можешь его масштабировать, двигать, размер в памяти практически не меняется.
В общем дело тут все в ООП, универсальности и погоне за совместимостью с Delphi, никаких особых оптимизаций в коде компонентов не делается.