Dit wordt hoogstwaarschijnlijk veroorzaakt door entropiecodering, de laatste fase zonder verlies van JPEG-compressie, nadat de beeldgegevens zijn gekwantiseerd om de grootte te verkleinen.

Wanneer een JPEG-afbeelding wordt verliesloos geroteerd, deze laatste verliesvrije coderingslaag moet ongedaan worden gemaakt, de uitgepakte DCT-coëfficiënten worden door elkaar geschud en vervolgens moeten de geschudde coëfficiënten opnieuw entropie worden gecodeerd. Aangezien de efficiëntie van de entropiecoderingslaag afhangt van de volgorde van de DCT-coëfficiënten binnen elk blok, waardoor het roteren van de afbeelding zal veranderen, zou het niet moeten verbazen dat het geroteerde afbeeldingsbestand een paar procent kleiner of groter kan zijn dan het origineel. / p>

Er zijn ook verschillende manieren waarop de entropiecoderingsstap kan worden uitgevoerd, dus het is heel goed mogelijk dat de bestandsgrootte van exact dezelfde JPEG-afbeelding kan variëren afhankelijk van de software die de codering uitvoert. Enkele van de mogelijke verschillen tussen encoders zijn:

• keuze van rekenkundige codering (zeldzaam maar potentieel efficiënter, vroeger gepatenteerd) versus Huffman-codering (eenvoudiger, standaard);
• keuze van sequentiële (elk 8x8 pixelblok wordt één voor één gecodeerd) versus progressief (lage frequentiecomponenten van alle blokken worden gecodeerd vóór de hogere frequentiecomponenten, meestal iets compacter) coderingsvolgorde;
• keuze voor het gebruik van de standaard Huffman-symbooltabellen (sneller, eenvoudiger, kan efficiënter zijn voor zeer kleine afbeeldingen) vs. aangepaste tabellen die zijn geoptimaliseerd voor elke afbeelding (meestal efficiënter voor grote afbeeldingen, langzamer en complexer om te coderen);
• als aangepaste Huffman-tabellen worden gebruikt, kunnen verschillende encoders mogelijk verschillende tabellen genereren voor dezelfde afbeeldingsgegevens;
• verschillende details op laag niveau van het coderingsproces zelf, zoals of en wanneer herstartmarkeringen moeten worden opgenomen in de datastroom, kan ook variëren tussen encoders.

Bovendien bevatten de "JPEG-bestanden" waarmee mensen normaal gesproken werken, JPEG-gecomprimeerde afbeeldingsgegevens verpakt in een JFIF of een Exif -container, die de afbeeldingsgegevens combineert met een of meer metadatablokken, en introduceert zijn eigen set complicaties. Zelfs als de software die de afbeelding roteert eigenlijk geen substantiële wijzigingen aanbrengt in de JFIF / Exif-metadata, kan het eenvoudigweg herschikken van de gegevens de bestandsgrootte mogelijk met enkele bytes beïnvloeden.

In het bijzonder de JFIF / Exif-metagegevens kunnen een of meer miniaturen van de volledige afbeelding bevatten, en software die afbeeldingen roteert, zou de miniaturen echt moeten regenereren (of ook zonder verlies draaien!) Zodat ze overeenkomen met de nieuwe oriëntatie van de volledige afbeelding. -formaat afbeelding. Dit alleen al zou gemakkelijk het waargenomen verschil in grootte kunnen verklaren.

Ik ging door en herhaalde het experiment om te zien of ik erachter kon komen wat er aan de hand was.

Procedure

Ik heb een willekeurige RGB-afbeelding van 256 bij 256 pixels gegenereerd met de "Solid Noise" -filter in GIMP (Filters> Render> Clouds> Solid Noise ...) met behulp van de standaardinstellingen (hieronder weergegeven):

En het resultaat:

Vervolgens heb ik de afbeelding als JPEG opgeslagen met de standaardinstellingen:

Daarna heb ik de afbeelding naar Windows en opende de afbeelding met Windows Photo Viewer door met de rechtermuisknop op de afbeelding in de Verkenner te klikken en Voorbeeld te kiezen in het menu. Vervolgens heb ik de afbeelding geroteerd met de knoppen onderaan en de afbeelding opgeslagen door met de pijltjestoetsen naar de volgende afbeelding te navigeren.

