Tool voor bitmaps in embedded systems gezocht

Je zoekt een tool voor Windows embedded of voor (de opvolger) Windows IoT?
Ik weet niet of alle standaard Windows programma's daar op werken.

Tool hangt ook af van soort bitmap, er zijn er nogal wat (mono, 16 of meer kleuren)

Je zou bijna zeggen dat je de startpost niet gelezen hebt.

- Het komt uit een embedded systeem
- Het is een ARGB1555

Ik werk al heel lang en veel met bitmaps, maar vam ARGB1555 als formaat had ik nog nooit gehoord... :+

@Sine: Inderdaad. Dat is het formaat waar ik nu tegenaanloop en wat ook vaker gebruikt schijnt te zijn. Andere formaten zijn een bonus maar niet essentieel.

Een van de redenen dat ik een grafisch tooltje leuk zou vinden, is dat je makkelijk kan spelen met de afmetingen als je de originele dimensies van het plaatje niet kent. Op basis van een educated guess net zo lang proberen tot je iets herkenbaars ziet.

Het zit hem er verder vooral in dat ik het in zo min mogelijk tijd wil doen. Wat scripten of command prompt werk met Imagemagick (dat ga ik proberen als ik de suggesties van dit topic nagelopen heb en er geen oplossing tussen zat) is zonder meer haalbaar en zelf wat schrijven ook.

Bij dat laatste is het grootste probleem dat ik dan weer helemaal een omgeving moet optuigen en mijn ervaring van roest moet ontdoen; ik programmeer in het dagelijks leven nauwelijks. Ik heb iets vergelijkbaars ooit wel eens gedaan voor mijn bachelorproject om digitale stills te capturen en in een geschikte vorm te meppen voor verwerking in Matlab.

Op zaterdag 28 februari 2026 03:30:22 schreef maartenbakker:
Irfaview is normaal mijn favoriet, maar die kent het genoemde formaat niet. Die ander ga ik even bekijken, bedankt alvast.

Heb je een voorbeeld image in ARGB1555 formaat dat je hier kunt posten?
Op het web vind je dat formaat niet zo 1-2-3.

ARGB1555 lijkt op RGB555 formaat met de toevoeging van een 1-bit Alpha channel.

Het ARGB1555 formaat zit in Windows BMP versie 4. En misschien ook in het Targa formaat.

Hier kun je blijkbaar in een webpagina allerlei formaten bekijken, ook ARGB1555. Is dat wat?
https://rinechran.github.io/raw_pixels_viewer/

Voor GIMP is er een plugin:

https://github.com/Daniel-McCarthy/RLE-GIMP-Plugin

Wauw, ik leer ook bij over een (voor mij) nieuw formaat bitmap. Recent heb ik de lijst met mogelijke bestandsuitvoer voor schermafdrukken op een Tektronix TDS540D scope doorlopen en daar stonden al een hele hoop, voor mij totaal onbekende bestands-extensies in, maar hier had ik ook nog nooit van gehoord.

Sorry voor het ietwat off-topic antwoord, want ik vrees dat ik je niet verder kan helpen.

Dank aan FET voor het wijzen richting een bruikbare viewer!

https://rinechran.github.io/raw_pixels_viewer/ doet het opzich prima, maar mijn voorbeeldplaatje uit het apparaat kwam er uit met kleuren die net niet helemaal klopten maar wel in de buurt kwamen (misleidend).

Een vriend die toevallig langskwam heeft even een Javascriptje uit z'n mouw geschud om plaatjes om te zetten naar ARGB1555. De resultaten daarvan waren vrij bizar. Veel kleuren zaten in de buurt, maar het geheel klopte van geen kanten.

Dit kun je mooi zien in het proefplaatje dat ik gemaakt had om het raadsel op te lossen.

Een kenner van bedrade videoformaten ziet denk ik wel aan het plaatje hoe het formaat waarschijnlijk in elkaar zit (ik laat het heel even aan de lezer en geef het antwoord van de week nadat ik het geverifieerd heb - het Javascriptje moet nog even omgebouwd worden en het apparaat staat niet hier).

Screenshot van hoe het er uit zou moeten zien:

Screenshot van hoe het er uit ziet:

En dan ga je dus denken... Hebben rood en blauw daadwerkelijk maar half zoveel bits als groen? En waarom is m'n zwart groen en m'n wit roze? Half zoveel bits klopt weer niet met de indeling die toch duidelijk 1+15 bits per pixel is. Bij het bekijken van de onderste staircase viel voor mij het dubbeltje en heb met een hexeditor nog wat geverifieerd (makkelijk, hele plaatje dezelfde kleur kun je maken door te vullen met een bitpatroon).

Als zelf scripten een optie is: Python en OpenCV.

