Filesize van plaatje bestaat uit twee groottes

[hobbeldebobbel]

tja ik zou niet weten hoe ik het beter kan omschrijven.
ik heb in PS een plaatje gemaakt, een jpegje.
Als ik hem met opslaan als opsla als jpeg en een kwaliteit van 6 aan geef dan zegt ie mooi dat de grote van het plaatje mooi 7.0kb is.

Als ik daarna kijk in de verkenner is ie maar liefst 22.94kb.

Als ik hem daarna in Firefox op internet bekijk en daar de grote opzoek is ie: 45.83kb

kijk ik hetzelfde plaatje dan in irfanview bekijk dan zie ik daar twee grotes staan:


hoe kan dit nou?
de omschakeling van 1000-1024 misschien maar een verschil van 7.07 en 22.94 lijkt me een beetje heel erg veel......

[ThunderNet]

Het kan misschien liggen aan de hoeveelheid exif inhoud die je in je jpeg hebt zitten?

[Nvidiot]

Voor zover ik weet geeft Irfanview aan hoe groot 't plaatje uncompressed is / hoe groot 't compressed plaatje op de harde schijf is.

[hobbeldebobbel]

ok.
het zit hem dus in het verschil compressed/uncompressed.

het volgende dan: wat download een browser, de compressed versie neem ik aan.
Maar als ik hem upload dan wil ik eigenlijk die 7.07kb uploaden. maar ik kan alleen de 22.94kb variant uploaden.

[Savantas]

Je browser download de compressed versie (namelijk de enig beschikbare) maar als hij hem herkent als JPEG dan pakt hij hem uit. Zie de compressie als een zip bestandje. Ingepakt zie je alleen aan de eerste bits en/of extentie wat het is. Pas uitgepakt zie je de inhoud, oftewel de afbeelding.
Dus je plaatje zou als uncompressed (bv tiff) 47kB groot zijn, maar door de compressie word hij 29kB. Het verschil tussen de 7kB en de 29kB kan inderdaad extra info zijn (gemaakt met Photoshop versie ... op die en die datum). Maar zoek eens in de hulp van irfanview? Daar is het zo te vinden... Druk maar eens op I in Irfanview!

Zo heeft een collega van een vriend eens een scan gemaakt voor een Powerpoint presentatie. Hij vond die regelmatige brakke plaatjes maar niks en heeft hem op A4 op het maximum van de scanner getest (oftewel interpolatie, niet native resolutie) van 2400 dpi of nog een tandje hoger. Vervolgens meteen door scanprogramma op laten slaan als jpeg met 100% compressie. Het jpeg-bestandje was maar iets van 130 kB, maar de pc crashte steeds bij openen van de jpeg (in Powerpoint, Browser etc). Volgens mijn vriend steeg het geheugengebruik heel hard tijdens het (pogen om te) openen
Daarna had hij nog een harde dobber om aan zijn collega uit te leggen waarom ie met andere instellingen maar nog een scan moest maken...

[ Voor 68% gewijzigd door Savantas op 11-09-2006 15:28 ]

[Verwijderd]

Wat valt er uit te pakken aan jpeg? Iets wat er niet is kun je ook niet krijgen. Jpeg is al compressed en daar zit geen raw data verder in. Jpeg is daarom niet aan te raden om als orgineel te gebruiken/op te slaan.

[Savantas]

Tuurlijk zit daar wel info in, alleen de jpeg-compressie verbouwt je plaatje, oftewel het bevat gemuteerde RAW-data. RAW-data is in zijn kaalst gewoon een rijtje getallen per regel welke aangeven welke kleur die pixel is.
RAW gebruik je toch niet voor internet? Daar heb je jpg/gif en png voor. GIF en PNG behouden de informatie wel, maar GIF en PNG-8 kennen maar 256 kleuren. PNG-24 kan wel zonder verlies opslaan, maar je kan de compressie hiervan niet zo instellen als JPEG. En de bestandsgrootte (compressed dus) is vrijwel altijd iets groter dan hoge kwaliteit (dus lage compressie) jpg.
En reken maar dat bv een Word-bestand ook compressed info bevat, hoor. Dat is wel uit te pakken, maar een programma doet dat niet met WinZip, maar heeft gewoon intern een filter hiervoor.

[ Voor 27% gewijzigd door Savantas op 11-09-2006 15:30 ]

[Verwijderd]

jpg kan op 2 manieren comprimeren, info wegpleuren en zippen. Je pixeldata wordt namelijk omgezet naar een soort frequentiedomein (niet helemaal fouriertransformatie, maar vergelijkbaar).

Dit is nu nog lossless

Afhankelijk van je kwaliteits instellingen gooit ie dan de minst belangrijke frequenties weg (die er het minst inzitten dus).

Nu heb je loss

Verder kan je nog zippen, wat in principe weer een lossless stap is

-
extra info: er wordt een blokje van 8 x 8 (=64) pixels omgezet in een "stapel" van 64 wavelets die elk een nummertje hebben. Ipv 64 (bytes) pixels heb je nu 64 verschillende standaard plaatjes die met een bepaalde schaalfactor bij elkaar opgeteld worden. Je hebt hier dus nog steeds de volledige 64 bytes per blok en geen verlies. Vervolgens gooi je de plaatjes met de laagste schaalfactoren weg.

[Savantas]

Mophor! Nog nooit zo uitvoerig gelezen! Hulde! (Weer een voor de Grafisch FAQ)

[Verwijderd]

voor de wiskundigen: die 64 plaatjes zijn dus een volledige orthonormale set (wat 64 losse pixels uiteraard ook zijn)

[Janoz]

Om een plaatje weer te geven moet het geheel toch echt 'gerenderd' worden naar een hoogte x breedte bitmap. Je kunt nu eenmaal geen jpeg naar je beeldscherm sturen.

@Morphor: Het is idd geen fourier transformatie, maar een cosinus transformatie. Het voordeel hiervan is dat de laatste complexe resultaten zonder imaginair deel opleveren.

[ Voor 34% gewijzigd door Janoz op 12-09-2006 10:54 ]

[Verwijderd]

ook niet helemaal cosinus, het is namelijk niet periodiek, maar stopt aan de rand van 64 pixels, je ziet wel aan bijvoorbeeld het laatste plaatje dat er een soort envelope overheen zit. Het is volgens mij de inverse fourier van een blok (van 64), ben even kwijt hoe die heten. Soort golfpakketje. Sowieso is het allemaal wat vager dan we analytisch geleerd hebben, omdat het discreet is (vager voor mij dan )

edit: sinc functie, alleen dan uiteraard nog een gediscretiseerde versie, aangezien we met pixels werken (da's wat ik bedoelde iig, geen idee of het er echt 1 is)

[ Voor 32% gewijzigd door Verwijderd op 14-09-2006 07:22 ]