Komprimera jpg?

[jontemannen]

Hej!
Jag jobbar i ett stort projekt här på jobbet där vi har en massa foton i jpg-format på en gemensam projektplats på internet. Vi får hela tiden utöka utrymmet men nu börjar det bli stopp. Kan man komprimera (typ zippa) jpg mer eller är det redan komprimerat så mycket det går? Alternativt kan man ju göra alla bilder mindre men då tappar man ju upplösning. Om jag ändå ska förminska mina bilder... finns det en funktion i ex PS som gör att man kan fixa detta för en hel bunt bilder i taget?

Tacksam för hjälp!

Jonas

 

[joppis]

Om det verkligen är så att ni prioriterar kvantitet före kvalitet så kan ni komprimera bilderna mera. Men det blir ju inte så snyggt och jag hoppas ni har "originalen" kvar...

När man sparar en bild i bildhanteringsprogram brukar man ofta kunna välja hur hård komprimeringen ska vara.

 

[jontemannen]

Jo det är ju sant.
Frågan var:
1 - kan man packa ihop, typ zippa (om det finns ngt annat program), jpg mer? Alltså att man inte tappar upplösning.

2 - hur komprimerar man fler bilder i taget i PS?

 

[tomasandersson]

För att behandla flera bilder i taget, sk batchjobb, se

http://www.fotosidan.se/cldoc/3765.htm


Edit: Jag skulle ju skriva något om komprimering också. När det gäller zip eller liknande på jpg, testa på ett par bilder och se själv om det blir någon skillnad! Jag tror inte att du kommer att få speciellt mycket bättre resultat.

 

[arvro395]

jontemannen skrev:

1 - kan man packa ihop, typ zippa (om det finns ngt annat program), jpg mer? Alltså att man inte tappar upplösning.

Nej, inte så att de minskar nämnvärt i storlek.

 

[jontemannen]

Ok, tack. Det var som jag trodde då.

Jonas

 

[tec]

Programmet stuffit kan komprimmera jpeg ganska mycket utan att du får några kvalite förluster. Den funktionen finns bara till mac ännu i stuffit 10.

 

[Nome Nescio]

Vad skall ni ha bilderna till? Är det bara för att visa på skärmen så kan man ju dra ned på upplösningen, det är sällan man behöver mer än 1024x768 men ofta så klarar man sig på 800x600. Då kan man komprimera så att bildfilen inte blir större an 100kb utan att tappa allt för mycket i kvalité.

 

[epep]

tec skrev:
Programmet stuffit kan komprimmera jpeg ganska mycket utan att du får några kvalite förluster. Den funktionen finns bara till mac ännu i stuffit 10.

Hmm, hur går det till?
Förlustfri komprimering av jfif-bilder brukar inte ge speciellt mycket.
Ex:
-rw-r--r-- 1 ep ep 590427 2006-04-21 14:57 DSC_0122.jpg
-rw-r--r-- 1 ep ep 562473 2006-04-21 15:19 DSC_0122.jpg.hmm.gz
-rw-r--r-- 1 ep ep 562594 2006-04-21 15:19 DSC_0122.jpg.zip

Jag har ganska svårt att förstå hur stuffit skulle kunna förlustfritt komprimera *mycket* bättre än så.
Jag skulle gärna vilja se exempel där stuffit lyckas mycket bättre. Du får gärna skicka mig en jpeg-fil och ett stuffit-arkiv med jpeg-filen komprimerad så jag kan se om 1) komprimeringen verkligen är förlustfri och 2) hur stor skillnaden mellan filerna är.

/ep

 

[Nemesis]

En annan variant är om bilderna har EXIF information och kanske en tummnagel så kan man spara en del genom att ta bort all EXIF information. Detta ger ingen skillnad på bilden!

 

[epep]

Om du vill komprimera en massa filer kan du med fördel använda gd-biblioteket och skriva ett litet program som komprimerar jpeg-filerna. Då alltså med jpeg-komprimering och sålunda icke förlustfri komprimering. Resultatet blir bra och det är enkelt.

/ep

 

[tec]

epep skrev:

Jag har ganska svårt att förstå hur stuffit skulle kunna förlustfritt komprimera *mycket* bättre än så.
Jag skulle gärna vilja se exempel där stuffit lyckas mycket bättre. Du får gärna skicka mig en jpeg-fil och ett stuffit-arkiv med jpeg-filen komprimerad så jag kan se om 1) komprimeringen verkligen är förlustfri och 2) hur stor skillnaden mellan filerna är.

/ep