Voor elk van de onderstaande tests begon ik met een kopie van de originele afbeelding, en het overeenkomstige aantal keren geroteerd (geklikt op de rotatieknop) voordat het werd opgeslagen. Hier zijn de reslting-formaten ( ls -l -r ):

  grootte in bytes datum laatste wijziging VVVVV VVVVV-rwxrwx --- 1 root vboxsf 6258 8 nov 11:24 original.jpg-rwxrwx --- 1 root vboxsf 23645 8 november 11:30 cw.jpg-rwxrwx --- 1 root vboxsf 23636 8 november 11:30 cw-cw.jpg-rwxrwx --- 1 root vboxsf 23649 8 nov 11:30 cw-cw-cw.jpg-rwxrwx --- 1 root vboxsf 6258 8 nov 11:27 cw-cw-cw-cw.jpg-rwxrwx --- 1 root vboxsf 23649 8 nov 11:31 cw-cw-cw-cw-cw.jpg-rwxrwx --- 1 root vboxsf 23649 8 november 11:29 ccw.jpg-rwxrwx --- 1 root vboxsf 23636 8 november 11:29 ccw-ccw.jpg-rwxrwx- - 1 root vboxsf 23645 8 november 11:29 ccw-ccw-ccw.jpg-rwxrwx --- 1 root vboxsf 6258 8 november 11:27 ccw-ccw-ccw-ccw.jpg-rwxrwx --- 1 root vboxsf 23649 8 nov 11:30 ccw-ccw-ccw-ccw-ccw.jpg  

Onmiddellijke waarnemingen

• Windows Photo Viewer (WPV) vergroot de grootte drastisch ; de toename is ongeveer vier keer in deze test!
• Alle nieuwe afbeeldingen worden groter tot ongeveer dezelfde grootte, maar ze zijn niet identiek.
• WPV hercodeert de afbeelding niet en slaat deze zelfs niet opnieuw op wanneer deze wordt gedraaid met een veelvoud van 360 graden. (Het tijdstempel, 11:27, is wanneer de bestanden voor het eerst werden gekopieerd.)

Door cmp -l te gebruiken op bestanden die identieke inhoud zouden moeten hebben, kunnen we zien waar de bestanden verschillen.

  robert @ unit ../jpeg-rotate-test% cmp -l cw.jpg ccw-ccw-ccw.jpg 2223 63 62 2224 60 71 2226 60 64 2227 60 66robert @ eenheid ../jpeg-rotate-test% cmp -l cw-cw.jpg ccw-ccw.jpg 2223 63 62 2224 60 71 2226 60 64 2227 62 64robert @ eenheid ..jpeg-rotate-test% cmp - l ccw.jpg cw-cw-cw.jpg 2223 62 63 2224 71 60 2226 64 60 2227 61 64 robert @ unit ../jpeg-rotate-test% cmp -l cw.jpg cw-cw-cw-cw-cw. jpg 2221 60 61 2223 63 61 2224 60 66 2226 60 61 2227 60 61 robert @ eenheid ../jpeg-rotate-test% cmp -l ccw.jpg ccw-ccw-ccw-ccw-ccw.jpg 2223 62 63 2224 71 60 2226 64 65 2227 61 64  

Deze bestanden verschillen in slechts vier bytes (eigenlijk in een tijdstempel), wat betekent dat WPV elke keer hetzelfde doet; nu hoeven we alleen maar uit te zoeken wat dat is.

Gedetailleerde observaties

Hiervoor heb ik JPEGsnoop gebruikt om te zien wat er precies in de afbeeldingen stond.

Aangezien de outputs vrij lang zijn, heb ik er in eerste instantie aan gelinkt. Hier is een samenvatting van de verschillen:

• GIMP gebruikt alleen een APP0 (JFIF) en COM (commentaar) -segment voor metadata . WPV laat het APP0 -segment onaangeroerd, maar voegt merkwaardig genoeg een null-byte toe aan de opmerking (zodat deze wordt beëindigd met null).

