Fråga:
Sänker det bara att öppna och stänga en JPEG-fil bildkvaliteten?
markthomas
2014-10-30 19:09:45 UTC
view on stackexchange narkive permalink

Jag har haft en hel del fotografering klasser, läst många fotoböcker, och avskärmade många forum. Och jag kan inte hitta ett konsekvent svar på denna fråga. Ett "läger" säger att bildkvaliteten försvinner varje gång du öppnar och stänger en JPEG-fil (på grund av komprimering). Annat läger säger att det inte går förlorat på bildkvaliteten om du inte redigerar fotot och sedan sparar det igen.

Gör det skillnad om:

  • Jag öppnar bild i en standardbildvisare och enkelt "stäng" bilden?
  • Jag öppnar bilden i Photoshop Elements Editor och stänger den där?
  • Om jag helt enkelt stänger en bild vs. -spara den?

Kan någon ge ett enkelt svar när en JPEG stängs eller sparas orsakar en minskning av bildkvaliteten och när det inte gör det?

Att öppna en JPEG "dekomprimerar den" inte och stänger den "komprimerar den" inte och orsakar förlust av kvalitet. Komprimering (och "skada") görs när JPEG ursprungligen genereras, inte_ när den öppnas.
@ElendilTheTall: öppnar en JPEG-bild definitivt * kommer * att dekomprimeras, åtminstone om du genom att öppna menar att du faktiskt visar den snarare än filsystemets funktion.
Möjlig duplikat av [Vilken bildkvalitet går förlorad när en JPEG-bild sparas i MS Paint?] (Https://photo.stackexchange.com/questions/34878/what-image-quality-is-lost-when-re- spara-a-jpeg-bild-i-ms-färg)
Tolv svar:
Michael Borgwardt
2014-10-30 19:52:55 UTC
view on stackexchange narkive permalink

Detta är baserat på ett missförstånd. Kvalitetsförlust sker endast under komprimeringen som görs när en bild sparas som JPEG. Men det spelar ingen roll om det redigerades eller inte.

Så: du kommer (med några mycket specifika undantag, se kommentarer) tappar kvalitet om du öppnar en bild i en bildredigeraren och spara den igen, även om du inte gjorde några ändringar. Men om du bara öppnar den för att visa den och sedan stänger den istället för att spara, ändras ingenting.

Förresten: det här är bara för traditionella bildredigeringsprogram som Photoshop. Program som Lightroom som "utvecklar" RAW-filer följer ett annat tillvägagångssätt (även vid hantering av JPEG-filer): de håller alltid originalbilden intakt och sparar separat de redigeringssteg som gjordes, som tillämpas när de slutliga resultaten exporteras. Så med sådana program behöver du inte oroa dig för att förlora kvalitet (mer än en gång, det vill säga). Men då ska du ändå inte använda JPEG-källfiler för dem.

"du _förlorar kvalitet ... även om du inte gjorde några ändringar." Det beror på applikationen. En applikation kan mycket väl veta att inga ändringar gjordes och skriva om det ursprungliga komprimerade schemat utan ytterligare kvalitetsförlust jämfört med original JPEG.
Ja, eller om det programmet som standard är maximal JPEG-kvalitet (läs: minst lika bra som originalkvaliteten) och ingen av ändringarna har tillräcklig inverkan på bilden för att orsaka en nettoförlust av kvalitet genom komprimering (laddning av en perfekt komprimerad JPEG och att föra den igenom en kompressor igen gör inte kvaliteten magiskt sämre).
@DocMax: teoretiskt möjligt, men känner du till ett program som definitivt gör det?
@LightnessRacesinOrbit: Jag är väldigt säker på att du har fel i det. Omvandla data från frekvensområdet till det ursprungliga och tillbaka kan lägga till ytterligare fel på grund av kvantisering varje gång. Kanske kommer det så småningom att konvergeras mot något steady state, men jag tvivlar på det.
@MichaelBorgwardt: Jag erkänner att jag begår någon form av handvågig gissning, i hopp om att konvergens är i spel här. Jag förstår inte riktigt varför det inte kan vara; det är verkligen inte helt omöjligt i det mycket allmänna fallet med en förlust av kompression.
@MichaelBorgwardt `jpegtran` kan användas för att förlustfritt skära eller rotera en JPEG, bland andra olika omvandlingar. Jag använder den ofta för att ytterligare minska filstorleken och / eller ta bort oönskade fluffar som EXIF-data, kommentarer, etc: `jpegtran -optimize -copy none -perfect -v input.jpg> output.jpg`
Vissa program låter dig inte ens spara (eller bokstavligen bara göra ingenting) om inte det öppna projektet är smutsigt (du gjorde ändringar). Du kan dock alltid spara som ... för att göra en kopia.
@LordNeckbeard `jpegtran` gör något mycket specifikt annorlunda än vad en bildredigerare gör.
@Rawling Varför skulle den skillnaden betyda? Att nämna det var relevant för diskussionen.
@MichaelBorgwardt Jag har gjort tester med imagemagick, och det konvergerar faktiskt efter en handfull sparningar. Det finns exempel på en annan fråga här ... Jag hittar den senare ....
Här: http://photo.stackexchange.com/a/34192/ konvergerade i 8 eller 9 cykler i mina exempel.
@mattdm: för ett motexempel, vår egen Jeff Atwood fick allt dåligare resultat efter 10 cykler: http://blog.codinghorror.com/a-comparison-of-jpeg-compression-levels-and-recompression/ - så jag antar att det beror på den specifika bilden också
@LordNeckbeard `jpegtran` vet inte medvetet att inga ändringar gjordes och skriv om det ursprungliga komprimerade schemat utan ytterligare kvalitetsförlust, det använder bara * aldrig en förlustkomprimering *.
@DocMax: Det kräver antingen att 1) ​​appen lagrar i minnet (eller läser om) den komprimerade strömmen, eller att 2) den faktiskt inte skriver om JPEG-filen och lämnar den intakt (inklusive tidsstämpel, om den finns). Mycket osannolika scenarier
Jag håller med om att det är sällsynt att en applikation håller fast och skriver om den komprimerade strömmen som den är. Jag har sett det en gång, men det var för många år sedan när minnet var mer värdefullt än det är idag. Min poäng var bara att "_förlorar kvalitet" innebär att kvalitetsförlust inte alls kan undvikas; Jag skulle inte ha något problem med "kommer nästan säkert att förlora kvalitet".
Jag för det andra att det är helt möjligt för ett jpeg-program att dekomprimera redigera och spara en fil (med viss begränsning) utan ytterligare kvalitetsförlust. DCT kan göras med tillräcklig precision för att helt återställa frekvensdata som lagrades i original-jpeg (detta är ett problem), och en kodare kan välja att kvantifiera data hur den vill. Det kan alltid välja en kvantisering som inte klippar precisionen mer än den redan hade om den vill. Huruvida det finns faktiska kodare som gör detta är naturligtvis en annan fråga, det är möjligt i specifikationen.
@TimSeguine: "Det kan alltid välja en kvantisering som inte klipper precision mer än den redan var om den vill" - är det faktiskt möjligt med tanke på begränsad precision för dina numeriska typer?
@MichaelBorgwardt ja. Om det var möjligt för den första kodaren är det också möjligt för den andra.
@TimSeguine - det är baserat på antagandet att den exakta originaldata återhämtades från den första kodningen, vilket med tanke på kodningens förlorade karaktär innebär att det är osannolikt även under perfekta / labbetillstånd.
@JamesSnell Det är möjligt att beräkna DCT och invers DCT med godtyckligt hög precision. Det är allt som är nödvändigt. Period. Det är inte särskilt svårt även i praktiken. JPEG är bara förlorat på grund av kvantiseringssteget. Om vi ​​lämnar det och har en bra DCT-underrutin, kan vi göra många saker med data utan att minska kvaliteten ytterligare, inklusive beskärning, 90 graders rotation och reflektion. Det är inte bara en teoretisk möjlighet, det finns programvara som gör detta. Under laboratorieförhållanden. Jag förklarar bara hur det är möjligt.
@TimSeguine: Nej. Programvaran du pratar om utför inte alls en DCT eller invers DCT - den ordnar bara helt komprimerade data med hjälp av intim kunskap om formatet och dess symmetrier.
@MichaelBorgwardt Är du en trollkarl? Kan du läsa mina tankar? Jag nämnde aldrig ett specifikt program. Jag bryr mig inte heller om hur ett program jag inte pratade om implementeras.
@TimSeguine: vilken programvara * pratade du * om då? Eftersom jag tvivlar mycket på att någon som har de kunskaper som krävs skulle använda en så absurd slösaktig och ineffektiv metod för att få samma resultat.
@MichaelBorgwardt Det är inte slösaktigt om det är mer allmänt. Poängen var (förutsatt att du har en högkvalitativ DCT-algoritm) du kan i stort sett göra vad som helst mot en jpeg utan att påverka dess kvalitet om du hoppar över kvantiseringssteget när du sparar det igen. Det är helt klart att du köper mer. Du kan inte göra bättre än någon annan som tittar på originalet, men du behöver inte göra sämre heller. Var bara försiktig och kvantifiera inte.
@TimSeguine - Om du inte håller med det här svaret är det dags för dig att bryta ut referenserna. Och om du vill ha en diskussion kan det vara bäst att flytta den till chatt.
@JamesSnell Du har helt rätt. Jag är bara inte säker på att det är värt någons tid för mig att fortsätta vara pedantisk om ett svar som ger OP rätt råd.
user32334
2014-10-30 19:19:14 UTC
view on stackexchange narkive permalink

