max. TBitmap FMX vs. VCL

[bernhard_LA]

ich müsste *.tif Dateien mit ca. 20.000 * 20.000 pixel in eine FMX Bitmap laden ....
mit dem code fragment

Delphi-Quellcode:

  
   BMP := TBitmap.Create;
   BMP.Width := 500;
   BMP.Height := 500;

kann ich auf meinen Rechner TBitmaps mit ca. 3000 x 3000 pixel erzeugen, wie komme ich zu den großen Werten / Bilddateien ???
bei 6000 pixel x 6000 pixel bekomme ich eine Out of Memory Fehlermeldung :-(
bei VCL waren 20.000 x 20.000 pixel möglich

[Bernhard Geyer]

Ist schon ein 64-Bit Projekt?
Ansonsten schaffts du mit VCL auch keine 20k * 20k Bilder

[himitsu]

Zitat:

bei VCL waren 20.000 x 20.000 pixel möglich

Ähhh neee?
In einer realen 32-Bit-Anwendung, mit 2 GB RAM, wird es erfahrungsgemäß schwer "immer" einen gemeinsamen Speicherblock über 700 MB zu bekommen.

In 32 Bit garnicht, denn bei pf32Bit wäre das Bitmao 1.6 GB groß und das in einem zusammenhängenden Speicherblock.


ImageEN hatte ich schon große Bilder geladen.
Die haben ein TIEBitmap, welches intern LZW-Komprimiert ist.

Bei Delphis TWICImage musste ich aber bissl kämpfen, denn für eine Vorschaufunktion hatte ich auch sehr große TIFF-Bilder geladen.
Beim StretchDraw zeigte sich aber, dass der Entwickler von Embarcadero eine Volltrottel war,
denn da wird das Bild zuerst in ein internes TBitmap geladen und dann auf den Canvas (ein anderes TBitmap) runterscaliert.
Dabei bietet die WIC-API (Windows Imaging Component) auf extreme Speichersparsamkeit ausgelegt, indem die API immer nur mit kleineren Bildauschntitten arbeitet, wenn der Trottel auch die vorhandene Scalierungs-Interfaces genutzt hätte.

Selbst in Win32 ohne IMAGE_FILE_LARGE_ADDRESS_AWARE konnte ich am Ende sogar TIFFs mit derartigen Größen laden.
Allerdings nur in einem kleinen Programm, welches noch wenig Speicher belegt, wenige DLL/BPL geladen hat und wo der Speicher noch nicht zu sehr fragmentiert ist.

So oder so, würde ich dir also LargeAddressAware oder besser 64 Bit empfehlen.

[TurboMagic]

Ich verstehe noch nicht wie eine Bitmap deren Width und Height jeweils auf 500 gesetzt wird
dann 3000x3000 Bildpunkte groß sein soll.

Hat das was mit dp als Einheit zu tun?

[TurboMagic]

Zitat:

Zitat von himitsu (Beitrag 1472221)

Bei Delphis TWICImage musste ich aber bissl kämpfen, denn für eine Vorschaufunktion hatte ich auch sehr große TIFF-Bilder geladen.
Beim StretchDraw zeigte sich aber, dass der Entwickler von Embarcadero eine Volltrottel war,
denn da wird das Bild zuerst in ein internes TBitmap geladen und dann auf den Canvas (ein anderes TBitmap) runterscaliert.
Dabei bietet die WIC-API (Windows Imaging Component) auf extreme Speichersparsamkeit ausgelegt, indem die API immer nur mit kleineren Bildauschntitten arbeitet, wenn der Trottel auch die vorhandene Scalierungs-Interfaces genutzt hätte.

Hast du diese Thematik mal als QP Report erfasst?
Sonst bekommen wir da nie eine Verbesserung von "out of the box".

[himitsu]

Wollte ich mal, aber hatte noch keine Zeit Lust.
Hatte am Ende komplett auf TWICImage verzichtet, weil es zu krank war, mit den internen Handles zu arbeiten, denn die blöde Komponente merkt sich "versteckt" nur das Basisinterface, aber ein Sub-Interface wird sofort im LoadFromStream wieder freigegeben und ich müsste es mir dann sinnlos neu erzeugen, nachdem ich mich mühevoll an das Interne Interface durchgekämpft hatte.
Hatte mir den Code letzendlich direkt mit der WinAPI gebaut und paar Zwischenschritte rausgekürzt, speziell auf meinen Fall zugeschnitten.

Und dann hilft es auch nur im Windows.
Ich weiß garnicht ob das FMX-TBitmap im Windows auch die Systemfunktionen verwendet.

[TurboMagic]

Zitat:

Zitat von himitsu (Beitrag 1472224)

Wollte ich mal, aber hatte noch keine Zeit Lust.

Und dann hilft es auch nur im Windows.
Ich weiß garnicht ob das FMX-TBitmap im Windows auch die Systemfunktionen verwendet.

Ja, aber selbst wenn's nur für die VCL was bringt wär's doch eine gute Sache.
Und soviel Zeit braucht ein kleiner QP Report ja auch nicht.
Die Frage ist dabei, ob das ein Bugreport oder ein Feature Request wäre.

Falls du schon Code hast und den teilen wolltest/könntest wär's natürlich noch besser,
aber evtl. reicht da auch schon ein kleines Fragment aus um EMBT die richtige Richtung
zu zeigen... ;-)

[himitsu]

Mir war so, als hätte ich auch Teile im Forum, aber fand den Beitrag grade nicht (von letztem Jahr, wenn ich mich nicht irre).
Vor paar Monaten war ich in der Firma nochmal drüber gestolpert, denn jetzt war jemandem was aufgefallen.
Cheff eines Kunden hatte ein Foto der neuen Maschine ins DMS geladen, die war Rot, aber in der Vorschau Blau (oder andersrum) ... am Ende hatte ich im WIC einen Parameter RGB mit BGR vertauscht. :lol:

Mein Problem war vor allem PDFs (inzwischen DevExpress) und Bilder (BMP, TIFF, GIF, PNG, JPEG) multithreated zu laden, runterzuskallieren und dann in der GUI anzuzeigen.
Teilweise extrem große/detailierte PDFs/Bilder. (technische Zeichnungen)

[TurboMagic]

Na dann auf Report schreiben ;-)

[bernhard_LA]

wir machen natürlich alles in x64, RAM 16 GBYTE und mehr vorhanden .......;
Die 500 x 500 pixel waren nur ein Code Fragment und als Beispiel gedacht :-)

unter VCL ging bei uns wie bereits geschrieben h=20.000 und W= 20.000 , 30.000 pixel * 15.000 pixel waren auch möglich, aber eben nicht 50k * 50K Bitmaps,
alles mit pf24bit.

Wer kann über große FMX Bitmaps berichten, Grafikformat *.jpg, *.tig oder *.bmp ?
ist hier der Video Speicher entscheidend , muss man was im Win hierfür konfigurieren ?
Was wäre das beste Pixelformat unter FMX ???
Will mit diesem Code dann auch unter LINUX wieder arbeiten können ....