• WPV voegt er twee toe APP1 -segmenten, dit zijn Exif- en XMP-metadata. Deze segmenten zijn respectievelijk 4286 en 12726 bytes. Samen zijn ze verantwoordelijk voor bijna de gehele toename in bestandsgrootte.

• GIMP produceert een progressieve JPEG, terwijl WPV een basislijn (niet-progressieve) JPEG produceert. Om deze reden heeft de afbeelding van GIMP meerdere scansegmenten, terwijl de WPV-afbeelding er maar één heeft. In mijn ervaring is het progressieve beeld soms iets kleiner.

• GIMP gebruikte 1 × 1 chroma subsampling, terwijl WPV 2 × 2 subsampling gebruikte. Dit doet me geloven dat WPV geen "echte" verliesloze rotatie gebruikt, tenzij het op de een of andere manier kan detecteren dat dit een zwart-witafbeelding is.

Oplossen deze problemen heb ik een tweede test uitgevoerd.

Procedure

Ik volgde dezelfde stappen als bij de eerste test. Ik heb een willekeurige 256 × 256 RGB-afbeelding gemaakt met behulp van het RGB-ruisfilter (Filters> Neus> RGB-neus ...) met de volgende instellingen:

Hier is de resultaat:

Ik heb het bestand geëxporteerd als JPEG met de volgende instellingen:

Progressive is uitgeschakeld, maar Subsampling is nog steeds ingesteld op 4: 4: 4 (wat een andere naam is voor 1 × 1 subsampling). De kwaliteit is verhoogd naar 98.

Ik heb de afbeelding gekopieerd en de kopie met de klok mee gedraaid; vervolgens de geroteerde versie gekopieerd en die kopie tegen de klok in gedraaid, zodat we de kwaliteit rechtstreeks kunnen vergelijken tussen het origineel en de door WPV verwerkte kopie.

Resultaten

  -rwxrwx-- - 1 root vboxsf 159774 8 november 16:21 original-random.jpg-rwxrwx --- 1 root vboxsf 222404 8 november 16:24 cw-random.jpg-rwxrwx --- 1 root vboxsf 222467 8 november 16:24 cw- ccw-random.jpg  

Hoewel de toename deze tijd relatief kleiner is (ongeveer 40%), is de absolute toename zelfs nog groter - ongeveer 62 kB. Dit suggereert dat WMV een minder efficiënte codering gebruikt.

Ik gebruik ImageMagick om de twee afbeeldingen te vergelijken:

  robert @ unit. ./jpeg-rotate-test% vergelijk -verbose -metric AE original-random.jpg cw-ccw-random.jpg null: original-random.jpg JPEG 256x256 256x256 + 0 + 0 8-bit sRGB 160KB 0.000u 0: 00.009
cw-ccw-random.jpg JPEG 256x256 256x256 + 0 + 0 8-bit sRGB 222KB 0.010u 0: 00.010 Afbeelding: origineel-willekeurig.jpg Kanaalvervorming: AE rood: 0 groen: 0 blauw: 0 alle: 0 origineel-willekeurig. jpg = > JPEG 256x256 256x256 + 0 + 0 8-bit sRGB 0.050u 0: 00.020  

Er zijn nul pixels verschillend tussen de originele en de geroteerde kopie. Dus zelfs als WPV geen gebruik maakt van "echte" verliesloze rotatie, doet het zijn werk goed genoeg. Ik vermoed dat ik weet wat er aan de hand is, en om het uit te leggen, ga ik een beetje in op de wiskunde achter JPEG-compressie.

Het JPEG-compressie-algoritme splitst een afbeelding op in blokken van 8 × 8 pixel. Elk van deze blokken wordt vervolgens onderworpen aan een Discrete Cosine Transform (DCT). De resulterende DCT-coëfficiënten beschrijven het blok als een som van golven met verschillende frequentie. Het algoritme "gooit" wat informatie weg in de hoogfrequente golven die corresponderen met ruis en zeer kleine details. Het decoderingsproces keert de DCT om, waarbij de opgeslagen golven bij elkaar worden opgeteld om het blok terug te krijgen.

