Svenska ElektronikForumet

Sitter med ett litet bildprojekt och måste få fråga er hur "stor" en bild egentligen är.

Bifogat är en bild från ett annat pågående projekt men tar den bara som exempel.
Enligt högerklick så ska denna bilden vara av storlek 62 747 bytes men "65 536 bytes on disk". Knepigt är också att den visas som 61,28 KiB när jag förhandsgranskar...

Frågor:

• 1. Vad är skillnaden på dessa två? Är det extra ytrymmet "on disk" ett slags slaskutrymme som blir pga diskens uppbyggnad?
  
  2. Säg att jag vill spara ner bilden på tex ett EEPROM och veta exakt hur många bitar jag behöver, hur går jag till väga?
  
  3. Är en del av datan skräp som jag kan formatera bort genom att konvertera bilden till bitmap eller liknande?

Ja, som sagt, många frågor och som ni förstår har jag inte speciellt bra koll på ämnet...

Eftersom minsta allokeringsenhet i regel är 4 kB på disken, så blir det en del slack, dvs du fyller inte upp det sista klustret, men det är fortfarande allokerat på disken.

SKillnaden i ditt exempel är 2789 byte, dvs lite mer än halva sista klustret är utnyttjat.

Om du själv lagrar bilden i ett eeprom, kan du själv avgöra om du skall använda ett filsystem (med overhead och eventuellt slack) eller bara lagra den som den är, och då tar den inte mer plats än sin verkliga storlek.

Ah just det, så hänger det ihop ja.

Ok, så den bifogade bilden är just 62 747 bytes stor, dvs 62747 * 8 = 501 976 bits ?

Sen gäller det alltså att lyckas skriva över en bild i "råformat" till EEPROM:et men det är nog en annan femma som hör hemma i programmeringskategorin. Ska söka lite på det.

Om du kunde plocka ut bilden och "hålla den i handen" så är den: 62 747 bytes.

Eftersom filer kommer och går på en hårddisk så kan en fil bli utspridd fysiskt lite här och var på disken där det finns plats.
På något sätt måste man då peka ut var på disken "klumparna" av filen ligger. Om dessa klumpar är små så
blir det väldigt mycket overhead att peka ut var de ligger, därför har man gärna stora "klumpar", lagrar
man få men stora filer så är det en fördel med väldigt stora "klumpar". Lagrar man väldigt många små filer så kanske
man i praktiken inte kan lagra mer än hälften så mycket data som disken egentligen rymmer eftersom en liten fil alltid tar upp minst en "klump".

61.28 * 1024 = 62750,72 ok den var lite skum, men väldigt nära 62747 i alla fall.

Men om din bild är en jpg så är det iofs lätt att lagra den i ett eeprom, men om sen en microprocessor ska avkoda jpeg
för att kunna få pixel-data så blir det (kanske?) tufft, om man inte kan hitta en färdig jpeg-rutin, men de kräver säkert minne och tar tid. Redan på min 50MHz Amiga tog det några sekunder att avkoda en jpeg-bild.

MVH: Mikael

Magnus_K skrev: Enligt högerklick så ska denna bilden vara av storlek 62 747 bytes men "65 536 bytes on disk". Knepigt är också att den visas som 61,28 KiB när jag förhandsgranskar...

Ki står för 1024. k kan stå för 1000 eller 1024, samma sak med K. Ki infördes just för att minska förvirringen så står det Ki eller Mi så vet man att det är 1024 respektive 1 048 576.

62 747 / 1024 = 61,276 d.v.s. avrundat 61,28.


Slack kan som sagt var uppstå på grund av att man måste allokera utrymme i klumpar. Filsystem kan ha olika storlek på minsta allokeringsenhet, vissa filsystem är mer flexibla än andra.

Att använda något komprimerat format (ex. packa bilderna i en ZIP-fil) är ett sätt att få bort slack (men filerna blir då svårare att komma åt).

Det handlar om indexering. På hårddisken måste det finnas ett index som pekar ut var varje fil börjar. Om detta index ska kunna peka ut en enskild byte på disken (d.v.s. filer ska kunna lagras utan slack) så blir index väldigt stort (eftersom fältet för pekaren måste ha många bitar). Eftersom de flesta filer är relativt stora är det bättre att låta index peka på större block. Men i en ZIP-fil så ligger det ett index som bara gälelr ZIP-filen och det kan peka ut varje enskild byte i ZIP-filen.

Ska du spara på EEPROM kan du oftast ha en adresspekare som pekar på en enskild adress och då slipper du slack.


Att konvertera till annat format kan i vissa fall spara utrymme, men för foton är JPEG oftast det bästa. Men det går ju att spara i olika kvalitet i JPEG. Man får prova sig fram vad som funkar, går inte att räkna ut i förväg.