Absolut inte. Du måste redigera filen och spara den igen som en JPEG för att förstärka effekterna av bildkomprimering. Att bara visa det har ingen effekt alls - om det gjorde det skulle alla JPEG-filer på webben "slitas ut" helt på en eller två dagar.

FYI - här är ett exempel på vilken typ av vägledning som jag tycker är förvirrande (det här är från en fotobloggs webbplats): "Vad är nackdelen med att fotografera .JPEG? Den har ett komprimeringsschema som orsakar bildförstöring varje gång filen öppnas och sparas. Nedbrytningen är liten. Du skulle nog inte märka det först. Men du skulle se det med tiden. "
@markthomas: det avgörande ordet är * sparad * - spara är en helt annan sak än att stänga.
+1 för att "slita ut" ... Google måste applicera färska lager "måla" varannan sekund på sin sökresultatsida!
@MichaelBorgwardt Faktiskt, men det kan missförstås som "varje gång filen öppnas och varje gång filen sparas". Beviljas att du skulle ha mycket större försämring om du sparade utan att öppna först, men jag tror fortfarande inte att öppning borde ha nämnts.
The Spooniest
2014-10-31 06:33:24 UTC
view on stackexchange narkive permalink

JPEG-komprimering kan beskrivas som två olika faser: först en förlustfas, sedan en förlustfri fas. Att förstå skillnaden mellan dem är viktigt för denna fråga. Det här är inte så mycket för att det hjälper till att förstå vad som händer, utan för att det hjälper till att förstå var de vanliga misstagen kommer ifrån.