En de afmetingen van een bitmap kun je gokken op basis van de autocorrelatie: Openvolgende lijnen lijken op elkaar, en hebben dus een hoge autocorrelatie.
Ik zou aan een AI vragen daar even een scriptje voor te klussen.

Er is inmiddels een scriptje voor de conversie (Javascript, zie laatste bericht). Python ken ik van "wel eens gezien" en OpenCV ken ik niet maar hou ik in gedachten voor als ik weer wat zoek.

In een viewer waar je makkelijk aan de "potmeter van de horizontale afbuigfrequentie" kunt draaien is het makkelijker om de correlatie die je noemt, te vinden. Dat had ik inderdaad in gedachten maar met de wetenschap dat een pixel 16 bits beslaat kun je ook handmatig de afmetingen aanpassen in rawpixelviewer of Irfanview. Voor een eenmalig project was dat uiteindelijk acceptabel. Wat ik zocht, bestond nog niet en was uiteindelijk ook niet nodig. Het goede is de vijand van het betere.

Het enige dat nog overbleef was de indeling van die 16-bits, wat geen ARGB1555 bleek te zijn. Ik kom erop terug, ik denk met een 1-regelig berichtje met het formaat als mijn conclusie blijkt te kloppen. Daarna is het project wat mij betreft klaar.

Het is maar net hoe een 16-bits ARGB1555 pixel wordt gemapped naar een pixel op een RGB888 display device (of hoe je een RGB888 pixel probeert te converteren naar ARGB1555 als je het ARGB1555 formaat niet weet).
Bij een onjuiste mapping krijg je leukste artefacten te zien.

Daar dachten mijn meedenker en ik dus eerst ook aan, een of andere onduidelijke mapping die er tussen zit... Ik had met een hex editor vastgesteld dat het 1555 big endian moest zijn en de testkleuren die ik als steekproef invoerde wezen toch naar RGB, alleen als ik een plaatje probeerde klopte het nooit. Bij mij viel het kwartje bij de onderste staircase, maar dat is echt iets van "als je het ziet dan zie je het". Ik hoop het later van de week even te testen voor de definitieve uitkomst.

Op maandag 30 maart 2026 16:30:53 schreef maartenbakker:
Daar dachten mijn meedenker en ik dus eerst ook aan, een of andere onduidelijke mapping die er tussen zit... Ik had met een hex editor vastgesteld dat het 1555 big endian moest zijn en de testkleuren die ik als steekproef invoerde wezen toch naar RGB, alleen als ik een plaatje probeerde klopte het nooit. Bij mij viel het kwartje bij de onderste staircase, maar dat is echt iets van "als je het ziet dan zie je het". Ik hoop het later van de week even te testen voor de definitieve uitkomst.

Had je dat plaatje al eens met Gimp proberen te openen?
Eventueel omnoemen naar bmp als dat nog niet het geval is.

Om het op te slaan moet je het exporteren als bmp (twee opties, de eerste geeft extra mogelijkheden) en dan kun je kiezen voor 16 bit A1 R5 G5 B5

Deze is als transparante gif ingelezen en als ARGB1555 ge-exporteerd:

centron.bmp

De "centron" afbeelding eens geopend in IrfanView (zag eruit als onderstaande afbeelding) en gesaved als bmp in RGB888 formaat.
Is dit het plaatje zoals het er moet uitzien?
Indien zo dan kan IrfanView ARGB1555 correct inlezen.

centron_RGB888.bmp

Zojuist geverifieerd met een paar testbeelden die nu correct worden weergegeven.

Het formaat op het embedded device is ACrYCb1555 dus behoorlijk custom zeg maar... Ik heb het javascriptje omgegooid om dit te genereren aan de hand van de formules zoals te vinden op www.mir.com/DMG/ycbcr.html en dat lijkt gelukt te zijn.

Probleem opgelost, niet in de vorm van een kant en klare tool, maar met bestaande software (irfanview, rawpixelviewer, hexeditor) aangevuld met een stukje javascript.

P.S. De reden dat het kwartje viel toen ik de onderste staircase zag: een full-range ramp van component video ziet er zo uit, is een onderdeel van bepaalde testbeelden en herkende ik.

Dat is een exotisch YUV image formaat, soms moeilijk doen als plain RGB 555 veel makkelijker is.
Die groene waas en pink verkleuring heb ik ook eerder gezien bij het afspelen van video met een foutieve decoder maar verwachtte geen YUV formaat in een image.

Ik had het ook niet verwacht, maar er zal waarschijnlijk een technische reden voor zijn dat het verderop net even beter uitkomt op deze manier.

