Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

Bitmaps [Android]

Pagina: 1
Acties:

  • Steve04
  • Registratie: September 2011
  • Laatst online: 16:20
Hallo

Het project waarmee ik bezig ben is gebaseerd op http://romotive.com/, maar dan wel voor android. De bedoeling is om op basis van een event, bv.: gezichtsdetectie een bijhorende afbeelding te tonen.

Afbeelding bij voorbeeld: https://docs.google.com/f...oyDWtMS1kVUVQc0dKREU/edit

Die afbeelding wordt als een bitmap toegekend aan een ImageView. Omdat de afbeelding gans het scherm moet vullen zonder gebrek aan kwaliteit heb ik de grootte van de afbeelding gelijkgesteld aan de grootte van mijn scherm: 1280 bij 720 pixels. Mits het PNG afbeeldingen zijn met 32 bits diepte neemt een bitmap (1280*720*32)/1024= 28800kb in beslag. De java VM reserveert 65536kb geheugen waarmee het verhaal snel eindigt in een out of memory exception bij het laden van een andere afbeelding. De huidige oplossing die ik nu heb maakt gebruik van één van de BitmapFactory decode methods die een bitmap aanmaakt op basis van een path naar de afbeelding die opgeslagen is op de SD-kaart. Hierdoor kan ik wisselen van afbeelding zonder gebrek aan geheugen. Het zelfde probleem deed zich voor wanneer de applicatie in pauze ging en later terug de focus krijgt, dit heb ik zo opgelost: Wanneer de activity in pauze gaat maak ik de bitmap klaar voor de Garbage collector via de bitmap.recycle method vervolgens geef ik via System.gc een hint aan de Garbage collector dat het nu interessant kan zijn om de boel wat op te kuisen. In de onResume callback herstel ik de activity door de Bitmap opnieuw te laden en toe te kennen aan de ImageView.

Het werkt wel, maar echt top is het niet. Vandaar dat ik opzoek ben naar een betere oplossing. Op android developer staat er wat over Memory caching en Disk caching maar dit vindt ik wat onduidelijk en weet ook niet of dit de oplossing is die ik zoek.

http://developer.android....bitmaps/cache-bitmap.html

Daarnaast kan ik ook iets aan de afbeeldingen zelf doen. Bv.: ogen, mond en andere attributen als afzonderlijke afbeeldingen gebruiken en via code deze positioneren op het scherm. Voordeel kleinere afbeeldingen minder geheugen, nadeel positionering is niet gemakkelijk en wat met geheugenbeheer?

Kortom: tips, suggesties of mogelijke strategieën om het probleem aan te pakken zijn welkom, alvast bedankt.

Steve

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Is het überhaupt nodig met bitmaps te werken? Zoiets (als in: simpel gezichtje in cartoonstijl) is volgens mij relatief simpel met wat vectoren real-time te tekenen. Bitmaps zijn eigenlijk wel 't laatste waar ik aan zou denken; als last resort zeg maar. Een hybride oplossing met sprites is dan nog een gulden middenweg. De achtergrond is een simpele gradient (paar bytes als je 'm "zelf tekent" i.t.t. 1280x720 ≈ 2 a 3Mb aan bitmap data) en daar teken je dan verschillende oogjes/mondjes op die van een alph channel voorzien zijn voor de transparantie. Desnoods zou je ook nog eens de achtergrond als een enkele bitmap kunnen opslaan. Maar dan glij je steeds verder af t.o.v. wat simpele vectoren die relatief makkelijk ook nog eens te animeren zijn voor vloeiende(re) bewegingen (en alle permutaties van expressie X naar Y of van X naar Z).