Het is mogelijk om de DCT "golven" te roteren zonder de transformatie daadwerkelijk ongedaan te maken en opnieuw uit te voeren (in feite draai je alle horizontale golven in verticale golven en vice versa). Wat ik denk dat er in WPV gebeurt, is dat de afbeelding daadwerkelijk wordt gedecodeerd, geroteerd en vervolgens opnieuw wordt gecodeerd. Omdat tijdens het hercoderingsproces de grootte van onze afbeelding een veelvoud is van 8 in beide dimensies, komt elk van de nieuwe blokken overeen met een van de originele blokken. Belangrijk is dat aangezien elk blok geen hoogfrequente componenten heeft, het algoritme geen informatie weggooit en precies de juiste DCT-componenten vindt die een "echte" verliesloze rotatie zou hebben.

Ten slotte, ik ' Ik kijk nogmaals naar de componenten van de JPEG-bestanden. De resultaten zijn weer gelinkt als gists. Vergelijking van de twee:

• De WPV-afbeelding bevat 4286 + 2 bytes Exif-metadata extra, 1 extra byte in de opmerking en 12,726 + 2 bytes XMP-metadata. Dit is in totaal 17.017 bytes aan extra metadata. Waar worden al die gegevens voor gebruikt? Ik gluurde in het bestand met mijn vertrouwde hex-editor en een kopie van de relevante standaarden:

  • Exif-metagegevens zijn gestructureerd als een TIFF-afbeelding, die een aantal tags bevat (er is manier meer complexiteit, maar ik zal het meteen overslaan). De meeste bytes in het Exif-segment bevinden zich in twee identieke tags met tagnummer EA1C (59.932 decimaal). Dat tagnummer is nergens gedocumenteerd dat ik kon vinden. Beide tags bevatten 2060 bytes van het type "ongedefinieerd", die allemaal nul bytes zijn, behalve de eerste zes ( 1C EA 00 00 00 08 ). Ik heb geen idee wat deze tags zijn, waarom er twee zijn en waarom ze elk 2 kB moeten zijn.

  • De XMP-metadata is eigenlijk een volledig ingesloten XML-document met naamruimte en lange UUID's, die alleen de WPV-versiestring bevat (die al in de Exif-metadata stond). Dat is echter slechts goed voor ongeveer 400 bytes. De rest van het segment is 122 herhalingen van 100 spaties gevolgd door een nieuwe regel . Dat is meer dan 12.000 bytes aan totaal verspilde ruimte.

• Net als de vorige test gebruiken zowel GIMP als WPV dezelfde DCT-kwantisatietabellen. Dit betekent dat ze exact dezelfde DCT-coëfficiënten moeten berekenen, en daarom zijn de afbeeldingen precies hetzelfde. Ik weet niet zeker of WPV toevallig dezelfde kwantisatietabellen gebruikt of dat het de tabellen van de invoer kopieert.

• In tegenstelling tot de vorige test gebruikt WPV dit keer 1 × 1 subsampling, dus het kan in feite detecteren dat dit een kleurenafbeelding is (of in ieder geval dat hogere samples nodig zijn om de afbeelding zonder verlies opnieuw te coderen).

• GIMP en WPV gebruiken verschillende Huffman-tabellen (onderdeel van de entropiecodeerstap). De tabellen voor WPV zijn groter met in totaal 279 bytes en bevatten in één geval 7 keer zoveel codes.

  Als we naar de statistieken van JPEGsnoop kijken, kunnen we zien dat sommige van deze codes zelden worden gebruikt. In de ID: 1, Class: AC -tabel, van de 119 gedefinieerde 16-bits codes, worden er bijvoorbeeld slechts 23 daadwerkelijk gebruikt. Over het algemeen is het daadwerkelijke scansegment 28,5% groter in de WPV-versie.

Samenvatting

• WPV doet het misschien niet " echte "verliesloze rotaties, maar de rotaties lijken praktisch verliesloos te zijn.

• De extra grootte is gedeeltelijk te wijten aan een vaste hoeveelheid toegevoegde metadata, en gedeeltelijk aan minder efficiënte entropiecodering .

Versie-informatie:

• OS (Linux) ( uname -a ):

    Linux-eenheid 3.16.0-4-amd64 # 1 SMP Debian 3.16.36-1 + deb8u1 (2016-09-03) x86_64 GNU / Linux  

