Ефективност на използването на PNG срещу BMP с големи файлове

Написах програма за картографиране в Delphi, където потребителят може да зареди растерно изображение във фонов режим, което съхранявам в паметта. В един случай потребителят зареди 44MB BMP успешно, но програмата беше бавна и когато те отпечатаха (изграждам изхода), получиха грешка Изчерпване на ресурси. Преобразувах BMP в PNG (3MB) и програмата работи много по-добре и заданието за печат беше успешно.

След като PNG трябва да бъде разширен до DIB със същия размер, защо има разлика в производителността/ресурса? Ако не друго, трябва да отнеме повече работа и разпределение на паметта, за да зареди PNG. какво ми липсва

Тъй като изглежда, че няма очевидни отговори, ще напиша малък демо проект, за да мога да проуча това допълнително.


png delphi graphics bmp
person Mitch    schedule 05.04.2012    source източник
comment
Сигурни ли сте, че BMP и PNG файловете имат еднакъв брой пиксели и BitsPerPixel?   -  person Francesca    schedule 05.04.2012
comment
Какво използвате за отпечатване на изображението? Пишете ли директно на Printer.Canvas или използвате компонент на отчет като QuickReport или Rave?   -  person rkawano    schedule 05.04.2012
comment
Франсоа: Да, получих досието на клиентите и го пробвах сам. rkawano: Отпечатвам на DIB плочки, които изпращам на платното на принтера.   -  person Mitch    schedule 05.04.2012
comment
Звучи сякаш имаш изтичане на памет някъде.   -  person MickLH    schedule 26.11.2013

Отговори (1)


arrow_upward
1
arrow_downward

Разликата е в компресията.

BMP = необработени данни като PNG = същите необработени данни, използващи компресия без загуби

Това има спестяване по повече от 1 начин в програмните кръгове ...

  1. зареждането на изображението води до зареждане на по-малко необработени данни в ram.
  2. След това обработвате по-малко необработени данни, така че се нуждаете от по-малко ресурси.

Подреждането означава, че проблемът за вас е експоненциален, например ...

44MB x 10 плочки = 440MB

Vs

3MB x 10 плочки = 30MB

Принтерите не обичат да им се подават масивни парчета данни и всички освен по-скъпите принтери обичат да отпечатват целия документ наведнъж (напр. буфериране на целия поток).

И така, от вашето приложение потребителят казва „Печат“ ... вашият код след това казва „добре, ще изпратя 10 копия от това“ и принтерът започва да „кешира“ 440 MB необработени данни.

Повечето обикновени домашни принтери разчитат на компютъра да извърши кеширането и да отпечата това, което му е дадено, но стандартният офис принтер ще извърши кеширането и след това ще отпечата документа.

Въпреки това ... мисля, че това е незадължително нещо, което можете да промените (мисля обаче, че варира от принтер до принтер).

РЕДАКТИРАНЕ:

ето нещо от света на програмирането на игри:

http://www.gamedev.net/topic/450104-png-vs-bmp/

person War    schedule 12.04.2012
comment
При проследяване през кода PNG се разширява до DIB с равен размер на BMP в паметта. Предполагам, че кодът с по-ефективна памет би извършил преобразуването според нуждите. - person Mitch; 12.04.2012
comment
Искате да кажете, че облицовката не помага? Рисувам част от плочката с разделителна способност на устройството, която след това се предава на принтера. Щях да рисувам директно и да оставя драйвера на принтера да се справи, но тогава щях да загубя способността да правя прозрачност. - person Mitch; 12.04.2012
comment
не съм напълно сигурен какво правите, но основната концепция е, че всяка част от това изображение, което изпращате на принтера, той трябва да обработи и трябва да направи това обикновено като некомпресирани необработени данни. Това може да е причината за вашия проблем с ресурсите ... ресурс на принтера, а не на компютъра ... има ли смисъл? - person War; 13.04.2012
comment
Всъщност не, подреждането изпраща същото количество данни (DIB), независимо дали оригиналното изображение е било PNG или BMP. В интерес на истината и двете изображения се съхраняват от библиотеката, която използвам в паметта като Device Independent Bitmaps (DIB). Ето защо целият този въпрос няма смисъл. - person Mitch; 14.04.2012