1.7 Tegn, filformater, farger og komprimering
ASCII/UTF-8, RGB-fargekoder i hex, og skillet tapsfri vs. tapskomprimert — og hva ASCII/UTF-8/vektorgrafikk egner seg til.
Nivå 3 — bør kjenne til. Dette er det letteste stoffet i seksjon 1, og det ligger sist i delen av en grunn: de tre garanterte sjangrene (tallkonvertering, to-er komplement og LMC) er viktigere. Men trenden gjør at du ikke bør hoppe over kapitlet — seksjon 1 må bestås for seg, og noen få poeng her kan være det som avgjør.
Slik kommer den: som svarform F3 (dra-og-slipp — «plasser hvert format i riktig kolonne»), F2 (sant/usant om formategenskaper) eller F1 («kryss av alle som stemmer om denne fargekoden»).
Det eneste som krever regning: RGB-fargekoder. Og den regningen er allerede kjent — det er heksadesimal konvertering fra kap. 1.1, gjort tre ganger.
Tidsbruk: 45 minutter.
Forkunnskaper — sist du var her
Kapitlet bygger på kap. 1.1. Her er det du trenger, ferdig oppfrisket:
1. Heksadesimal konvertering. Ett heksadesimalt siffer er fire bit; to sifre er én byte. Sifferverdiene A til F er 10 til 15.
0x2E = 2·16 + 14 = 46
0xFF = 15·16 + 15 = 2552. Verdiområdet for en byte uten fortegn: 0 til 255. Det er nøyaktig området en fargekomponent kan ha.
3. ASCII-tanken fra kap. 1.4: at et tall kan representere et tegn. A er 65.
Ingenting mer trengs. Resten av kapitlet er begreper og skiller.
Løkke 1 — Tegn: ASCII og UTF-8 (~12 min)
Da du skrev navnet ditt i et skjema i går, ble hver bokstav lagret som et tall. Hvilket tall, og hvor mange byte det tok, avhenger av hvilken tegnkoding systemet bruker.
Det er to du må kjenne: ASCII, som er den gamle og enkle, og UTF-8, som er den som faktisk brukes i dag.
Tegnkodingen som gir hvert tegn et tall mellom 0 og 127, altså 7 bit per tegn.
Systematikken: store bokstaver ligger sammenhengende fra 65, små bokstaver fra 97, siffertegnene fra 48. Mellomrom er 32.
Begrensningen som er hele poenget: 128 koder rekker til det engelske alfabetet, sifrene og noen skilletegn. Det er ikke plass til æ, ø og å, og heller ikke til gresk, kyrillisk eller kinesisk.
Den faste feilslutningen: at ASCII er 8 bit. Det er 7 — den åttende biten i en byte var opprinnelig ubrukt eller en kontrollbit.
Tegnkodingen som bruker variabelt antall byte per tegn: 1 byte for de vanlige engelske tegnene, 2 for de fleste europeiske spesialtegnene, 3 for de fleste andre skriftsystemer og 4 for de mest sjeldne tegnene og emojier.
Den avgjørende egenskapen: UTF-8 er bakoverkompatibel med ASCII. De 128 ASCII-tegnene har nøyaktig samme koder i UTF-8 og tar én byte. En ren ASCII-fil er en gyldig UTF-8-fil.
Konsekvens du kan bli spurt om: A tar én byte, mens ø tar to. En tekst på hundre tegn kan derfor være mer enn hundre byte.
Den faste feilslutningen: at UTF-8 alltid bruker flere byte enn ASCII. For engelsk tekst er de identiske.
Hvor mange byte tar teksten Bra jobb! i ASCII, og hvor mange i UTF-8? Og hva med Bra jøbb!?
Bra jobb! i ASCII. Tell tegnene: B, r, a, mellomrom, j, o, b, b, utropstegn — 9 tegn. Hvert ASCII-tegn er én byte.9 byte.
Bra jobb! i UTF-8. Alle ni tegnene er ASCII-tegn, og UTF-8 er bakoverkompatibel. Derfor: 9 byte — nøyaktig det samme.
Bra jøbb! i UTF-8. Åtte av tegnene er ASCII og tar én byte hver. Tegnet ø er ikke ASCII og tar to byte i UTF-8.
8 · 1 + 1 · 2 = 10 byte.
Bra jøbb! i ASCII: lar seg ikke gjøre. ø finnes ikke i ASCII-tabellen.
Poenget: antall tegn og antall byte er ikke det samme. For ren engelsk tekst er de like; så snart et spesialtegn dukker opp, spriker de.
(Innsteg — tegnkoding.) Hvor mange byte tar hver av disse tekstene i UTF-8?
a) Hei
b) Hæ?
c) abc123
Skillet mellom tegnet 5 og tallet 5. Tegnet har ASCII-koden 53; tallet er verdien 5.
Siffertegnene ligger sammenhengende fra 48: 0 er 48, 1 er 49, og 9 er 57. Vil du gjøre et siffertegn om til tallverdien, trekker du fra 48.
Dette er den samme forskjellen som mellom OUT og OTC i kap. 1.4: den ene skriver verdien, den andre skriver tegnet.
Den faste feilen: å regne med at en tekstfil med tallet «255» tar én byte. Den tar tre — ett per siffertegn.
(Tegnkoding, svarform F2 — sant/usant-matrise.) Vurder hver påstand som sann eller usann, og begrunn.
a) ASCII bruker 7 bit per tegn.
b) En ren ASCII-fil er også en gyldig UTF-8-fil.
c) UTF-8 bruker alltid flere byte per tegn enn ASCII.
d) Teksten 2024 tar fire byte som ren tekst.
Løkke 2 — Fargekoder i heksadesimal (~12 min)
Åpner du fargevelgeren i et tegneprogram, står det gjerne #2E8B57 i et lite felt. Det er den ene regneoppgaven i dette kapitlet — og du kan den allerede.
Seks heksadesimale sifre er tre byte. Ett byte per farge: rød, grønn og blå.
0x 2E 8B 57
RR GG BB0x2E = 2·16 + 14 = 46 rødt0x8B = 8·16 + 11 = 139 grønt0x57 = 5·16 + 7 = 87 blått
Verdiområdet for hver komponent er 0 til 255 — nøyaktig det en byte uten fortegn rommer. 0 er ingen lys i den kanalen, 255 er full styrke.
De faste holdepunktene:
| Kode | R, G, B | Farge |
|---|---|---|
0x000000 | 0, 0, 0 | svart |
0xFFFFFF | 255, 255, 255 | hvit |
0xFF0000 | 255, 0, 0 | rent rødt |
0x00FF00 | 0, 255, 0 | rent grønt |
0x0000FF | 0, 0, 255 | rent blått |
Antall farger: hver komponent har 256 verdier, så totalt
256³ = 2²⁴ = 16 777 216 farger. Det er derfor formatet kalles 24-bits farge.Den ene fella: feil oppdeling. Deler du i to trippel-sifre eller starter fra feil ende, får du tre tall som ser plausible ut og er helt gale.
Hva er RGB-komponentene i a) 0xFF7F00 og b) 0x336699?
0xFF7F00. Del i par: FF, 7F, 00.- Rød: 0xFF = 15·16 + 15 = 255 — full styrke.
- Grønn: 0x7F = 7·16 + 15 = 127 — omtrent halv styrke.
- Blå: 0x00 = 0 — helt av.
R = 255, G = 127, B = 0. Full rød, halv grønn, ingen blå — det gir en oransje farge.
b) 0x336699. Del i par: 33, 66, 99.
- Rød: 0x33 = 3·16 + 3 = 51
- Grønn: 0x66 = 6·16 + 6 = 102
- Blå: 0x99 = 9·16 + 9 = 153
R = 51, G = 102, B = 153. Mest blå, minst rød — en dempet blåfarge.
Legg merke til mønsteret i b). Hvert par har to like sifre, og verdiene 51, 102, 153 er nøyaktig 1, 2 og 3 ganger 51. Det er ingen tilfeldighet: 0xNN med to like sifre er alltid N · 17.
(Fargekoder — samme heksadesimale teknikk som sjanger A.) Finn RGB-komponentene i 0x1E90FF.
Kryss av alle påstandene som stemmer om fargekoden 0xC0392B.
a) Grønnkomponenten er 39.
b) Blåkomponenten er 43.
c) Rødkomponenten er 192.
d) Fargen har mer rødt enn grønt og blått til sammen.
Fargerepresentasjonen der hver av de tre komponentene får én byte, altså 24 bit til sammen.
Antall mulige farger er — omtrent 16,8 millioner.
Dette er standarden på skjermer og i vanlige bildeformater. Noen formater bruker en fjerde byte til gjennomsiktighet, som gir 32 bit per piksel.
Den faste feilslutningen: at flere bit per farge betyr høyere oppløsning. Oppløsning er antall piksler; fargedybde er antall bit per piksel. De to er uavhengige.
Løkke 3 — Komprimering: hva som kan gjenskapes (~11 min)
Du har sikkert lagt merke til at et bilde tatt med mobilen tar noen få megabyte, mens det samme bildet ubehandlet ville tatt langt mer. Noe er blitt fjernet. Spørsmålet er hva — og om det kan komme tilbake.
Det er hele skillet i denne løkka, og det er det som testes.
Komprimering der hele originalen kan rekonstrueres eksakt fra den komprimerte fila. Ingen informasjon går tapt.
Eksempler: ZIP, PNG, FLAC, GIF.
Metoden bygger på å finne mønstre og gjentakelser: i stedet for å lagre «hvit piksel» tusen ganger, lagres «tusen hvite piksler».
Konsekvens: du kan komprimere og pakke ut så mange ganger du vil uten at kvaliteten synker. Kompresjonsgraden er til gjengjeld begrenset — en fil uten mønstre lar seg knapt komprimere.
Komprimering der informasjon forkastes permanent for å få fila mindre. Originalen kan ikke gjenskapes.
Eksempler: JPEG, MP3, MP4, AAC.
Metoden bygger på hva sansene våre ikke merker: JPEG forkaster fine fargedetaljer øyet ikke ser, MP3 forkaster lyd som maskeres av annen lyd.
Den viktigste konsekvensen: tapet er kumulativt. Lagrer du en JPEG på nytt hver gang du redigerer den, forsvinner mer for hver runde. Det finnes ingen vei tilbake.
Den faste feilslutningen: at JPEG er tapsfritt fordi bildet «ser likt ut». Det ser likt ut nettopp fordi metoden er god til å fjerne det du ikke ser.
Svarform F3. Plasser hvert format i riktig kolonne: tapsfri eller tapskomprimert.
1. PNG
2. JPEG
3. MP3
4. ZIP
5. FLAC
6. MP4
| Format | Kolonne | Hvorfor |
|---|---|---|
| PNG | Tapsfri | Bildeformat som gjenskaper hver piksel eksakt. Brukes til grafikk, logoer og skjermbilder |
| JPEG | Tapskomprimert | Forkaster fargedetaljer øyet ikke ser. Brukes til fotografier |
| MP3 | Tapskomprimert | Forkaster lyd som maskeres av annen lyd |
| ZIP | Tapsfri | Generell filkomprimering — en pakket tekstfil må komme ut identisk |
| FLAC | Tapsfri | Lydformat som gjenskaper opptaket eksakt. Større filer enn MP3 |
| MP4 | Tapskomprimert | Videoformat som forkaster både bilde- og lyddetaljer |
Fasit: tapsfri er 1, 4 og 5. Tapskomprimert er 2, 3 og 6.
Regelen som avgjør nesten alle slike oppgaver: spør hva formatet brukes til.
- Skal originalen kunne gjenskapes — et program, et dokument, en logo, et lydopptak i studio — må formatet være tapsfritt.
- Skal fila være liten nok til å sendes eller strømmes, og er den ment for øyne og ører — foto, musikk, video — er den tapskomprimert.
Den ene fella: PNG og JPEG er begge bildeformater, men står i hver sin kolonne. Det er ikke medietypen som avgjør, men hva formatet gjør med informasjonen.
Koble hvert format til riktig kategori. Formatene er nummerert, kategoriene bokstavmerket.
1. FLAC
2. JPEG
3. ZIP
4. MP3
A Tapskomprimert
B Tapsfri
Oppgi koblingene på formen «1→X».
Løkke 4 — Raster mot vektor (~10 min)
Det siste skillet handler ikke om komprimering, men om hvordan bildet er beskrevet.
Bilde lagret som et rutenett av piksler, der hver piksel har sin egen farge.
Eksempler: JPEG, PNG, GIF, BMP — og alt et kamera produserer.
Egenskapen som avgjør bruken: oppløsningen er fast. Forstørrer du bildet, blir pikslene større og bildet uskarpt eller rutete.
Filstørrelsen avhenger av antall piksler, ikke av hvor komplisert motivet er. Et helt hvitt bilde og et fotografi med samme oppløsning har like mange piksler — men det hvite komprimeres langt bedre.
Bilde lagret som en beskrivelse av former: linjer, kurver, sirkler og fyllfarger, med koordinater og parametere.
Eksempler: SVG, EPS, og formatene tegneprogrammer for illustrasjon bruker.
Egenskapen som avgjør bruken: bildet kan forstørres fritt uten å bli uskarpt, fordi formene regnes ut på nytt for hver visningsstørrelse. En logo i vektorformat ser like skarp ut på et visittkort og på en husvegg.
Begrensningen: vektorgrafikk egner seg ikke til fotografier. Et fotografi består ikke av rene former, og en beskrivelse av det ville blitt både enorm og unøyaktig.
Den faste feilslutningen: at vektorgrafikk «alltid er bedre». Til logoer, ikoner og diagrammer er den det. Til bilder av virkeligheten er den ubrukelig.
For hver oppgave: hvilket format egner seg best, og hvorfor?
a) Firmalogoen som skal brukes både på visittkort og på en reklameplakat.
b) Et fotografi som skal legges ut på en nettside.
c) Et skjermbilde av en feilmelding, som skal sendes til brukerstøtte.
b) JPEG. Fotografier består ikke av rene former, så vektor er utelukket. Og på en nettside teller filstørrelsen: JPEG kan forkaste fargedetaljer øyet ikke ser, og gir en fil som ofte er ti ganger mindre enn den tapsfrie varianten. Tapet gjør ingenting her — bildet skal ses, ikke redigeres videre.
c) PNG. Et skjermbilde har skarpe kanter, ensfargede flater og lesbar tekst. Nettopp der er JPEG dårligst: metoden lager synlige artefakter rundt skarpe kanter, og teksten blir grumsete. PNG er tapsfritt og komprimerer ensfargede flater svært godt, så fila blir både skarp og liten.
Regelen bak alle tre: velg etter hva innholdet er, ikke etter hva som «pleier å brukes».
| Innhold | Format |
|---|---|
| Former som skal skaleres | Vektor (SVG) |
| Fotografi | Tapskomprimert raster (JPEG) |
| Skarpe kanter og tekst | Tapsfri raster (PNG) |
Vurder hver påstand som sann eller usann, og begrunn.
a) Vektorgrafikk kan forstørres uten å bli uskarp.
b) Vektorgrafikk egner seg godt til fotografier.
c) PNG er tapsfritt, mens JPEG er tapskomprimert.
d) Filstørrelsen på et rasterbilde avhenger av antall piksler.
Kryss av alle påstandene som stemmer.
a) Fargekoden 0x00FF00 er rent grønn.
b) En tekst med hundre norske tegn kan ta mer enn hundre byte i UTF-8.
c) En JPEG som lagres på nytt ti ganger, mister mer informasjon for hver gang.
d) ASCII kan representere bokstaven ø.
1. Feil oppdeling av fargekoden. Seks sifre skal deles i tre par, ikke i to trippel-sifre. Og parene leses fra venstre: rødt, grønt, blått.
2. Å lese et heksadesimalt par som desimaltall. 0x39 er 57, ikke 39. Fella slår til når paret tilfeldigvis bare inneholder sifre 0–9, som i 39, 12 eller 50. Konverter alltid.
3. Å tro at JPEG er tapsfritt. Bildet ser uendret ut nettopp fordi metoden er god til å fjerne det du ikke ser. Informasjonen er borte, og tapet er kumulativt.
4. Å blande ASCII og UTF-8. ASCII er 7 bit og 128 tegn, uten norske bokstaver. UTF-8 har variabel lengde og er bakoverkompatibel med ASCII — for engelsk tekst er de identiske.
5. Å tro at vektorgrafikk egner seg til fotografier. Vektor er for former som skal skaleres: logoer, ikoner, diagrammer. Et fotografi består ikke av former.
6. Å blande fargedybde og oppløsning. 24-bits farge sier hvor mange farger hver piksel kan ha; oppløsningen sier hvor mange piksler bildet har. De to er uavhengige.
Begrepsbank til eksamen
Begrepsbanken er flashcard- og repetisjonsstoff — den gjentar det du nettopp har lest. Hopp trygt over ved førstegangslesing; tidsanslaget for kapitlet gjelder kjernestoffet.
Avtalen om hvilket tall som representerer hvilket tegn. Uten en tegnkoding er en tekstfil bare en rekke byte.
De to du må kjenne, er ASCII (7 bit, 128 tegn) og UTF-8 (variabel lengde, hele Unicode).
Dette er den samme typen avtale som tolkningskontrakten for en byte i kap. 1.3: bitene bærer ikke sin egen betydning.
At et nytt format kan lese alt det gamle formatet kunne, uten endringer.
UTF-8 er bakoverkompatibel med ASCII: de 128 ASCII-tegnene har samme koder og tar én byte. En ren ASCII-fil er derfor allerede en gyldig UTF-8-fil.
Dette er hovedgrunnen til at UTF-8 ble standarden framfor andre unicode-kodinger som brøt med ASCII.
At antall byte per tegn ikke er fast. I UTF-8 tar et tegn 1, 2, 3 eller 4 byte, avhengig av hvilket tegn det er.
Konsekvens: antall tegn og antall byte er ikke det samme. En tekst med hundre tegn kan ta mer enn hundre byte.
Den faste feilen er å regne filstørrelse ved å telle tegn. Det virker bare for ren ASCII-tekst.
Fargemodellen der enhver farge beskrives som en blanding av rødt, grønt og blått lys, hver med en styrke fra 0 til 255.
Modellen er additiv: alle tre på full styrke gir hvitt, alle tre av gir svart.
Den brukes på skjermer fordi de faktisk sender ut lys i disse tre fargene. Trykk bruker en annen modell, fordi blekk trekker lys fra i stedet for å legge til.
Antall bit som brukes per piksel til å beskrive farge. 24-bits farge gir én byte per kanal og dermed 16,8 millioner farger.
Noen formater bruker en fjerde byte til gjennomsiktighet, altså 32 bit per piksel.
Fargedybde og oppløsning er uavhengige: fargedybden sier hvor mange farger hver piksel kan ha, oppløsningen sier hvor mange piksler det er.
Antall piksler i et rasterbilde, oppgitt som bredde ganger høyde.
Et bilde på 1920 ganger 1080 piksler har litt over to millioner piksler. Med 24-bits farge tar det ubehandlede bildet omtrent 6 MB — derfor komprimeres bilder alltid.
Den faste feilslutningen er å blande oppløsning med skarphet: et forstørret lavoppløst bilde blir uskarpt uansett hvor mange farger hver piksel har.
Forholdet mellom original størrelse og komprimert størrelse.
Tapsfrie metoder oppnår typisk beskjeden gevinst på data uten mønstre, og stor gevinst på data med mange gjentakelser — et helt hvitt bilde krymper enormt.
Tapskomprimerte metoder oppnår mye høyere grad, fordi de har lov til å kaste informasjon. Prisen er at valget er endelig.
At tapskomprimering forverres for hver gang fila lagres på nytt, fordi hver runde forkaster mer informasjon.
En JPEG som redigeres og lagres ti ganger, er merkbart dårligere enn originalen — selv om ingen enkelt lagring så ille ut.
Praktisk konsekvens: arbeid i et tapsfritt format mens du redigerer, og eksporter til et tapskomprimert format først til slutt.
Tapsfritt rasterformat for bilder med skarpe kanter, tekst og ensfargede flater: skjermbilder, logoer, diagrammer.
Komprimerer ensfargede områder svært godt, og støtter gjennomsiktighet.
Den faste feilen er å bruke JPEG til slikt innhold. JPEG lager synlige artefakter rundt skarpe kanter, og tekst blir grumsete.
Tapskomprimert rasterformat laget for fotografier. Forkaster fargedetaljer øyet ikke oppfatter.
Gir ofte filer som er en tiendedel av den tapsfrie varianten, med nesten umerkelig kvalitetstap på et fotografi.
Uegnet til grafikk med skarpe kanter, og uegnet som arbeidsformat, siden tapet er kumulativt.
Tapsfri, generell filkomprimering som virker på alle filtyper.
Et komprimert program eller dokument må komme ut bit for bit identisk — ellers ville det ikke virket. Derfor kan generell filkomprimering aldri være tapskomprimert.
Kompresjonsgraden varierer sterkt: tekst og kode krymper mye, mens en allerede komprimert JPEG knapt krymper i det hele tatt.
Vektorformat for grafikk på nett. Bildet lagres som en tekstbeskrivelse av former med koordinater og farger.
Skalerer fritt uten kvalitetstap, og filene er små for enkel grafikk.
Uegnet til fotografier. Fordi formatet er tekst, kan en SVG-fil også søkes i og redigeres i en vanlig teksteditor — noe et rasterbilde aldri kan.
Det minste elementet i et rasterbilde: én rute i rutenettet, med én farge.
Ordet er en sammentrekning av picture element.
En piksel har ingen fysisk størrelse i seg selv — den får størrelse først når bildet vises på en skjerm eller trykkes. Det er derfor det samme bildet kan være både lite og stort uten å endre antall piksler.
Data om bildet som lagres i fila ved siden av selve bildeinnholdet: opptaksdato, kameramodell, eksponering og ofte posisjon.
Dette er verdt å kjenne fordi det er et personvernpoeng: et bilde du deler, kan røpe hvor og når det ble tatt. Du møter temaet igjen i kap. 3.7.
Metadata påvirker filstørrelsen lite, men fjernes ofte automatisk når bilder lastes opp til nettsteder.
Prinsippet bak RGB: fargene lages ved å legge til lys. Alle tre kanalene på full styrke gir hvitt, alle av gir svart.
Dette er hvordan skjermer virker — de sender ut lys i rødt, grønt og blått.
Trykk bruker motsatt prinsipp: blekk trekker fra lys fra det hvite papiret. Derfor har trykk sin egen fargemodell, og en farge på skjerm ser ofte litt annerledes ut på papir.
Synlig feil som oppstår som følge av tapskomprimering: uskarpe firkanter rundt skarpe kanter i JPEG, eller metallisk klang i en kraftig komprimert MP3.
Artefaktene er ikke en feil i fila — de er den forkastede informasjonen som mangler.
De blir tydeligere jo hardere fila er komprimert, og de stabler seg opp ved gjentatt lagring. Ser du firkantmønstre rundt tekst i et bilde, er bildet lagret som JPEG en gang for mye.
Dette kapitlet er skrevet av Anthropics toppmodeller (Claude Opus og Claude Fable) og er foreløpig ikke manuelt gjennomgått — kvalitetskontrollen gjøres av uavhengige KI-agenter, og innmeldte feil rettes fortløpende. Funnet en feil? Meld fra, så retter vi den. Les mer om hvordan innholdet lages.
Skolesaga er en uavhengig læringsressurs og er ikke tilknyttet eller godkjent av Universitetet i Oslo. Dette er ikke offisielt studiemateriell. Les mer.