[.NET] Hoe images efficient in XML opslaan

[Verwijderd]

Hallo Allemaal,

Ik ben momenteel bezig om de images die mijn gebruiker kan importeren op te slaan in mijn een XML file.

Momenteel laad ik de file als binary, en creeer een byte array die ik dan met Base64 in de XML kan opslaan. Nu is de vraag echter, hoe laat ik dit weer als image zien in WinForms? En is er een efficientere manier? Bijv. via een .NET object wat ik kan serializen naar de XML?

Met vriendelijke groet,
Martin

[Woy]

Mijn eerste vraag is eigenlijk: Waarom zou je images ( of een willekeurig ander binair formaat ) op willen slaan in xml?

Verder is de manier om het gewoon Base64 te encoden niet zo heel erg slecht als je dit toch echt wilt. Om het dan weer te gebruiken zul je het gewoon Base64 moeten decoden, en de resulterende data weer in een Image inladen. Wat lukt er niet bij het inladen van een Image?

Je zou misschien nog iets winst kunnen halen door de data eerst te zippen, maar aangezien images meestal al compressed zijn zul je daar niet zoveel winst mee halen.

[ Voor 4% gewijzigd door Woy op 12-05-2009 21:19 ]

[Snake]

Wat is mis met ze gewoon op te slaan in een directory? Sneller en minder overhead.

[Verwijderd]

Google 's op ".net xml serialize bitmap". Dit was m'n eerste hit...

[MrBucket]

Woy schreef op dinsdag 12 mei 2009 @ 21:19:
Mijn eerste vraag is eigenlijk: Waarom zou je images ( of een willekeurig ander binair formaat ) op willen slaan in xml?

Ik vermoed (hoop ) dat het gaat om webservice die zijn clients images aan moet bieden, m.a.w.: hoe vouw ik een image in een SOAP-bericht?

Ik weet in ieder geval dat MS CRM 4.0 ook Base64 gebruikt om binaire attachments als onderdeel van een SOAP response te kunnen retourneren. Dus als je het doet, ben je in ieder geval niet de enige

[Verwijderd]

Eigenlijk is het antwoord heel eenvoudig, in proces industrie draaien talloze embedded systemen met touchscreens, op deze touchscreens draaien HMI applicaties (visualizatie).

Wij ontwerpen deze schermen en communicatie parameters / variabelen etc... in onze eigen designer. Onze designer spuugt één grote XML uit waar alle info in zit.

Deze XML (in zip formaat) wordt geladen op de panel, die daardoor direct allen info heeft. Hierdoor kunnen upgrades heel eenvoudig uitegevoerd worden. Alle images zijn ook vrij klein (meestal niet groter dan 32kb).

Mijn vraag was eigenlijk ook of de byte array een probleem was, en of ik dit direct in een .NET image control kan laden?

[MrBucket]

Verwijderd schreef op dinsdag 12 mei 2009 @ 22:35:
Eigenlijk is het antwoord heel eenvoudig, in proces industrie draaien talloze embedded systemen met touchscreens, op deze touchscreens draaien HMI applicaties (visualizatie).

Wij ontwerpen deze schermen en communicatie parameters / variabelen etc... in onze eigen designer. Onze designer spuugt één grote XML uit waar alle info in zit.

Deze XML (in zip formaat) wordt geladen op de panel, die daardoor direct allen info heeft. Hierdoor kunnen upgrades heel eenvoudig uitegevoerd worden. Alle images zijn ook vrij klein (meestal niet groter dan 32kb).

Mijn vraag was eigenlijk ook of de byte array een probleem was, en of ik dit direct in een .NET image control kan laden?

Ach so. Nou, "rechtstreeks" niet, maar Base64 strings kunnen gewrapped worden in Streams (met of zonder byte array als tussenstap durf ik niet te zeggen), en images kunnen voor zover ik weet geconstrueerd worden uit Streams, dus volgens mij zit je wel goed.

Edit: even gechecked, en Images kunnen uit streams geconstrueerd worden. Over base64 en streams kwam ik o.a. dit tegen: http://www.ddj.com/windows/184416920, dus misschien is het het makkelijkst om een byte[] als tussenstap te pakken.

[ Voor 10% gewijzigd door MrBucket op 12-05-2009 23:00 ]

[Woy]

Je moet dan idd zoals ik zei in mijn eerste post, Base64 decoden. Daar krijg je een byte array uit. Dan kun je d.m.v. een MemoryStream ( http://msdn.microsoft.com...stem.io.memorystream.aspx ) gewoon weer een Image maken.

C#:

byte[] myBytes;
Image img = Image.FromStream( new MemoryStream( myBytes ) );

Ik zie nou trouwens dat een XmlTextReader ook gewoon een ReadBase64 methode heeft. Ik weet niet niet hoe je de Xml weer inleest maar die zou je ook kunnen gebruiken.

[Janoz]

Als je toch een zip heen stuurt, waarom zouden daar niet meerdere bestanden in kunnen? Voor een bepaalde applicatie van mij lever ik ook een gezipt bestand op (eigenlijk jar), en daarin heb ik gewoon een mapje resources opgenomen.

[Verwijderd]

Omdat mensen dan de plaatjes gaan vervangen :-)

Ik heb hier al ervaring mee dat dit uiteindelijk gebeurt vandaar dat we er deze keer niet voor hebben gekozen.

Bedankt voor de hulp ik heb het nu allemaal werkend.

[Woy]

Verwijderd schreef op donderdag 14 mei 2009 @ 08:03:
Omdat mensen dan de plaatjes gaan vervangen :-)

Ik heb hier al ervaring mee dat dit uiteindelijk gebeurt vandaar dat we er deze keer niet voor hebben gekozen.

Bedankt voor de hulp ik heb het nu allemaal werkend.

Je snapt dat op deze manier de plaatjes net zo goed vervangen kunnen worden. Als je niet wilt dat de plaatjes vervangen worden, kun je de files misschien gewoon signen met een private key, die je dan met een public key kunt controleren. Als de signature niet klopt accepteer je de file niet.

[sopsop]

Woy schreef op donderdag 14 mei 2009 @ 08:25:
[...]

Je snapt dat op deze manier de plaatjes net zo goed vervangen kunnen worden. Als je niet wilt dat de plaatjes vervangen worden, kun je de files misschien gewoon signen met een private key, die je dan met een public key kunt controleren. Als de signature niet klopt accepteer je de file niet.

Ik denk dat TS bedoelt dat Jan met de pet wat meer moeite zal moeten doen dan een paar bestandjes in een zipfile te vervangen. Ik zie een operator niet 1,2,3 een bytearray encoden met base64 en het resultaat in een XML document plakken.

[Woy]

sopsop schreef op donderdag 14 mei 2009 @ 13:47:
[...]

Ik denk dat TS bedoelt dat Jan met de pet wat meer moeite zal moeten doen dan een paar bestandjes in een zipfile te vervangen. Ik zie een operator niet 1,2,3 een bytearray encoden met base64 en het resultaat in een XML document plakken.

Maar voor jan met de pet is het dan meestal al genoeg om gewoon de extensie niet .zip te laten zijn.