Om du ska lagra den där bilden i råformat så blir det inte ca 62kiB. Det blir 300x400x3= ca 351,6kiB
Alltså inte RAW-format då, utan rådatan för RGB-värdena.

@adent, Nerre & MadModder:
Tack för bra och ingående svar! Nu förstår jag också varför det står "KiB" när man tex laddar upp en bild till forumet.

Det jag är nyfiken på är det ni alla 3 är inne på dvs pixel-storlek, eller avkodad rå RGB-data, eller vad det verkliga ordet kan vara.
Det MadModder skriver i ovan inlägg är intressant. Som jag skriver nedan har jag förstått det:

300x400 är alltså pixelantalet. Om det vore bara en svartvit bild där var bit representerade en pixel. Så borde denna bilden alltså vara 120'000 bitar stor. Jag misstänker att man multiplicerar detta sedan med färgdjupet, som i detta fall är 3 bitar per pixel.

Om man laborerar lite med den bifogade bilden i första inlägget och bara fokuserar på den avkodade RGB-datan. Vet ni om någon gratis windowsmjukvara där jag kan labba lite. Tex om jag vill prova att konvertera den bilden till 8-bitars gråskala?

Äsch, klämmer in en fråga till. Om jag skapar en bild med 8-bitars gråskala och den får max överstiga 150'000 bits. Det blir alltså en bild med 150'000/8 = 18750 pixlar med tex mått på 187 x 100 ?

Färgdjupet på den bilden du visar är väl 24 bitar per pixel? D.v.s. 3 färgkanaler om vardera 8 bitars djup.

(Sorry om jag inte riktigt orkat läsa alla detaljer i tråden och svarar på fel fråga så att säga)

Precis. 24 bitar per pixel. 256 nivåer för röd, 256 för grön, och 256 för blå. Det är 8 bitar per basfärg. 16777216 möjliga färgtoner.
Och 300x400x3x8=2 880 000 bitar=351,5625kiB.

Om den vore svartvit, som i gråskala, så är det 8 bitar per pixel.
Om det bara vore svarta och vita pixlar, som i ett gammalt fax, då är det en bit per pixel.

Ändra bitdjupet kan man göra med Gimp.
I Gimp 2.6 är meny-valet Bild --> Läge.

RGB: Varje punkt har 3 * 8 = 24 bitar.

Gråskala: Varje punkt har 8 bitar (256 nivåer av grått).

Indexerad: Där kan man välja hur många färger bilden ska ha.
Bilden får en palett, och varje bildpunkt har ett värde
som pekar på en viss färg i paletten.
Hur en bild som bara behöver t.ex. 3 eller 5 bitar
för varje färg sparas, vet jag inte. Det borde bero på
vilket format bilden sparas i.

För att ändra från ett indexerat läge till ett annat
så kan man få gå till RGB och tillbaka till indexerad
för att det ska hända något om man använder Gimp.

När man gör en bild indexerad kan man även välja
"dithering", som är olika sätt att försöka bevara bilden
även fast det inte finns tillräckligt med färger,
genom att sprida ut färgpunkterna på olika sätt.
Se t.ex. bilden på gitarren här.

Dock står det 2-bit där. Det ska vara 1-bit.

Ja, det ska det ju.

Ahaa, nu hänger jag med. Läste fel på ditt tidigare inlägg MadModder!

Laddade ner senaste versionen av Gimp och det verkar vara ett kanonprogram. Verkar kunna lösa de flesta problemen jag har. Tack för tipset BJ!

I nuläget ska jag labba lite med enbart 1-bits pixlar och fastän dithering tycks få mycket bättre 1-bitars bilder så vet jag inte om det inte blir mest tydligt utan den "funktionen".
Nedan är samma bild med och utan dithering. Nerpressad till under 150'000 bitar i binärt format. (tror jag i alla fall)

Nej men det här blir bra. Har lärt mig skitmycket om bilduppbyggnad och nu ska det bara bli att använda denna datafil för att dra in på mitt minne och sedan kunna nyttja den igen.

Som vanligt suverän support från forumet

Dithering försöker skapa gråskala mha pixeldensitet. På bildskärmar är pixlarna lite för stora för att det ska fungera, men om du backar 3 meter från skärmen så ser det nog bättre ut. I tryckta medier så är det i princip dithering man använder för att skapa olika färgtoner (men prickarna är skitsmå, man kan kolla med lupp på en dagstidning eller veckotidning så ser man).

Precis! Noterade detta när jag förhandsgranskade bilden i mappen. Såg jättebra ut då men vid förstoring ganska mycket sämre, lik en Monet