Наиболее быстро изменить размер Bitmap-а (уменьшить).

← →
DVM © (2006-11-21 10:11) [0]

Как наиболее быстро изменить размер Bitmap-а? Скорость стандартного StretchBlt не совсем устраивает. Можно ли обогнать StretchBlt и если да, то как?
Может кто занимался подобным. Можно ли привлечь для масштабирования SSE, MMX и прочие наборы инструкций? Если кто знает, расскажите как.

← →
clickmaker © (2006-11-21 10:17) [1]

DirectDraw?

← →
KilkennyCat © (2006-11-21 10:21) [2]

TBitmap.Width := ...
TBitmap.Height := ...

← →
DVM © (2006-11-21 10:23) [3]

> KilkennyCat © (21.11.06 10:21) [2]

Это отсечение, а не масштабирование.

← →
DVM © (2006-11-21 10:23) [4]

> clickmaker © (21.11.06 10:17) [1]

DirectDraw, сам по себе как мне кажется скорости не прибавит. Мне нужно просто масштабирование, без вывода на экран. Я с DD знаком мало, там есть функции масштабирования более быстрые, чем StretchBlt? Идеальным бы вариантом оказалось использование аппаратной поддержки со стороны видеоадаптера (он наврняка умеет, такая мощь простаивает). Но как этим воспользоваться?

← →
WondeRu © (2006-11-21 10:26) [5]

http://rsdn.ru/forum/Message.aspx?mid=2201982 тут обсуждается

← →
KilkennyCat © (2006-11-21 10:29) [6]

> Это отсечение, а не масштабирование.

неправда. это
> наиболее быстро изменить размер Bitmap-а?

а если менять картинку, то зависит от алгоритма.

> Идеальным бы вариантом оказалось использование аппаратной
> поддержки со стороны видеоадаптера (он наврняка умеет, такая
> мощь простаивает). Но как этим воспользоваться?

DirectDraw... но не все видеокарты реализуют аппаратный StretchBlt.

← →
DVM © (2006-11-21 10:37) [7]

> неправда. это

Я не смотрел реализацию TBitmap.Width := ... и TBitmap.Height := ... в VCL, но что-то мне подсказывает, что за ними скрывается то же StretchBlt :)
Это вряд ли быстрее.

← →
DVM © (2006-11-21 10:39) [8]

> KilkennyCat © (21.11.06 10:21) [2]

Неправ я. Оказалось чуть-чуть быстрее. Но настолько незначительнее, что овчинка выделки не стоит.

← →
DVM © (2006-11-21 10:44) [9]

> KilkennyCat © (21.11.06 10:21) [2]

Только все же TBitmap.Width := ... и TBitmap.Height := не масштабируют - они обрезают лишнее. :)

← →
Barloggg (2006-11-21 10:51) [10]

из под винды аппаратно ускоренный есть bltfast на прямом WinApi, но масштабирования он не держит.
к тому же там вагон параметров в типе TBltFx с поганой документацией.

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

← →
clickmaker © (2006-11-21 10:51) [11]

> Только все же TBitmap.Width := ... и TBitmap.Height := не
> масштабируют - они обрезают лишнее

если через TImage и включено Strecth, то масштабируют

← →
DVM © (2006-11-21 10:57) [12]

> clickmaker © (21.11.06 10:51) [11]

Не, ни о каком TImage речь не идет. Медленно и тяжеловесно.

> Barloggg (21.11.06 10:51) [10]

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

У меня в огромном количестве образуются картинки (получаются по сети). Они не того размера, какой нужен. Размер надо преобразовывать и возможно их отображать потом. Это я так понимаю подпадает под определение "единичные операции"?

← →
atruhin © (2006-11-21 11:46) [13]

Посмотри GraphicEx, там несколько способов масшабирования, может будет быстрее.

← →
Думкин © (2006-11-21 12:12) [14]

> DVM © (21.11.06 10:44) [9]

Но размер они меняют, что и требовалось в сабже.

← →
DVM © (2006-11-21 13:00) [15]

> Но размер они меняют, что и требовалось в сабже.

Буквоедство это. В том же сабже указано StretchBlt. Речь о масштабировании. Русский язык богат и неоднозначен.

← →
Sapersky (2006-11-21 13:39) [16]