[ Voor 83% gewijzigd door RobIII op 10-04-2013 23:24 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


  • Steve04
  • Registratie: September 2011
  • Laatst online: 16:20
Ik wou de gezichtjes oorspronkelijk eerst real-time met vectoren gaan tekenen, maar omdat dit niet zo gemakkelijk is (afhankelijk van hoe complex je het wil) had ik besloten om ze via adobe illustrator te gaan ontwerpen. In Android is het zo dat alles wat je tekent of als illustraties gebruikt op een bitmap gebeurt, een canvas bv. teken ook alles op een onderliggende bitmap. Ik denk dat ik ga moeten kiezen uit volgende oplossingen:
  1. Gebruik maken van vectoren maar met verlies aan "kwaliteit" daarmee wil zeggen dat de gezichtjes meer basic en minder mooi zullen zijn dan de reeds ontworpen gezichtjes.
  2. Op zich is wat ik wil een soort van foto galerij waarbij het veranderen van een foto niet gebeurt op basis van een veeg over het scherm maar een event zoals bv. gezichtserkenning. Dus implementatie van een soort memory management zal nodig zijn maar hoe of wat ?
  3. ...
Ik ga het een dagje laten bezinken misschien krijg ik nog reacties van mogelijke oplossingen of mensen die hetzelfde probleem hebben ervaren. Alvast bedankt.

  • epic007
  • Registratie: Februari 2004
  • Laatst online: 17-11 15:31
Wil je echt uncompressed png's cachen? Je zou misschien ook (delen) in jpeg kunnen encoden. Deze laad je dan als jpeg in je geheugen en je decode ze pas naar Bitmap met BitmapFactory als je ze echt nodig hebt.

  • Steve04
  • Registratie: September 2011
  • Laatst online: 16:20
Android biedt de beste ondersteuning voor png afbeeldingen vandaar dat ik dit gebruik.

Nu een andere suggestie:

Ik beschik tevens over een aantal animaties die gebouwd werden met flash op basis van de afbeeldingen. Nu heb ik daarvan mp4 video's gemaakt die via de android MediaPlayer kunnen afgespeeld worden.
De bedoeling is een statische afbeelding te tonen van het neutraal gezicht. Telkens wanneer er een event voordoet wordt de passende video afgespeeld, hierna schakelen we terug over op de statische afbeelding.
Heb het nog niet getest dat is voor morgen, mocht dat niet lukken ga ik het proberen zelf via code te tekenen. De gezichtjes zullen wat basic zijn maar dat is dan zo.

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
Steve04 schreef op donderdag 11 april 2013 @ 15:55:
mocht dat niet lukken ga ik het proberen zelf via code te tekenen
"Via code" is natuurlijk ook relatief; je kunt natuurlijk easy een kleine editor maken waarmee je, bijv., met de muis een mondhoek animeert en daar de x/y posities mee opneemt op 25fps oid. Je kunt dan zelfs nog tweenen en dan ben je al heel dicht bij wat Flash in principe ook doet. Sterker: kun je niet op een-of-andere manier die vectoren en animaties uit Flash 'exporteren'? Dan ben je al helemaal klaar op 't daadwerkelijk tekenen van de lijntjes/gradients e.d. na. En je kunt ook nog eens leentje-buur spelen met / afkijken / gebruik maken van tweener en dergelijke libraries die de laatste restjes complexiteit ook uit handen nemen.

[ Voor 14% gewijzigd door RobIII op 11-04-2013 16:06 ]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


  • Steve04
  • Registratie: September 2011
  • Laatst online: 16:20
RobIII schreef op donderdag 11 april 2013 @ 16:03:
Sterker: kun je niet op een-of-andere manier die vectoren en animaties uit Flash 'exporteren'?
Geen idee moet dat eens nagaan maar het zou in ieder geval een grote stap vooruit zijn, bedankt.

[ Voor 112% gewijzigd door Steve04 op 12-04-2013 10:36 ]


  • Steve04
  • Registratie: September 2011
  • Laatst online: 16:20
In adobe illustrator kan je afbeeldingen opslaan als scalable vector graphics (.SVG). Hieruit kan ik bv. het path van een oog halen:

XML:
1
2
3
<path fill="url(#SVGID_1_)" stroke="#FFFFFF" d="M668.479,289.512c-48.064-28.133-117.905,38.32-155.983,103
    c-38.084,64.681-29.992,139.923,18.076,168.052c31.42,18.383,85.671,17.154,120.741-7.469
    C669.902,540.047,716.543,317.639,668.479,289.512z"/>


Via de Path class moet het mogelijk zijn om het path te reconstrueren op basis van de gegevens. Android beschikt jammer genoeg niet over SVG parser of iets dergelijks als createDrawableFromSvg(source). Dus dat path parsen naar een drawable ga ik zelf moeten voorzien. Wat denken jullie ?

Verwijderd

Steve04 schreef op vrijdag 12 april 2013 @ 10:37:
In adobe illustrator kan je afbeeldingen opslaan als scalable vector graphics (.SVG). Hieruit kan ik bv. het path van een oog halen:

XML:
1
2
3
<path fill="url(#SVGID_1_)" stroke="#FFFFFF" d="M668.479,289.512c-48.064-28.133-117.905,38.32-155.983,103
    c-38.084,64.681-29.992,139.923,18.076,168.052c31.42,18.383,85.671,17.154,120.741-7.469
    C669.902,540.047,716.543,317.639,668.479,289.512z"/>


Via de Path class moet het mogelijk zijn om het path te reconstrueren op basis van de gegevens. Android beschikt jammer genoeg niet over SVG parser of iets dergelijks als createDrawableFromSvg(source). Dus dat path parsen naar een drawable ga ik zelf moeten voorzien. Wat denken jullie ?
Er zijn wel zat open-source alternatieven. Misschien kan je eens een kijkje nemen naar SVG-Android?

  • Steve04
  • Registratie: September 2011
  • Laatst online: 16:20
Heb SVG-android geprobeerd, namelijk de voorbeeld code maar zonder resultaat. Ik krijg wel een error in LogCat maar de applicatie zelf geeft geen forse close en crash dus niet.

code:
1
error opening trace file: No such file or directory (2)
Pagina: 1