Förlorad kompression händer bara när filen sparas . Detta är den del som orsakar förlust av kvalitet. Att bara stänga filen räcker dock inte för att utlösa förlust av komprimering: du måste spara den . Vissa redaktörer kan vägra att spara JPEG-filer som inte har redigerats, för att undvika att oavsiktligt utlösa förlustfri komprimering, men jag vet inte på toppen av mitt huvud om någon redaktör faktiskt gör det.

Förlustfri komprimering sker också endast när filen sparas . Huvudskillnaden är att även om det hände när filen stängdes utan att spara, så spelar det ingen roll eftersom den är förlustfri. JPEG använder båda teknikerna tillsammans.

Lossless dekompression händer när filen öppnas, men inte vid någon annan tid . Inte när det är stängt, och inte ens när det är sparat. Som med förlustfri dekompression, skulle det inte spela någon roll även om det hände under dessa tider, för det är förlustlöst.

"Lossy dekompression" händer aldrig. Det finns inget sådant . Det kan inte vara, för de data som slängdes ut under den förlorade komprimeringsfasen är borta. Om du på något sätt kunde rekonstruera det, skulle du ha en förlustfri komprimeringsalgoritm, inte en förlustfri. Jag nämner till och med konceptet eftersom det, efter att ha nämnt två typer av kompression, skulle se konstigt ut om jag nämnde en enda typ av dekompression utan att förklara varför.

Observera att sparar filen utlöser båda typerna av komprimering . Det finns inte så mycket kring detta, såvida du inte vet att bilden inte har redigerats, men då är det inte så mycket att spara den heller. Observera också att det bara att stänga filen utan att spara utlöser någon fas , inte ens den "säkra" förlustfria komprimeringen. På grund av detta kan bara att öppna och stänga filen inte minska bildkvaliteten .