StretchBlt требуется с фильтрацией или без?
Если с фильтрацией, FastLIB"овский Bilinear быстрее, хотя и даёт несколько худшее качество (видимо, сам алгоритм проще). Если без (FastResize) - скорость примерно та же, что и у StretchBlt.
Насчёт единичных операций - да, от DDraw в такой ситуации будет мало пользы. Разве что хранить в том размере, который пришёл, и делать stretch непосредственно при выводе.

← →
DVM © (2006-11-21 14:12) [17]

> StretchBlt требуется с фильтрацией или без?

Не фильтрация необязательна.
Т.е.
SetStretchBltMode(Canvas.Handle, COLORONCOLOR); Для StretchBlt

Вобщем я пришел к выводу, что не обогнать StretchBlt.
Попробовал и DrawDibDraw() и INTEL Image Processing Library - все медленнее, чем StretchBlt с COLORONCOLOR;

Результат для 100 повторов на некоторой картинке:

StretchBlt - 281 тиков
DrawDibDraw - 625 тиков (хотя это скорее подготовительные операции)
INTEL Image Processing Library - 844 (тоже подготовка дольше, чем обработка)

← →
DVM © (2006-11-21 14:15) [18]

Для StretchBlt + HALFTONE - 1547 тиков.

← →
Sapersky (2006-11-21 14:47) [19]

Сейчас потестировал - FastResize оказалась быстрее... (когда тестировал в прошлый раз - комп был другой, возможно в этом дело).
http://sourceforge.net/project/showfiles.php?group_id=173551

← →
DVM © (2006-11-21 15:53) [20]

> Sapersky (21.11.06 14:47) [19]

Для FastResize результат - 79 тиков. Однако.

← →
Pavia © (2006-11-22 00:30) [21]

Быстрее всего будет если на ассемблере написать. Немогу точно сказать будетли прирост от MXX и SSE нужно пробовать.

Насчет DDraw не все видео карты поддерживают маштабированный вывод для спрайтов, но можно задействовать 3D рэндринг. Правда скорее всего если боддерживался то виндоус его бы использовал. И можно было бы маштабировать через BitBlt(не помню точно).
Так вот для аппоратного ускорения нужно делать 3D рэндринг использовать Direct3D. Но аппоратный вывод он долгий из за всяких простоев.
Незнаю как в DirectX но в OpenGL есть функция GlFlush для того чтобы была возможность немедленно скинуть результат обработки из видео памяти. Кто то сказал что передача в видео память операция медленная. Это зависет от компьютера если брать AGP8 то 66МГц что в 6 раз медленнее памяти. А если EPCI-16 то 1056МГц что наровне с памятью компьютера.

← →
Eraser © (2006-11-22 01:54) [22]

> [21] Pavia © (22.11.06 00:30)

Стандартная Bit/StretchBlt тоже уже аппаратно-ускоренная на сколько это возможно, получить более быстрый результат проблематично.

← →
DVM © (2006-11-22 10:17) [23]

> Eraser © (22.11.06 01:54) [22]

Обогнать в плане вывода на экран - да вряд ли возможно. Тут BitBlt вне конкуренции. А вот изменение размера у StretchBlt сделано не самым быстрым способом. У FastDIB FastResize в 3 раза быстрее. На нем и остановился. Вообще FastDIB удобнее в использовании, чем стандартный TBitmap из VCL. В нем есть все то, чего мне не хватало в TBitmap.

← →
Sapersky (2006-11-22 13:46) [24]

Стандартная Bit/StretchBlt тоже уже аппаратно-ускоренная на сколько это возможно

Аппаратно-ускоренной реализации StretchBlt я ещё не встречал. См. ссылку на rsdn из [5] - там человек пишет, что теоретически её можно ускорить, но практически, по моему опыту, производители драйверов почему-то этого не делают. Для подтверждения опыта я выкладывал пример - хотя скорость он иногда меряет криво, преимущество DirectDraw в stretch по нему видно невооружённым глазом.

Вообще FastDIB удобнее в использовании, чем стандартный TBitmap из VCL

Угу, я уже почти забыл, что такое TBitmap :)
Хотя есть у FastLIB и свои недостатки, слабая устойчивость к ошибкам, например (шаг влево, шаг вправо - AV).

← →
Eraser © (2006-11-23 19:57) [25]

