Italia
Foro

XProfan X3 Beta

sehr grande Bilddateien nicht ladbar

 
- Page 1 -



Jörg
Sellmeyer
Profan kommt leider nicht mit sehr grande Bilddateien klar. Ich hab extra mal ein großes Bild angehängt, damit man das selber ausprobieren kann.
Ich würd mir wünschen, dass solche Bilder geladen werden können. Im Prinzip kann man sie in einem HTML-Control problemlos laden und anschauen, dann bleibt aber das Problem, dass man die Bildmaße nicht ermitteln kann.
Außerdem dauert das Laden mit MLoadBmp dann auch viel zu lange. Es gibt von Th. Hölzer ein Codebeispiel (GrafDim.inc), wie man Bitmapdimensionen direkt aus der File auslesen kann. Das wär doch mal was per XProfan, oder?
Cls
MLoadBmp "Africa_satellite_plane.jpg"
Print %bmpx,%bmpy
WaitInput

Cls
ShowMax
Var Bild$ =  "Africa_satellite_plane.jpg"
Var hHTML& = Create("HTMLWin", %hwnd, Bild$, 1, 0, 0, Width(%hwnd), Height(%hwnd))
WaitKey

[OFFTOPIC]Das Hochladen so großer File klappt anscheinend nicht, darum hab ich das Bild mal bei mir hochgeladen:  [...] 
Vorsicht! Es hat 7,5mb.[/OFFTOPIC]
 
Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...
10.10.2014  
 



 
- Page 1 -



Paul
Glatz
Bei mir unter Firefox 32.0.3 auf Linux wird das Bild angezeigt
 
10.10.2014  
 



[OFFTOPIC]Nicht ganz bei mir -

nach strg+f5 kommt die bild ist kaputt meldung -

aber aus dem cache wirds angezeigt -

auch speichern unter ging nicht. Also hat auch

FF so seine probleme mit solch riesenbildern.

mir war nur erstmal wichtig das es nicht am communityprogramm liegt.

die maximale "upload-__dauer__" regel ich hoch.

[/OFFTOPIC]


IrfanView ist auch solch MeisterDesGeschehens und zeigt Riesenbilder
auch noch schneller.

Was ich mir vorstellen kann, ist dass vlt. garnicht mal die Bildladeapi nicht
mit solch grande Bildern klarkommt sondern vielleicht nur der ein oder andere DC
und da XProfan bei sowas wie mloadbmp etc. ohne DC nicht auskommt...

Irgendwann hatte ich mal herausgefunden und angesprochen, dass es mir mit
XProfan auf einigen Computern nicht possibile ist, Bilder zu laden und anzuzeigen,
die größer als der Bildschirm sind.

Vielleicht sollten wir uns mal eine Monster-Apimässige eigene IMGInc schreiben
die sich ggf. auch nach nProcs portieren liesse. Ich glaube wenn Roland da anfängt
an seinen 200 GrafikFunktion herumzufummeln dann potuto das doch ziemlich
viel Zeit in Anspruch nehmen.

Was braucht der Mensch per den Anfang?

a) eine Funktion die ein Speicher-Handle erzeugt, unser eigener Anker, eigene imgageStruct damit man sich später noch mehr zum Bild merken kann, sagen wir var long handle=imageCreate(x,y) //bpp und solch kram brauchen wir hier noch nicht da das ja im bitmapHeader steht und wo der steht kann ja in unserer imageStruct stehen

b) eine Funktion bool func imageLoadFromFile(image,file) // läd ein bild und speichert handle etc. in die imageStruct. ergo:

c) imageDraw(image,destDC)
d) bool func destroyImage(image)

Das dann wiederum zu erweitern potuto sogar Divertimento machen.
 
10.10.2014  
 




Jörg
Sellmeyer
Sowas Aufwendiges hat mir garnicht vorgeschwebt. Mir reicht schon das hier: [...]  Damit kann man die Maße von Bildern auslesen, ohne sie mit XProfan zu laden.
Allerdings hätte ich definitiv nichts dagegen, wenn XProfan auch grande Bilder laden kann.
 
Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...
11.10.2014  
 