Åter "ingen mening att spara" Jag har orolig för vad ett program skulle göra om jag bara redigerar metadata (Kommentar, anteckningar) när användargränssnittet är Open-edit-save och det finns ingen speciell indikation på att bilddata kopieras men inte komprimerad igen.
"Lossy dekompression" som ett koncept är perfekt men jag känner inte till någonting som implementerar det. Den komprimerade filen innehåller en viss mängd data; man kan föreställa sig en dekompressionsalgoritm som endast extraherar en version med låg upplösning av dessa data. Att göra det kan vara mycket snabbare än att extrahera all tillgänglig data, och man kan till exempel använda en sådan algoritm för att ge en förhandsgranskning. (Till exempel komprimerar JPEG en bild som en sekvens av 8x8 block. Du kan extrahera genomsnittsfärgen för varje block och göra det som en enda pixel för en förhandsgranskning av 1/8 storlek.)
@jdlugosz-program som endast uppdaterar metadata i allmänhet dekomprimerar / komprimerar inte bilddelen av JPG. De kopierar bara den delen som den är i den nya filen. JPG-filformatet är konstruerat så att det faktiskt är lättare och mindre arbete att göra det så om du bara behöver uppdatera metadata. Men allt beror på programvaran. Om det är dumt på det sätt det gör saker, finns det ingen väg runt det (förutom att använda annan programvara).
@DavidRicherby Det finns många program som använder dekompressionsmotorn för förhandsgranskningar och liknande. De flesta webbaserade fotoalbum gör detta för att skapa miniatyrer och för att skicka en lågupplöst version till en webbläsare med en liten skärm. I MacOSX gör miniatyrbilderna i Finder och iPhoto det. Jag misstänker att miniatyrer i Explorer på Windows gör det också, men jag är inte säker på den.
Egentligen kan AIUI, både JPEG-komprimering * och * dekompression vara (något) förlorande. Det vill säga, du kan inte exakt rekonstruera originalbilden från komprimerad data, * och * du kan inte (alltid) exakt rekonstruera komprimerad data från den komprimerade bilden. För det mesta, AFAIK, kan detta hända på grund av klippning: när de komprimerade YUV DCT-koefficienterna mappas tillbaka till 8-bitars RGB-pixelfärger, kan vissa pixlar hamna med färgvärden mindre än 0 eller större än 255, vilket kommer att klippas.
@DavidRicherby: Enligt vad jag förstår är varje punkt i en JPEG-fil en summa av olika värden multiplicerade med olika skalningsfaktorer; även om värdet generellt återges till ett värde med 8 bitar vardera för rött, grönt och blått, definieras värdena för punkterna mer exakt än det. Om man skulle JPEG-komprimera en bild som exakt matchade det avrundade resultatet av en JPEG-dekompression, skulle komprimering med samma inställningar som den tidigare bilden ge samma resultat som den tidigare komprimeringen, men avrundning som sker i dekompressionsprocessen bryter det.
Många program kan göra förlustfri rotation genom att rotera DCT-blocken utan att dekomprimera dem och därmed undvika det förlustfria komprimeringssteget. Så du kan inte säga att "att spara filen utlöser båda typerna av komprimering", även om det är sant för det mesta.
Carl
2014-11-23 13:55:29 UTC
view on stackexchange narkive permalink

Att bara öppna och stänga en JPEG-fil bör inte utlösa ett spara-kommando (i något program som jag känner till) och därför sker ingen återkomprimering.

För de gånger du faktiskt trycker på "spara", vad som händer beror på vilka ändringar du har gjort och hur smart det aktuella bildprogrammet är.

Användaren CutNGlass har redan nämnt ett exempel på en smart bild program, "Better JPEG", som utnyttjar det faktum att JPEG-bilder består av massor av oberoende kodade rektangulära pixelblock, och endast block som verkligen BEHÖVER komprimeras när bilden sparas. Med ett sådant program kan du till exempel ta bort röda ögon och när JPEG-bilden sparas komprimeras endast blocken som påverkades av ändringen. http://www.betterjpeg.com/features. htm

Denna teknik för att undvika att komprimera någon del av en JPEG-bild som inte behöver komprimeras är verkligen "gamla nyheter" (jag är ingen expert och jag har känt det i över ett decennium), så jag antar att jag har tagit det för givet att alla bra bildhanteringsprogram skulle hantera detta perfekt nu (vilket skulle innebära att det normalt inte skulle bli någon komprimering från att bara öppna en JPEG-bild och trycka på "spara", eftersom programmet skulle veta att det inte har gjorts några ändringar av några block och bara lämna dem orörda), men från att titta på den här frågan och dess olika svar kan jag bara samla det detta ÄR INTE sant! * Kanske är programmeringen bakom sådana lösningar mer komplicerad än jag tror att den skulle vara - annars hade alla JPEG-hanteringsprogram haft det för många år sedan! *