• OS (Windows):

  

• GIMP (Linux): 2.8.14 (uit pakket gimp , versie 2.8.14-1 + deb8u1 )

  

• Window Photo Viewer (volgens metadata van afbeeldingen):

    Microsoft Windows Photo Viewer 10.0.10586.0  

^{BEWERKEN : dit antwoord werd gepost voordat ik wist dat de bestanden met ongeveer 9 KiB in omvang waren toegenomen (9055 bytes voor de 256 × 256 afbeelding, 9612 KiB voor de 512 × 512 afbeelding).}

Naar alle waarschijnlijkheid heeft Windows Picture Viewer bij het draaien van de afbeelding een (of beide) van de volgende dingen gedaan:

1. Toegevoegd een EXIF-tag die niet in de originele JPEG-afbeelding stond (misschien de Orientation-tag);
2. Informatie gewijzigd / toegevoegd aan een tag die al bestond (misschien tags voor verwerkingssoftware of afbeeldingssoftware).

Dit verhoogde de bestandsgrootte vanwege de extra EXIF-tag (en / of aanvullende gegevens naast bestaande tags).

Latere rotaties hebben de bestandsgrootte niet vergroot omdat alle tags en / of taggegevens die WPV zou hebben toegevoegd / gewijzigd, waren er al. Alleen de Orientation Tag waarde is gewijzigd (en misschien ook de datum / tijd tag-waarden).

---

EDIT : het is vrijwel zeker dat dit uitleg kan geen rekening houden met ongeveer 9 KiB aan extra gegevens in het bestand. Verder, bij afwezigheid van andere redenen voor de toename van de grootte, zou deze verklaring verwachten dat de toename in grootte min of meer constant zou zijn (modulo enkele lengteverschillen tussen stringrepresentaties van numerieke gegevens, waarschijnlijk een paar bytes) . Dat is duidelijk niet wat hier gebeurt, althans niet de volledige uitleg.

Zonder reverse engineering van de jpeg en / decoder is het onmogelijk met zekerheid te zeggen. Er zijn eigenlijk een aantal jpeg-standaarden en in tegenstelling tot wat vaak wordt gedacht, kunnen ze niet allemaal worden gewijzigd zonder opnieuw te coderen.