> [24] Sapersky (22.11.06 13:46)

> Аппаратно-ускоренной реализации StretchBlt я ещё не встречал

ошибаешься, удали фирменный драйвер видеокарты и поставь стандартный, увидишь, что значит Blt- фции без аппаратного ускорения )

← →
Eraser © (2006-11-23 20:00) [26]

к слову у меня StretchBlt + HALFTONE работает намного быстрее и меньше жрет проц, чем остальные режимы StretchBlt.
почему? сам не знаю.

← →
DVM © (2006-11-24 10:43) [27]

> к слову у меня StretchBlt + HALFTONE работает намного быстрее
> и меньше жрет проц, чем остальные режимы StretchBlt.
> почему? сам не знаю.

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

← →
Sapersky (2006-11-24 14:57) [28]

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

В смысле, они ещё больше будут тормозить, чем с фирменными драйверами? Ну это само собой, но я не о том. Я о том, что какие фирменные драйвера ни ставь, StretchBlt всё равно будет работать по крайней мере отчасти софтверно. Т.е. медленнее surface.Blt.

Хотя вот это:

к слову у меня StretchBlt + HALFTONE работает намного быстрее и меньше жрет проц, чем остальные режимы StretchBlt.

может указывать на то, что чудеса иногда случаются :) Дело в том, что во всех аппаратных реализациях DirectDraw-stretch, которые я видел, HALFTONE прошит намертво и никак не отключается (хотя это не совсем то, что софтверный HALFTONE, качество несколько хуже). Т.е. если HALFTONE быстрее, StretchBlt в этом случае, возможно, работает аппаратно.

Если интересно, можешь проверить это предположение (тест-exe, 160 кб):
http://slil.ru/23461557

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

Может, имелся в виду вывод на экран, т.е. "обратно" не надо. А DDB-битмап, как говорили на rsdn (и это, в общем, подтверждается опытами), может жить в видеопамяти.

> Sapersky (24.11.06 14:57) [28]

> Если интересно, можешь проверить это предположение (тест-
> exe, 160 кб):
> http://slil.ru/23461557

А можно исходник данного теста?

← →
Sapersky (2006-11-27 14:26) [30]

http://slil.ru/23476254

> Sapersky (27.11.06 14:26) [30]

Спасибо

DDraw почти в 3 раза медленне FastDIB из за долгой загрузки Bitmap-a.
Если без загрузки то раз в 5 быстрее.

>Посмотри GraphicEx, там несколько способов масшабирования, может будет быстрее.

У них очень хорошие алгоритмы, кстати. Рекомендую. У себя из них переписанный на асм делал для больших изображений.

Самый быстрый способ:
строится матрица координат, два массива линий получающегося изображения в координатах исходного. Т.е. откуда брать точки из исходного массива.
Дальше идут вложенные циклы по оси х, и у, для каждой линии х и у выбираются согласно предварительно рассчитанным координатам точки из исходного битмапа-сырья.
Скорость очень высокая, mmx/sse здесь не поможет, т.к. считать особо нечего, только пересылки.
Качество, конечно, от скорости страдает, но в моём случае, работая с большими картинками не критично, у меня изображения достаточно монотонные (или как это сказать)? Отбрасывание 3/4 точек почти не заметно.
Есть у них же похожие алгоритмы, но со сглаживанием.

Посмотрел rsdn:

>В варианте видео->видео DirectDraw, по моим тестам, быстрее GDI в десятки-сотни раз

Здесь тоже, мягко говоря, не всё так просто. Для того, что бы изображение отстретчить, его нужно в видеопамять перегнать, а это процесс. Это хорошо, когда изображение одно, а когда их отстретченных на экране штук 20, и все изначально метров по 40-50, последовательно - agp не выдерживает, параллельно - видеопамяти не напасёшься. Я у себя недавно именно из-за этого второй 2d движок писал. Для мелких изображений всё ок, а вот когда по agp начинаешь гонять гигабайты, тут она и помирает. А хочеться полёта... ;)
Вот и приходится предварительно в обычной памяти масштабировать, а потом уже в видео перикидывать и отображать как есть. Так что, обычный процессор, без gdi и дайректа, может работать не хуже последного. Качество, правда, страдает, видюхи хардварно сглаживают хорошо и быстро, что есть, то есть...