Hej ny användare. Tack för ditt bidrag, införandet av en länk till betterjpeg är ett användbart tillskott. Ur ett utvecklarperspektiv är situationen vad vi skulle kalla ett extremt edge-case - för att vara användbart är det beroende av att användaren gör en delvis redigering OCH vill ha exakt samma kvalitetsutmatningsinställningar OCH källfilen är ett av få JPEG-kodningsalternativ . För mängden arbete som ingår är det inte tillräckligt med fördel.
Hej @JamesSnell! Först och främst uppskattar jag verkligen din feedback och ger mig en förklaring till varför alla bildhanteringsprogram inte gör allt för att undvika nedbrytning av JPEG när det är möjligt. Men jag måste säga att det är ganska subjektivt om i detta programmeringsarbete är för mycket arbete och om användningsfallet representerar "extrema kantfall" eller inte! Det beror på hur många bildformat programmet hanterar och hur vanlig JPEG-användning är, och det beror på hur anal du är på att inte någonsin vill förlora något som du inte behöver förlora (onödigt förlust av bildkvalitet, i det här fallet) .
Jag skulle också säga att eftersom JPEG är världens # 1 (mest använda) bildformat, som i och för sig gör detta till något annat än ett "extrem edge-case" (åtminstone ordet "extrem" bör tas bort ). Om du också tänker på det faktum att denna blockhanteringsteknik, om den implementeras i ett bildprogram, kan användas för en mängd olika situationer (delvis redigeringar, som att ta bort röda ögon, rotera / vända bilden; beskära), att indikerar också något annat än en "extrem edge-case." Det kanske inte är den mest efterfrågade funktionen, men samtidigt är jag säker på att den skulle uppskattas!
Carl, jag håller med @JamesSnell om att detta är ett edge-fall - och jag har arbetat med en populär bildredigerare så jag har lite erfarenhet här. När du öppnar en fil kopieras den till en okomprimerad version i minnet för redigering * och originalet kastas omedelbart *. Detta sparar minne och ger dig flexibiliteten att använda valfritt filformat som källa. Jag har sett programvara som kan göra en förlustfri vändning eller rotation av en JPEG, men det är en mycket specialiserad funktion. Programmet du länkar till är den enda redaktören jag någonsin har sett som utvidgar den här funktionen till allmän redigering.
Tack för att du väger in, Mark - och tack för din insikt. Jag skulle emellertid fortfarande inte kalla detta "ett edge case", eftersom vi pratar om mycket vanliga typer av redigeringar med världens vanligaste bildfiltyp ... Att programmerare vill ha det enkelt och kanske inte bryr sig tillräckligt om bildnedbrytning för att det ska kännas "värt det" för dem att hantera detta är en förklaring till varför de flesta bildprogram inte hanterar detta, men det gör det inte till "ett edge case". JPEG-filen är normalt mycket mindre än den okomprimerade versionen, så den kan lagras i minnet och denna funktion läggs till.
Frecklefoot
2014-10-30 22:08:55 UTC
view on stackexchange narkive permalink

Du tappar definitivt ingen kvalitet bara genom att visa den. Men som påpekats ovan kan du förlora bildkvaliteten när du sparar den utan att göra ändringar om redigeraren komprimerar den när den sparar filen . Anta till exempel att du har en JPEG utan komprimering:

  1. Du öppnar den i GIMP, gör inga ändringar och sparar den
  2. GIMP frågar dig hur mycket komprimering du vill ha (kvalitet)
  3. Du anger 90% kvalitet (standard)

Gör detta 20 gånger så ser du en signifikant minskning av kvaliteten eftersom den har komprimerats 20 gånger. Om du sparar det utan komprimering (100% kvalitet) ser du ingen förändring.