Opzich wordt een dergelijk coderingsprincipe ook gebruikt in JPEG algoritmes omdat je de kleurverschilsignalen met meer verlies mag comprimeren dan het helderheidssignaal, maar alsnog had ik het niet verwacht.

P.S. zuivere YUV (PAL) en YCbCr zijn vergelijkbaar maar toch weer niet onderling uitwisselbaar; de berekening van de verschilsignalen is anders. Je hebt een hele reeks systemen die helderheids- en kleurinformatie op een of andere manier uitsplitsen afhankelijk van het precieze doel.

[Bericht gewijzigd door maartenbakker op (31%)]

YUV heeft niet alleen betrekking op het PAL formaat (YUV PAL wordt specifieker YUV420 genoemd).
Vandaag de dag zijn er heel wat YUV encodings (zoals YUV410, YUV411, YUV422, YUV440, YUV444 en nog meer exoten) die vrij gangbaar zijn in de huidige computerwereld en die gecodeerd worden in YCbCr.

Vandaar dat ik het over "zuivere YUV (PAL)" heb om dat te onderscheiden van de categorie van andere coderingen die er op lijken. Juist bij het proberen te herkennen van dit soort formaten, probeer ik om elke dubbelzinnigheid te vermijden.

Ik heb weliswaar informatica gestudeerd, maar in mijn hart ben ik al sinds de basisschool een televisiemonteur (met de daarbij horende haat-liefdeverhouding met kleurendecoders, net als RF is het tovenarij die je pas gaat begrijpen als je het snapt).

[Bericht gewijzigd door maartenbakker op (35%)]

Op maandag 30 maart 2026 17:28:45 schreef KGE:
Had je dat plaatje al eens met Gimp proberen te openen?

Zo te zien niet. Maarten is blijkbaar iets met javascript aan het dingessen. Ik vermoed dat hij niet weet wat Gimp is.

Op dinsdag 31 maart 2026 23:39:32 schreef Bobosje:
Vandaag de dag zijn er heel wat YUV encodings (zoals YUV410, YUV411, YUV422, YUV440, YUV444 en nog meer exoten) die vrij gangbaar zijn in de huidige computerwereld en die gecodeerd worden in YCbCr.

Kies maar uit: alle color-space conversions die in OpenCV ingebakken zijn (het zijn er 155):

https://docs.opencv.org/5.0.0-alpha/d8/d01/group__imgproc__color__conv…

Geen idee welke met PAL overeenkomt, maar de gebruikte conversiematrices zijn gedocumenteerd:
https://docs.opencv.org/5.0.0-alpha/de/d25/imgproc_color_conversions.h…

Klinkt alsof OpenCV absoluut geholpen zou hebben, ga ik in gedachten houden voor als ik nog eens zoiets tegenkom.

Op woensdag 1 april 2026 04:09:57 schreef Kortsluiting_Online:
[...]

Zo te zien niet. Maarten is blijkbaar iets met javascript aan het dingessen. Ik vermoed dat hij niet weet wat Gimp is.

Ik weet prima wat Gimp is, maar dat is net als Photoshop nogal een grotesk pakket dat ik eerst ergens zou moeten installeren (de schijf is altijd vol) en leren gebruiken terwijl het javascriptje al klaar was (benodigdheden: notepad en firefox, was door een vriend geklust voordat ik eraan kon beginnen en heb ik zelf omgeklust toen het formaat duidelijk was).

Uiteindelijk ging het niet om het tooltje dat voor me zag, maar om de toolchain die het probleem oploste. Die was eigenlijk heel simpel, Irfsnview en rawpixelviewer werden hier in het topic al gesuggereerd als hulpmiddelen, maar dat is achteraf altijd het geval.

Op woensdag 1 april 2026 02:09:16 schreef maartenbakker:
Ik heb weliswaar informatica gestudeerd, maar in mijn hart ben ik al sinds de basisschool een televisiemonteur (met de daarbij horende haat-liefdeverhouding met kleurendecoders, net als RF is het tovenarij die je pas gaat begrijpen als je het snapt).

:) en dat smalle hoge blauwe delay-line doosje van Philips die bij de kleurendecoder werd gebruikt had iets magisch in zich.

Op woensdag 1 april 2026 08:26:15 schreef blurp:
[...]

Kies maar uit: alle color-space conversions die in OpenCV ingebakken zijn (het zijn er 155):

https://docs.opencv.org/5.0.0-alpha/d8/d01/group__imgproc__color__conv…

Geen idee welke met PAL overeenkomt, maar de gebruikte conversiematrices zijn gedocumenteerd:
https://docs.opencv.org/5.0.0-alpha/de/d25/imgproc_color_conversions.h…

Of in ffmpeg, daar zitten ook een hele hoop formaat / encoding conversies in.

PAL zal een van de YUV420 encodings in OpenCV zijn.