← →
Pent (2006-11-28 15:24) [35]

Где-то у вас ошибка в тесте.. На моем компьютере StretchBlt быстрее, чем FastResize, чуть ли не на порядок. Даже с интерполяцией. Это при условии, что отрисовка происходит сразу на экран, а если на другой Bitmap, то скорости должны быть примерно одинаковыми.

← →
Pent (2006-11-28 15:26) [36]

А использование DirectX не для игр мало когда оправдано, не в последнюю очередь из-за вопросов совместимости имхо.

> Pent (28.11.06 15:24) [35]
> Где-то у вас ошибка в тесте.. На моем компьютере StretchBlt
> быстрее, чем FastResize, чуть ли не на порядок. Даже с интерполяцией.
> Это при условии, что отрисовка происходит сразу на экран,
> а если на другой Bitmap, то скорости должны быть примерно
> одинаковыми.

Не верю. :) Что за видеокарта? Какие драйвера, какая ОС?

В каком тесте?

FastResize не выводит на экран - она с битмапа на битмап масштабирует.
После результирующий битмап надо BitBlt куда надо.

← →
Sapersky (2006-11-28 19:50) [38]

Сейчас обнаружил, что скорость StretchBlt с COLORONCOLOR имеет не вполне очевидную зависимость от глубины цвета, 32 bpp в 7-8 раз быстрее чем 24 bpp. А я раньше тестировал 24...
При выводе на экран в таком варианте StretchBlt немного быстрее FastResize, при масштабировании в другой битмап - наоборот.
Чтоб одновременно всё-всё сравнить, прикрутил FastLIB к своему тесту:
http://slil.ru/23483988
(исходник)

> Sapersky (28.11.06 19:50) [38]

Прикрути еще DrawDIBDraw из vfw:

procedure DDDraw( Canvas: TCanvas; dTop, dLeft, dHeight, dWidth: Integer; Bitmap: TBitmap); var lpBits : Pointer; pBmpInfo: PBitmapInfo; nColors : Cardinal; hdd : HDRAWDIB; BitmapStream: TMemoryStream; procedure SetSize; var RatioH, RatioW : Extended; begin with pBmpInfo^.bmiHeader do begin if ( biWidth > dWidth ) or ( biHeight > dHeight ) then begin RatioH := dHeight / biHeight; RatioW := dWidth / biWidth; if RatioH > RatioW then RatioH := RatioW; dHeight := Trunc( biHeight * RatioH ); dWidth := Trunc( biWidth * RatioH ); Exit; end; dHeight := biHeight; dWidth := biWidth; end; end; begin if Bitmap = nil then exit; BitmapStream := TMemoryStream.Create; Bitmap.SaveToStream(BitmapStream); pBmpInfo := PBitmapInfo( PChar( BitmapStream.Memory ) + SizeOf(TBitmapFileHeader) ); with pBmpInfo^, bmiHeader do begin if biClrUsed = 1 then nColors := biClrUsed else nColors := ( 1 shl biBitCount ); if biBitCount > 8 then begin lpBits := PChar( @bmiColors ) + Ord( biClrUsed ) + Ord( biCompression = BI_BITFIELDS ) * 3; end else lpBits := PChar( @bmiColors ) + nColors; hdd := DrawDibOpen; try DrawDibRealize( hdd, Canvas.Handle, True ); SetSize; DrawDibDraw( hdd, Canvas.Handle, dLeft, dTop, dWidth, dHeight, PBitmapInfoHeader( @bmiHeader ), lpBits, 0, 0, biWidth, biHeight, DDF_HALFTONE ); finally DrawDibClose( hdd ); end; end; BitmapStream.Free; end;

Еще INTEL Image Processing Library тоже. Будет полезная весчь.

> Сейчас обнаружил, что скорость StretchBlt с COLORONCOLOR
> имеет не вполне очевидную зависимость от глубины цвета

Ничего себе. А я и не знал.

> Чтоб одновременно всё-всё сравнить, прикрутил FastLIB к
> своему тесту:

Проверил у себя. Результаты такие:

ToScreen:

Stretchblt + 24bpp = 27004
FastLib + 24bpp = 10381

Stretchblt + 32bpp = 6219
FastLib + 24bpp = 8258

Наиболее быстро изменить размер Bitmap-а (уменьшить). Найти похожие ветки