JPEG _ har alltid komprimering; det finns inget sådant som "ingen komprimering" med JPEG. Det är i sig förlorat. Att skicka en [JPEG-komprimerad] bild genom en JPEG-kompressor med 100% kvalitet kan kanske inte leda till förlust av kvalitet.
Upprepad komprimering av en JPEG-bild i samma kvalitet försämras inte.
@geometrikal [Verkligen?] (Http://petapixel.com/2010/02/04/saving-jpeg-photos-hundreds-of-times/)
@geometrikal definitivt inte fallet
Exempel på kvalitetsförlust med återbesparing på samma kvalitetsnivå: http://photo.stackexchange.com/a/34192/
Observera också att 100% kvalitet inte är någon kompression.
Även utan komprimering har du fortfarande en färgutrymmesomvandling (vanligtvis mellan RGB och YCrCb som kommer att bli föremål för kvantiseringsfel.
Dan R
2014-10-30 21:39:46 UTC
view on stackexchange narkive permalink

Definitivt, som alla filer, om du inte trycker på "spara" utan bara stänger filen, kommer inga ändringar att göras. (tänk på det som ett ord Doc som du bara öppnar och stänger)

Om du gör ändringar kommer de flesta program att ge dig ett meddelande som frågar om du vill "spara ändringar"

Så svaret är definitivt nej på din fråga.

Hoppas det hjälper.

Lie Ryan
2014-10-31 05:01:11 UTC
view on stackexchange narkive permalink

Enkelt uttryckt:

  • Öppning: ingen förlust av kvalitet
  • Kopiering: ingen förlust av kvalitet
  • Visning: ingen förlust av kvalitet
  • Spara utan ändringar: kopieras, ingen kvalitetsförlust *
  • Sparar med endast metadataändringar: ingen kvalitetsförlust *
  • Sparar med ändringar av komprimeringskvalitet: förlust av kvalitet
  • Spara efter redigering av bilddata: förlust av kvalitet

* Beroende på program kan dåligt implementerade program faktiskt komprimera även när det inte behövs med den resulterande kvalitetsförlusten

Avkodning av digitala data är förlustfri. Det finns inte ett enda digitalt format där avkodning och visning kan förändra data.

Det är bara omkomprimering av bilddata som är potentiellt förlorade. Vissa redigeringsåtgärder som egentligen bara är metadataändringar bör inte orsaka kvalitetsförlust, till exempel är EXIF-rotation förlustfri.

Det är möjligt för ett program att generera en fil med hjälp av data som kopieras ordagrant från delar av bilden som inte har ändrats, men producerar nya komprimerade data för andra delar. JPEG-guiden, till exempel, gör det möjligt att markera "viktiga" områden i en JPEG och lämna dem som de är, samtidigt som andra mindre viktiga delar av bilden aggressivt komprimeras med olika mängder.
Kopiering av __filen__ (i Explorer, Finder, etc.) leder inte till kvalitetsförlust. Öppna bilden, göra en markera alla, kopiera, ny bild från kopia och spara sedan _null_ leder till kvalitetsförlust.
@supercat - blockersättning är endast möjligt för vissa jpeg-kodningsscheman. Men det selektiva kvalitetsalternativet (som endast i vissa områden) kan ge några intressanta platsbesparingar utan större bildförstöring på webben.
@JamesSnell: Jag använde JPEG Wizard för många år sedan; Jag har inte tittat för att se om / hur den har underhållits eller uppdaterats, men det kan ge stora utrymmesbesparingar i fall där en bild har några ställen där det behövs detaljer och mycket område där det inte är. I vissa fall kan suddig ut allt utom de primära ämnena i en bild * förbättra * bilden estetiskt samtidigt som den gör filen mycket mindre.
John Demetriou
2014-11-03 14:31:26 UTC
view on stackexchange narkive permalink

Enkelt uttryckt Nej).

För att vara specifik. När du sparar JPEG-bilden har du vissa förluster eftersom JPEG definieras som förlustkomprimering.

Bilden komprimeras med Huffman-kodning om jag inte tar fel. Nu när en bildredigerare öppnar en bild dekomprimerar den inte bilden. Den avkodar helt enkelt den komprimerade bilden så att skärmen kan visa vad som finns i den.

Men när du gör ändringar och sparar den igen komprimeras bilden till en ny jpeg med mer dataförlust. Programvara som GIMP frågar dig hur mycket kvalitet du vill ha så att du kan välja 100% för att behålla den befintliga kvaliteten.

Att öppna och stänga en bild nu utan att göra några ändringar spelar ingen roll hur den lagras och vilken data Är försvunnen. Att öppna den för visning och sedan stängning gör inga ändringar i filen. Oavsett fall (mp3, bild, orddokument). Eftersom ingenting sparas kommer kvaliteten alltid att vara densamma.

Men som tidigare svar har sagt, om du verkligen är orolig för dataförlust kan du helt enkelt använda andra format som png eller tiff.

Observera att du inte behåller den befintliga kvaliteten när du sparar fotot i GINMP med 100% -värdet för "kvalitetsprocentinställningen". Den ställer bara in vissa parametrar som används av kodaren till högsta möjliga kvalitetsnivå. Dessa inställningar är inte förlustfria.
Inga problem. Du kan läsa mer om det i [denna fråga] (https://stackoverflow.com/questions/7982409/is-jpeg-lossless-when-quality-is-set-to-100).
Steve Cox
2014-10-30 23:16:17 UTC
view on stackexchange narkive permalink

Det verkar finnas en hel del felinformation även i dessa svar.

JPEG är en förlustfri standard för kodning av block. Det är en frekvensdomänkod som får sin komprimering genom att representera bildkomponenter med högre frekvens med lägre precision. Blockstorleken är 8x8 pixlar.

För att koda en JPEG-bild tar du varje block genom att utföra en 2-D DCT och spela in resultatet i ett slags sicksackmönster med färre och färre bitar som börjar vid den lägsta frekvensen och slutar med den högsta. Precisionsprofilen styrs av en enda kvalitetsvariabel.

Så länge du har gjort denna process i ett block en gång kan du avkoda och koda om så många gånger du vill utan att förlora någon bildkvalitet (så länge du alltid använder samma kvalitetsvariabel). Detta är inte en överdrift; processen för avkodning och omkodning av ett jpeg-block kan göras perfekt förlustfritt, och alla redigeringsapplikationer som är värda sitt salt kan redan göra det.

Vad betyder det för en person som redigerar en bild? Om du öppnar en bild och sparar (kodar om) den med samma bildkvalitet förloras ingen kvalitet (din redigeringsapplikation skulle kunna berätta vilken kvalitetsvariabel som används för att koda bilden). Om du öppnar en bild och bara redigerar en del av den, är de enda blocken som ändras alls de 8x8 blocken du har redigerat. Allt annat kommer att vara exakt detsamma.

[Är] (http://petapixel.com/2010/02/04/saving-jpeg-photos-hundreds-of-times/) att [så] (https://www.youtube.com/watch?v= Fk6kV5N1rzs)?
Jag har inte undersökt noggrant, men jag antar att det är avrundningsfel som gör att detta inte exakt är fallet.
Om programmet använder samma Q-matris och du bara ändrar isolerade regioner är @stevecox-sammanfattningen korrekt. Om samma program används bör samma skjutinställning ge samma interna parametrar. Att beskära från vänster / topp kan ändra blockinriktningen; övergripande förändring som nyans och ljusstyrka berör allt och antingen kan införa hemsk nedbrytning utöver komprimeringens nominella kvalitet. Om det ursprungliga sparandet var av mycket hög kvalitet, blir effekterna subtila men kumulativa.
@mattdm, även utan avsiktlig avrundning av höga frekvenser (kvantisering), reduceras färginformationen i upplösning och appliceras över ett fullupplöst b& w-lager, och färgrymdstransformationen kommer att ha normal flytpunktsprecision och närmaste helhetsrundning. JPEG2000 adresserar det och har riktiga förlustfria lägen.
-1 Bara gjort ett snabbt experiment med Photoshop CC och öppnar och sparar en bild med exakt samma inställningar upprepade gånger ** resulterar ** i en annan fil varje gång, jämfört med originalet med en "skillnad" blandningsläge. Tydligen är Photoshop inte ett "värt sitt salt". Jag kan inte prata för andra redaktörer men jag slår vad om att pengar är desamma. Du * kunde * skriva ett program mycket noggrant för att undvika avrundningsfel vid kontinuerlig dekomprimering och komprimering av en bild, men det skulle inte vara någon mening - JPEG är inte ett bra mellanformat, punkt.
@MattGrum Jag gjorde precis samma experiment med jaspis. Skillnaden var tom efter den första komprimeringen. Kan inte prata med hur du gjorde ditt experiment, men referensimplementeringen ger inte extra kvalitetsförlust
@SteveCox Jag öppnade en bild i Photoshop, sparade den som en JPEG-kvalitet 7, öppnade den JPEG-filen och sparade den som en JPEG-kvalitet 7 och upprepades sedan 5 gånger. Jag jämförde sedan den första JPEG med den 5: e JPEG. Vad referensimplementeringen gör är endast av akademiskt intresse om de stora redaktörerna alla orsakar en minskning av kvaliteten.
CutNGlass
2014-11-02 13:43:52 UTC
view on stackexchange narkive permalink

Det enkla svaret är "Det beror på." bilden?

Bör vara säker, eftersom en tittare aldrig ska kunna ändra bild.

Jag öppnar bilden i Photoshop Elements Editor och stänger den där?

Bör inte ändra bild.

Om jag helt enkelt stänger och bildar kontra att spara den igen?

Stänger bilden bör inte ändra bilden. Återspara bilden kommer troligen att ändra den, beroende på plug-ins du använder.

En anledning till att du hittar så många olika svar för "när stänger eller sparar du en JPEG orsakar en minskning av bildkvaliteten och när inte? " är att det beror på så många olika saker, inklusive: programvaran du använder för att redigera bilden, plugin-program som är installerade på den programvaran, om din programvara utför "automatiskt sparade" och de inställningar du använder när du sparar jpg-bilden! Det är faktiskt därför jag inte redigerar originalfiler.

Jag använder inte photoshop, men det finns ett plugin-program som är tillgängligt för det som ska hjälpa till med den specifika frågan i fråga - undvika förlust av bildkvalitet när du sparar en jpeg: http://www.betterjpeg.com/jpeg-plug-in.htm

Bättre JPEG Lossless Resave plug-in för Adobe Photoshop och Adobe Photoshop Elements är ett verktyg som är utformat för att undvika komprimeringsförluster när du sparar redigerade JPEG-bilder i Photoshop. Plugin-programmet utnyttjar det faktum att JPEG-bilder består av ett antal små oberoende block och inte komprimerar oförändrade block.

Rafael
2016-09-05 19:33:50 UTC
view on stackexchange narkive permalink

Intressanta uppsättningar svar. Men vissa är fortfarande lite vilseledande. Jag kommer att försöka summera.

Absolut inte

1) Att öppna en fil påverkar inte den på något sätt. Stänger också den. Inte i en tittare eller redigeringsprogram.

Det finns en chans att du ser filen annorlunda i olika program men det kan bero på hur det här programmet tolkar viss information som färgläge eller färgprofil. Men den processen är bara att läsa den.

Det finns en chans för små förändringar

2) Gör löslösa åtgärder, som att rotera en bild. Normalt ordnar programmen bara om data för en jpg-fil utan att analysera och komprimera om. Men jag skulle inte lägga händerna på elden för alla program som föreslår att göra det.

Små onaturliga förändringar

3) Öppna och spara med samma komprimering i samma program.