Inget konstigt alls. Jpeg är komprimerad med en ganska enkel huffmankodning. När du där försöker komprimera den redan komprimerade koden kommer filen vara kvar på samma storlek eller möjligtvis bli ännu större. Det stuffit gör då är att packa upp huffmankodningen och komprimera filen igen med en bättre algoritm som komprimerar filen ännu mer. Därför får du en mindre fil utan att den behöver göra om hela jpeg algoritmen som kommer förstöra bilden ännu mer.

Hoppas det inte vart för tekniskt. Men den byter helt enkelt ut huffman mot något bättre. Sitter tyvärr inte vid någon mac just nu så kan inte visa med något exempel.

 

[arvro395]

tec skrev:
Men den byter helt enkelt ut huffman mot något bättre.

Oj, det var smart!

 

[epep]

tec skrev:
Inget konstigt alls. Jpeg är komprimerad med en ganska enkel huffmankodning. När du där försöker komprimera den redan komprimerade koden kommer filen vara kvar på samma storlek eller möjligtvis bli ännu större. Det stuffit gör då är att packa upp huffmankodningen och komprimera filen igen med en bättre algoritm som komprimerar filen ännu mer. Därför får du en mindre fil utan att den behöver göra om hela jpeg algoritmen som kommer förstöra bilden ännu mer.

Hoppas det inte vart för tekniskt. Men den byter helt enkelt ut huffman mot något bättre. Sitter tyvärr inte vid någon mac just nu så kan inte visa med något exempel.

Det är något mycket konstigt med den av dig beskrivna algoritmen.
För att den ska kunna fungera krävs att den algoritm som stuffit använder är förlustfri, annars introduceras *ännu* mer komprimeringsartefakter. Jag har svårt att se hur en förlustfri komprimeringsalgoritm skulle kunna komprimera en jpeg-bild så att bilden blir mindre än jpegen, men det är kanske möjligt. Är det inte en förlustfri komprimeringsalgoritm som används så introduceras nya artefakter.

Ok för att man kan packa upp Huffman-kodningen och packa om med en annan förlustfri kodning, men hur mycket vinner man på det?
Jag är intresserad av att se exempel.

/ep

 

[tec]

epep skrev:
Det är något mycket konstigt med den av dig beskrivna algoritmen.
För att den ska kunna fungera krävs att den algoritm som stuffit använder är förlustfri, annars introduceras *ännu* mer komprimeringsartefakter. Jag har svårt att se hur en förlustfri komprimeringsalgoritm skulle kunna komprimera en jpeg-bild så att bilden blir mindre än jpegen, men det är kanske möjligt. Är det inte en förlustfri komprimeringsalgoritm som används så introduceras nya artefakter.

Ok för att man kan packa upp Huffman-kodningen och packa om med en annan förlustfri kodning, men hur mycket vinner man på det?
Jag är intresserad av att se exempel.

/ep

Förstår inte vilken del som är svårt att förstå. Men jpeg består av 3 delar. DCT transformering, Kvantisering av data, Packning av data. De två första är förstörande, då man tar bort data som inte är synligt för ögat. Den sista är helt förlustfri och det är den man har bytt ut mot en nyare förlustfri packningsalgoritm.

Men du kan läsa deras whitepaper. Den förklarar det antagligen bättre än jag kan göra här på några rader. I den finns exempel filer som är komprimerade och dom ligger på mellan 20-35% bättre komprimering än vanlig jpeg.

http://www.stuffit.com/imagecompression/wp_stuffit_imgcomp.pdf

 

[epep]

tec skrev:
Förstår inte vilken del som är svårt att förstå. Men jpeg består av 3 delar. DCT transformering, Kvantisering av data, Packning av data. De två första är förstörande, då man tar bort data som inte är synligt för ögat. Den sista är helt förlustfri och det är den man har bytt ut mot en nyare förlustfri packningsalgoritm.

Men du kan läsa deras whitepaper. Den förklarar det antagligen bättre än jag kan göra här på några rader. I den finns exempel filer som är komprimerade och dom ligger på mellan 20-35% bättre komprimering än vanlig jpeg.

http://www.stuffit.com/imagecompression/wp_stuffit_imgcomp.pdf

Jag ska citera det jag skrev tidigare:
"Ok för att man kan packa upp Huffman-kodningen och packa om med en annan förlustfri kodning, men hur mycket vinner man på det?
Jag är intresserad av att se exempel."

Det man vinner på i jpeg-komprimeringen är att man tar bort en massa högfrekvenssignal efter DCT. Denna kvantisering är den förlustbringande delen i jpeg (tillsammans med reduceringen av chromakanalerna, som sker innan DCT och efter färgrymdsomvandlingen). DCT i sig själv genererar väl bortsett avrundningsfel inte någon förlust? Därefter körs Huffman-kodningen.
Jag undrade helt enkelt hur mycket man vann, med tveksamhet till att det var speciellt mycket, på att köra en annan kodning än Huffman och exempel på detta. Så enkelt var det.
StuffIt anger enligt länken du hänvisar till ovan en vinst på ca 30% (och de tycks ha använt exempelfiler och verkar även i övrigt trovärdiga).