Het is mogelijk dat de eerste save een lossy herschrijving is in zijn favoriete jpeg-smaak en de daaropvolgende rotaties zijn een eenvoudige metadata-tweak of een bewerking rechtstreeks op de DCT-tabel (wat mogelijk is voor sommige coderingsschema's).

De toename in bestandsgrootte kan ook wat extra metadata bevatten, hoewel 9k veel lijkt, is het mogelijk. De toename kan ook worden verklaard door de toevoeging van een miniatuur die mogelijk niet aanwezig was in de uitvoer van GIMP. Mogelijk kunnen we meer informatie rechtstreeks uit de bestanden halen (vóór WPV en erna).

In elk geval is het proberen om zonder problemen met jpeg te werken echt een dwaze boodschap, aangezien het alleen nuttig is bij bepaalde afbeeldingsformaten, niet alle decoders en encoders zijn identiek en het vereist dat die editors rechtstreeks met de jpeg-inhoud werken, waarvan u niet kunt vertrouwen dat dit het geval is ... Alleen omdat dit nu het geval is, betekent niet dat dit in de toekomst zal blijven.

Je kunt beter met een verliesvrij formaat werken en de pijn volledig vermijden.

JPEG-rotatie zonder verlies is alleen mogelijk zonder de introductie van grensartefacten als de afbeeldingsafmetingen veelvouden zijn van de blokgrootte (meestal [/ altijd?] 8). Zie de jpegtran-manpagina (sorry, ik heb er geen goede canonieke link voor; voel je vrij om te bewerken als je er een vindt) voor details over wat erbij komt kijken:

De transpositie-transformatie kent geen beperkingen wat betreft afbeelding
afmetingen. De andere transformaties werken nogal vreemd als de afbeeldingsafmetingen geen veelvoud zijn van de iMCU-grootte (gewoonlijk 8 of 16 pixels), omdat ze alleen volledige blokken DCT-coëfficiëntgegevens op de gewenste manier kunnen transformeren.

Het standaardgedrag van jpegtran bij het transformeren van een afbeelding met een vreemde grootte
is ontworpen om de exacte omkeerbaarheid en wiskundige consistentie van de transformatieset te behouden. Zoals gezegd, kan transponeren
het hele beeldgebied omdraaien. Bij horizontaal spiegelen blijft elke gedeeltelijke iMCU-kolom aan de rechterkant onaangeroerd, maar kunnen alle rijen van de afbeelding worden omgedraaid. Evenzo laat verticale spiegeling elke gedeeltelijke iMCU-rij aan de onderkant onaangeroerd, maar kan alle kolommen worden omgedraaid. De andere transformaties kunnen worden opgebouwd als reeksen van transponeer- en flipbewerkingen; voor consistentie zijn hun acties op randpixels gedefinieerd als hetzelfde als het eindresultaat van de corresponderende transpose-and-flip-reeks.

Voor praktisch gebruik kun je er de voorkeur aan geven om elke niet-transformeerbare
edge weg te gooien pixels in plaats van een vreemd uitziende strook langs de
rechter- en / of onderkant van een getransformeerde afbeelding. Om dit te doen, voegt u de -trim-schakelaar toe:

Ik vermoed dat de Windows Photo Viewer dit probleem vermijdt door decompressie en extreem hoogwaardige hercompressie uit te voeren om verliesloos gedrag te simuleren wanneer de afbeeldingsdimensies geen veelvouden van 8 zijn, in plaats van daadwerkelijk verliesloos roteren uit te voeren. Een goed hulpprogramma zou gewoon echt verliesvrij maken, artefacten en alles, of een paar pixels laten vallen, in plaats van de kwaliteit van de hele afbeelding te verpesten (en de bestandsgrootte te vergroten).

Ik heb geen definitief antwoord, maar enkele mogelijke theorieën over waarom dat is gebeurd. Sommige bestandstypen werken op zo'n manier dat twee verschillende codes voor een afbeelding van dat bestandstype niet noodzakelijkerwijs verschillende afbeeldingen produceren. Het PNG-bestandstype werkt bijvoorbeeld op die manier omdat het een transparante achtergrond mogelijk maakt, maar een afbeelding met een transparante achtergrond en een afbeelding die hetzelfde is, behalve dat dezelfde achtergrond wit is, ziet er precies hetzelfde uit. Een afbeeldingsbestand is gecomprimeerd als het minder dan 3 bytes geheugen per pixel in beslag neemt. Ik denk dat behalve degene met een transparante achtergrond, geen twee PNG-bestanden exact dezelfde afbeelding genereren. Elke keer dat u een afbeelding opslaat als PNG, wordt deze omgezet in een code die de originele afbeelding genereert en behalve voor zeer ongebruikelijke afbeeldingen zoals een waarbij elke pixel een willekeurige kleur is van alle 2 ^ 24 kleuren, neemt de code minder geheugen in beslag dan 3 bytes per pixel, dus opslaan als PNG is compressie zonder verlies. Aan de andere kant kunnen alleen bepaalde afbeeldingen worden gegenereerd door de code van een JPEG-afbeeldingsbestand om geheugen te besparen. Er is waarschijnlijk meer dan één JPEG-bestandstype en ik weet niet of een ervan de eigenschap heeft dat twee verschillende afbeeldingen van dat bestandstype exact dezelfde afbeelding kunnen genereren. Ik neem aan dat je een aantal keren zojuist een afbeelding hebt geroteerd en deze vervolgens als JPEG hebt opgeslagen en ik zal een uitleg geven van wat er is gebeurd in de veronderstelling dat je dat deed en waarvan ik niet weet of het waar is. Een rotatie die u hebt gemaakt, is verliesloos als er een manier is om exact dezelfde afbeeldingsbestandscode terug te krijgen als voordat u deze roteerde en opsloeg. Je hebt misschien niet gelijk dat je echt een verliesloze rotatie hebt gedaan. Als het echt verliesvrij was, is een mogelijke reden dat twee verschillende afbeeldingscodes echt exact dezelfde afbeelding genereren en het was de code van de afbeelding die je had en niet de afbeelding die je had die de afbeelding bepaalde die je kreeg nadat je hem had geroteerd en vervolgens hebt opgeslagen het.

De redenen hiervoor zijn een paar

de manier waarop afbeeldingen worden gecodeerd en gecomprimeerd, verandert de grootte simpelweg vanwege het compressie-algoritme. u kunt dit testen door het op te slaan als een bitmap en vervolgens te roteren. In dat formaat of een ander onbewerkt formaat moet de grootte hetzelfde blijven. Als dit niet het geval is, voegt het programma dat de afbeelding opslaat nieuwe gegevens toe, mogelijk wat metadata of zoiets.

Maar waarom roteer je een jpeg 20 keer?

Vanwege hoe compressie van afbeeldingen werkt . Elk formaat zoals PNG of JPG behoudt over het algemeen de bestandsgrootte niet na rotatie.

Voor de compressor is de geroteerde afbeelding gewoon een andere afbeelding, vanwege de manier waarop compressie-heuristiek werkt er is geen garantie dat het zal comprimeren een geroteerde afbeelding hetzelfde .

Natuurlijk, als de compressie verliesloos is, als je de afbeelding 4 keer roteert voor de 4e keer, is de afbeelding weer hetzelfde (geroteerd totdat het wordt gekanteld als origineel) : in dat geval zou het weer dezelfde gecomprimeerde grootte moeten krijgen, zo niet dan is dat vanwege een van de volgende redenen :

• Toegevoegde metadata : het programma heeft om de een of andere reden wat tekst toegevoegd
• Compressor gewijzigd: het programma kan ervoor kiezen om de afbeelding gewoon opnieuw op te slaan als het origineel als er geen wijzigingen zijn, maar als je een wijziging aanbrengt ( zelfs 4 rotaties van 90 graden), kan besluiten om de afbeelding opnieuw te comprimeren met zijn eigen compressor (het programma weet niet langer dat het nog steeds dezelfde afbeelding is).
• In het algemeen levert dezelfde compressor (libPNG of libJPG) zeer verschillende resultaten op over verschillende implementaties, verschillende versies van dezelfde bibliotheek en met verschillende compressieparameters (ook het besturingssysteem en de compiler maken hier soms een verschil).

Beeldcompressie werkt door afbeeldingen te comprimeren in stukken van 4x4 of andere formaten. Over het algemeen ziet een compressor een geroteerd beeld als een ander beeld, maar aangezien een gecomprimeerd pixelblok slechts een lineaire decompositie is, is het mogelijk om, als de brokken op het beeld hetzelfde zijn, de lineaire decompositiematrices effectief hetzelfde te transponeren / spiegelen. kwaliteit:

Merk op dat dit moet worden geïmplementeerd per functie , en dat verklaart ook de initiële toename in grootte => bij de eerste rotatie probeert het gewoon de afbeelding te comprimeren in brokken die roteerbaar zijn:

• Als dit niet lukt: de beeldkwaliteit verslechtert

• Als het lukt, vergroot het de grootte slechts één keer, dan behoudt elke rotatie dezelfde kwaliteit.

• Die bewerking is alleen succesvol als de afbeelding is gemaakt door gelijke delen . (grootte van de afbeelding is een veelvoud van de grootte van de brok).

Het antwoord van scottbb is verkeerd en je kunt een eenvoudige test doen:

• Open de originele afbeelding: maak een screenshot
• Draai de afbeelding 4 keer met WPV: maak een screenshot
• Vergelijk de 2 screenshots

U zult het beeld zien veranderen (het wordt opnieuw gecomprimeerd bij de eerste rotatie). Die verandering is echter beperkt in de tijd, je kunt hem nu weer draaien zonder kwaliteitsverlies (als de afbeelding een grootte heeft die een veelvoud is van 8)

Om OP direct te beantwoorden:

Ik weet dat het verliesloos roteert

Het roteert niet zonder verlies, het verliest minstens één keer aan kwaliteit (bij de eerste rotatie: omdat het het eerst zou moeten comprimeren op een manier die kan worden gedraaid), dan behoudt het zijn kwaliteit.