En första komprimering görs första gången du sparar en jpg-fil. Om du sparar en andra gång filen med samma inställningar är den ursprungliga dataförlusten redan klar, men små ändringar kan tillämpas igen. Inte i samma utsträckning som den första, men kan märkas genom att göra detta flera gånger. Men det beror på programmet.

Märkbara ändringar

4) Det mest uppenbara är att spara igen med en annan komprimeringsinställning.

Inte bara i "skala" för vad programmet än har, utan också algoritmen som används. Detta är lite för tekniskt men det finns minst två huvudkompressionsalgoritmer 4: 4: 4 och 4: 2: 2.

Du kan använda "skjutreglaget" i ditt program för att toppa "kvalitet", men om ditt program använder 4: 2: 2 och originalet var på 4: 4: 4 kommer du att få en betydande dataförlust.

Här är ett litet papper som jag gjorde för några år sedan så att du kan se vad denna dataförlust betyder, det är på spanska men du kan använda google translate: http://otake.com.mx/Apuntes/PruebasDeCompresion2/1-CompresionJpgProceso.htm

En total röra

5) Om du öppnar en bild och sparar den igen i ett program som har begränsad kapacitet. Till exempel kan en viwer bara spara RGB-filer och inte fungera ordentligt med CMYK-filer, eller kanske förstår den inte den inbäddade färgprofilen. Du kan förstöra din bild helt när du sparar.