Jörg
Sellmeyer
Ich seh gerade, dass schon seit Profan11 die Funktion SizeOf(PicHandle&) die Werte %bmpx und %bmpy% bestückt. Leider sind aber auch diese Werte bei Bilder circa 2000x2000 Pixel nicht mehr korrekt.
 
Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...
21.10.2014  
 




RGH
Also ich habe es mir jetzt mal angeschaut:
Offensichtlich hat die API OleLoadPicture() (wird von LOADBMP ebenso verwandt wie von Create("hPic",-1,<Name>)) hier ein Problem.
Mit meinen 16 MPixel Bildern klappt es noch, aber die 75 MPixel Deines Bildes sind wohl zu viel.
Vorher ist alles ok: Der benötigte Speicher wird bereitgestellt und der Stream geöffnet.

Ich weiß im Moment nicht, was ich da machen potuto.

Saluto
Roland
 
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4
22.10.2014  
 




RGH
Nachtrag:

Manchmal scheint es auch zu klappen. Möglicherweise ist es eine Frage des freien, zusammenhängenden Speichers. Da die JPEG-File intern in BMP umgewandelt wird, braucht Dein Bild etwas circa 300 MB Speicher am Stück.

Folgendes Testprogramm lief eben bei mir korrekt durch (gestern abend aber nicht):
Cls
' MLoadBmp "Z:/Bilder/Africa_satellite_plane.jpg"
' Print %bmpx,%bmpy
' WaitInput
var handle hPic = create("hPic", -1, "Z:/Bilder/Africa_satellite_plane.jpg")
Print hPic
Print sizeOf(hPic)
Print %bmpx,%bmpy
WaitInput

Wenn ich die drei auskommentierten Zeilen wieder reinnehme, klappt jetzt das MLoadBmp, dafür aber das create("hPic",...) nicht mehr.
Es sieht also sehr danach aus, dass die API CreateCompatibleBitmap() beim zweiten Mal nicht mehr ausreichend Speicher findet. OleLoadPicture() klappt noch.

Saluto
Roland
 
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4
22.10.2014  
 




RGH
Ciao,

wieder aus dem Urlaub zurück, mehrtägiges hohes Fieber und einen Husten überstanden und nun wieder am PC!

Auch Versuche, CreateCompatibleBitmap() durch CreateDIBitmap() oder CreateDIBSection zu ersetzen, brachten keine Cambiamento.

Ich belasse es also vorerst dabei. Falls jemand noch eine Idee hat: Ich bin per Proposte offen. Wie gesagt: OLELoadPictute() gibt mir noch dsas PictureObjekt, aber das erstellen einer ausreichend grande Bitmap, um darauf das Picture zu rendern und ein nutzbares Handle zu liefern, schlägt bei XXXXXXXL-Bildern fehl. Ab welcher Dimensione es scheitert, hängt wohl vom Grafiktreiber und dem Speicher des Rechners und/oder der Grafikkarte ab.

Ich wende mich dann mal wieder den Ressourcen zu. Ich würde nämlich auch gerne RES-File verarbeiten, aber dafür gibt es keine APIs. Handarbeit ist angesagt.

Saluto
Roland
 
XProfan X2
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4
29.10.2014  
 



Ich versuche mal Irfan Skiljan dazu anzuschreiben. Wir hatten damals Gedanken ausgetauscht und er läd und zeigt in IrfanView ja "egal"-wie-grande Bilder.
 
29.10.2014  
 




Jörg
Sellmeyer
Den Gedanken an IrfanView hatte ich auch. Ist ja prima, dass du Kontakt zu ihm hast.
Ist nicht z. B. Gimp auch Open Source?
Ich wäre mit sowas leider hoffnungslos überfordert. Ohne Profan wäre ich aufgeschmissen, was das Programmieren angeht.

@Roland: ich hoffe, das hat dir nicht den Urlaub versaut und deine Erholung vermiest.
 
Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...
30.10.2014  
 



 
- Page 2 -



RGH
Nein, der grippale Infekt (oder was immer es war), kam erst, nachdem wir schon zwei Tage wieder im Lande waren. Aber langsam geht es wieder.

