Det må være sådan at i et 5 bit system, at alle 5 bit sat betyder fyld styrke på en given grundfarve. Det må så betyde at de 5 bit sat skal være lig med 8 bit sat ved konvertering. Det der må skulle gøres er lineær interpolation mellem disse 2 værdier sådan at regnestykket må være 8bit / 5bit => 255 / 31. Det giver så et decimaltal, som skal afrundes efter udregning for precision, men det tror jeg ikke bliver det store problem idet vore dages computere er hurtige :) Prøv dette:
unsigned char farve8bit = (float(farve5bit) / 31.0) * 255.0; Jeg kan ikke huske om der en kommando i C for afrunding, andre end ceil og floor, som enten runder op eller ned, altid. Go' vind
problemet med at bruge floats er bare floating point præsitions fejl så jeg tror faktisk at det bedste man kan gøre er at benytte det som bertelbrandler har foreslået. Det er osse det jeg er endtlig.
Ok, det er selvfølgelig rigtigt at en bitskifte operation er hurtigere (i vore dage, vel ikke mere end 1 clockcycle) til gengæld mister du noget præcision i det 5 satte bit skiftet op og lagt i en 8 bit variabel, er stadig kun 5 satte bit, så resultatet vil være 11111000, og det er ikke fuld styrke på en given grundfarve :) Så jeg forstår ikke helt hvad du mener med præcisionsfejl.
floating points er mere eller mindre utilregnelige så de egner sig ikke til noget som skal være præsist. Når du deler 2 tal der ikke går op vil du på forskellige systemer kunne opleve at du for forskellige tal. Og så er der problematikken om der skal rundes op eller ned. Hvis man vælger at runde op så har du problemstillingen omkring 0.5 hvor floating point errors kunne betyde forskellige mellem 0.4999999999 og 0.5.
Du har self. ret i det du skriver og det var osse den første løsning jeg har prøvet mig med. Lurer på om man kunne dele de binære tal med en algoritme.
Det er muligt, men hvis du er igang med at skrive programmet, tror jeg da nok jeg ville teste begge muligheder, idet min løsning i teorien, og din :), vil kunne gi' en fejl på max. 1(decimal) hvorimod bitskifte 3 pladser altid vil gi' en fejl på 7(decimal). Li'som dig, har jeg også tænkt på om det var muligt at finde en algoritme hvor resultatet kunne findes ved "bitpilleri", men det går nok hen og blir' en forholdsvis kompliceret algoritme, og så er det spørgsmålet ikke det vil kunne svare sig at anvende floatingpoint. De mest simple floatingpoint instruktioner er hurtige idag (FADD, FSUB, FMUL, FDIV) tager typisk også kun 1 clockcycle. Hvis det er meningen programmet altid skal køre på en maskine med X86 processor (Intel ell. AMD), så var det måske en mulighed at optimere den del af routinen med inline assembler.
Ups, der er lige indsneget sig en mindre fejl. Fejlen ved bitskifte er ikke ALTID 7, men mellem 0 og 7, ligefrem propertionalt med værdien i din 5bit værdi og forskellen mellem, faktoren 8 og faktoren (255 / 31). I øvrigt, så gir' din formel og bertelbrander's udtryk det samme resultat :) Men hvis hastighed er det største kriterie, så er bertelbranders udlægning den hurtigste, men faktoren (255 / 31) gir' den største farve nøjagtighed, så det vil selvfølgelig afhænge af hvad kriteriet er for konverteringen, hastighed eller farvenøjagtighed.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.