6) Med mycket komprimering. Du sparar den till din webbplats och komprimerade den. Ta inte bort dina original!

Endast på den redigerade delen av bilden

7) Återkomprimeringen utförs normalt på hela bilden, men som Jag nämnde i punkt 3, det är inte mycket av det om bilden inte har förändrats. När du redigerar en bild måste denna analys göras igen på den redigerade delen.

Kom ihåg att en redigering kan kategoriseras i tre grupper.

a) Färgkorrigeringar, kontrast etc. .

b) Att ändra en del av en bild (röda ögon, ta bort en person, rengöra oönskade fläckar)

c) Ett helt nytt collage.

Så i vissa fall är bilden helt annorlunda, åtminstone för synvinkeln för analys och komprimering.

I det här inlägget: https://photo.stackexchange.com/a/67434/ 37321 användaren nämnde ett program som gör en mycket smart analys av den befintliga komprimeringen och inte komprimerar det igen om det inte är nödvändigt.

Sofiia Shvets
2018-01-22 01:08:05 UTC
view on stackexchange narkive permalink

Ja, det gör det självklart! Jag kommer bara att göra det med exempelbild och JPEG-kvalitet på 30 för att göra den snabbInitial bild. (160 Kb) enter image description here

Första omgången (10 Kb) enter image description here

Andra omgången (9Kb) enter image description here

Så JPEG minskar inte signifikant bildens kvalitet så länge du inte ändrar storlek eller ändrar kvalitetsmått. Bilden fortsätter att sakta försämras, men obetydligt. Och nu tar jag bort bara 4 pixlar från bilden (en kolumn från höger). Och spara igen. enter image description here

Betydande försämring. För att förklara att vi skulle behöva dyka djupt in i JPEG-algoritmen. Hur som helst, om du befinner dig i den här situationen, kom ihåg - det är inte över. Det finns några fantastiska program för JPEG-brusborttagning, till exempel superupplösning och förbättring av neuralt nätverksbild. Jag har laddat upp den sista bilden (den värsta) till den här tjänsten och här är vad jag fick. Riktigt trevligt resultat. enter image description here

Vilken programvara öppnar och stänger du _med_? Är du säker på att din programvara inte sparar (och därför komprimerar) bilden när du stänger den?
Bara grundläggande Photoshop spara
Eftersom frågan ställs om flera olika situationer är det här svaret förvirrande utan att göra det klart.


Denna fråga och svar översattes automatiskt från det engelska språket.Det ursprungliga innehållet finns tillgängligt på stackexchange, vilket vi tackar för cc by-sa 3.0-licensen som det distribueras under.
Loading...