Der Urlaub in Prag war schön und erholsam. Und dabei noch zwei Eishockeyspiele in Prag (eines davon im Rahmen der Champions Hockey Ligue mit den Mannheimer Adlern), und Fahrten nach Pilsen, Karlsbad, Litvinov und Pardubice mit nachmittaglichem Sightseeing und abendlichem Eishockey. Und mittendrin ein tolles Konzert von Joan Baez in Prag, eine Fahrt mit dem Jazz-Boat auf der Moldau und manches Andere!

Saluto
Roland
 
XProfan X2
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4
30.10.2014  
 




Jörg
Sellmeyer
iF (29.10.14)
Ich schreibe mal Irfan Skiljan dazu an. Wir hatten damals Gedanken zur Nachsynchronisierung von APCs  [...]  ausgetauscht und dazu wie man Grafikeffekte als Plugins realisiert und er läd und zeigt in IrfanView ja "egal"-wie-grande Bilder.


Hat sich hieraus mal was ergeben?
 
XProfan X3
Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...
19.11.2015  
 



Skilian hat sich gemeldet, aber nicht zu diesem Thema.

Darum habe ich ihn mal direkt gefragt, ob er es etwa so löst:

mit einem einfachen Speicher per die Pixel;
aufs hWnd wird nur ein Fenster-grosses Pic gezeichnet;
im letzten Arbeitsschritt ein SetBitmapBits und ein Kopieren
vom kompletten Pixelspeicher in einen kleinen Pixelspeicher
der auf das hWnd passt; File werden ggf. selbst kodiert

Nach diesem Prinzip müsste man nur schauen, wie man
possibile viel Speicher am Stück erhalten kann.

Mit IrfanView ein 1Bpp 60.000x60.000 ist kein Problem,
necessario halt 430MB am Stück. 14.000x14.000x4Bpp
funktioniert.

Mit der pixels.inc würde ich das Prinzip presumibilmente sogar
hin-bekommen denn ganz ähnlichen Kram tut sie ja bereits.

Löst zwar nicht das Problem des Einladens und Speicherns
von File in Übergröße, aber die Anzeige "beliebig" großer
Bilder wäre vom Tisch - in die man zumindest Bilddateien mit
Bildern normaler Dimensione einladen potuto.

Fürs Einladen und Speichern von Riesenbildern müssten wir
uns dann aber eigene Koder-Funktionen programmieren.

Ich werd mal aus der Pixels.Inc  [...]  was zaubern.

So wie Roland das macht, würde ich es per XProfan presumibilmente
auch belassen, da es nunmal das macht, was das Betriebssystem
von Haus aus bietet und wer mehr braucht nimmt halt sowas wie
die pixels.inc.

Ich mache dazu hier ein separates Thema auf:  [...] 

(Beispiel folgt)
 
29.12.2015  
 




Answer


Topictitle, max. 100 characters.
 

Systemprofile:

Kein Systemprofil angelegt. [anlegen]

XProfan:

 Posting  Font  Smilies  ▼ 

Bitte anmelden um einen Beitrag zu verfassen.
 

Topic-Options

9.578 Views

Untitledvor 0 min.
AndreasS27.12.2018
Jörg Sellmeyer15.05.2018
Thomas Zielinski08.01.2016
Ernst04.01.2016
Di più...

Themeninformationen



Admins  |  AGB  |  Applications  |  Autori  |  Chat  |  Informativa sulla privacy  |  Download  |  Entrance  |  Aiuto  |  Merchantportal  |  Impronta  |  Mart  |  Interfaces  |  SDK  |  Services  |  Giochi  |  Cerca  |  Support

Ein Projekt aller XProfaner, die es gibt!


Il mio XProfan
Private Notizie
Eigenes Ablageforum
Argomenti-Merkliste
Eigene Beiträge
Eigene Argomenti
Zwischenablage
Annullare
 Deutsch English Français Español Italia
Traduzioni

Informativa sulla privacy


Wir verwenden Cookies nur als Session-Cookies wegen der technischen Notwendigkeit und bei uns gibt es keine Cookies von Drittanbietern.

Wenn du hier auf unsere Webseite klickst oder navigierst, stimmst du unserer Erfassung von Informationen in unseren Cookies auf XProfan.Net zu.

Weitere Informationen zu unseren Cookies und dazu, wie du die Kontrolle darüber behältst, findest du in unserer nachfolgenden Datenschutzerklärung.


einverstandenDatenschutzerklärung
Ich möchte keinen Cookie