Nästa fråga är vad man ska med metoden till. Mot bakgrund av att en annan algoritm än Huffman används (och jag antar att det inte är den andra bättre kompressionsmetoden som finns i jpeg-standarden) så kommer inte någon bildläsare att kunna läsa bilderna (än så länge i varje fall). Att StuffIt dessutom har patenterat metoden gör väl tyvärr att väldigt få bildvisningsprogram någonsin kommer att använda den.

/ep

 

[tec]

epep skrev:

Nästa fråga är vad man ska med metoden till. Mot bakgrund av att en annan algoritm än Huffman används (och jag antar att det inte är den andra bättre kompressionsmetoden som finns i jpeg-standarden) så kommer inte någon bildläsare att kunna läsa bilderna (än så länge i varje fall). Att StuffIt dessutom har patenterat metoden gör väl tyvärr att väldigt få bildvisningsprogram någonsin kommer att använda den.
/ep

Givetvis en viktig fråga. Men nu var området att använda det för att spara utrymme (som tråden handlar om), istället för mer generella packningsprogram som gz/bz2/7z som ger kanske 1-3%.

Att den är patenterad är ett problem. Där får vi samma problem som med "Den andra" kodningen i jpeg standarden dvs aritmetisk kodning. Som också är patenterad, därför den inte används så ofta men den ger runt 10% mindre filer.

Om det ska börja användas som bildformat måste stuffit alliera sig med andra och få in det i någon standard samt göra det helt fritt. Annars lär det ha en ganska tyst närvaro de närmsta 30 åren, som mycket annat.

 

[epep]

tec skrev:
Givetvis en viktig fråga. Men nu var området att använda det för att spara utrymme (som tråden handlar om), istället för mer generella packningsprogram som gz/bz2/7z som ger kanske 1-3%.

Att den är patenterad är ett problem. Där får vi samma problem som med "Den andra" kodningen i jpeg standarden dvs aritmetisk kodning. Som också är patenterad, därför den inte används så ofta men den ger runt 10% mindre filer.

Med reservation för att jag misstänker att du inte menar det du skriver i sista meningen utan "...därför används den inte så..." så instämmer jag. Jag ansåg det dock inte viktigt i sammanhanget.

Om det ska börja användas som bildformat måste stuffit alliera sig med andra och få in det i någon standard samt göra det helt fritt. Annars lär det ha en ganska tyst närvaro de närmsta 30 åren, som mycket annat.

gzip och 7zip använder varianter av LZ77 för att komprimera data. En tidigare version av bzip2 (dvs bzip) använde aritmetisk kodning. Jag ska se om jag får tag på den.
Komprimering av en oren (dvs en fil där det sannolikt finns kvar metadata) jpeg-fil med något av dessa program reducerar filstorleken med ca 10% (undrar hur mycket kompressionen av metadata står för). Lite lek med filen i gd-biblioteket (eg resize) brukar plocka bort metadata, och efter det komprimerar inte något av programmen filen alls.
Jag ska leka lite med libjpeg i morgon och se vad som händer om man komprimerar den ej huffman-kodade "jpegen". Jag ska nog hämta StuffIt och deras SDK också, och se om deras uttalanden håller.

 

[epep]

[dubbelpost raderad]

 

[Arctic]

Den här nya metoden finns i version 9 för Windows.

Jag plockade hem den för att testa och på den enda testbild jag komprimerat än så länge så var originaljpegen på 3440 kb och sitx-arkivet blev 2691 kb, ungefär 22% mindre alltså.

(Efter att ha testat på fyra andra filer så har resultatet blivit 21% - 28%.)

Sedan packade jag upp arkivet och gjorde en binärjämförelse och de var identiska. Inte för att jag tvivlade egentligen men bara för att vara säker.

Nackdelarna som jag ser det

Man måste köpa Stuffit för att kunna navända det och jag misstänker att det kan bli svårt att få tag på tredjepartsmjukvara som stödjer det formatet (speciellt då det är patentansökt. Mjukvarupatent suger, det är ju bara matematik :-/)

Det är ett arkivformat och inte ett bildformat så man måste först packa upp bilden för att kunna titta på den.

Det tar relativt lång tid att packa upp bilderna.

Programmet rapporterade ett fel när jag packade upp bilden igen. (De senare testerna gick dock bra.)

Fördelarna

Bilderna tar mindre plats.

Man kan skapa självuppackande arkiv så man är inte beroende av Stuffit för att packa upp filerna. Så länge man kör ett operativsystem som är binärkompatibelt iaf.