Software-update: Betterjpeg 2.0.0.2

Met het programma Betterjpeg kan je eenvoudige bewerkingen op foto's uitvoeren, zoals croppen, resizen en het verwijderen van het zogenaamde rode-oogeffect. Verder kan het programma de datum en de tijd dat de foto geschoten is, eventueel met commentaar, aan de foto toevoegen. De meeste programma's die jpeg-bestanden bewerken, schrijven het hele bestand opnieuw weg. Hierdoor neemt de kwaliteit van het bestand af; jpeg is immers een 'lossy' formaat. Betterjpeg doet dit echter alleen met die gedeeltes die daadwerkelijk in de foto aangepast zijn, maar niet met de rest van de foto. Hierdoor neemt de kwaliteit van het bestand niet verder af. Versie 2.0.0.2 is sinds kort beschikbaar en voorzien van de volgende lijst met veranderingen sinds de vorige vermelding in de Meuktracker:

Version 2.0.0.2:

• fixed: reconstruction bug.

Version 2.0.0.1:

• added: lossless conversion to grayscale.
• added: lossless brightness/color adjustment.
• added: JPEG noise removal.

Version 1.7.2.1:

• fixed: menu width bug.

Version 1.7.2.0:

• added: CMYK and RGB JPEG support.
• fixed: menu bug when using two monitors.

Version 1.7.1.7:

• fixed: context menu triggered twice.

Versienummer	2.0.0.2
Releasestatus	Final
Besturingssystemen	Windows 9x, Windows NT, Windows 2000, Windows XP, Windows Vista
Website	BetterJPEG
Download	http://www.betterjpeg.com/downloads/bjpg_2_0_0_2.exe
Bestandsgrootte	730,00kB
Licentietype	Shareware

Reacties (9)

[The Flying Dutchman]

Ik weet niet precies hoe de jpeg compressie werkt, maar ik kan me voorstellen dat door alleen dat gedeelte te wijzigen dat aangepast is, er een slechtere compressie bereikt wordt. Extreem voorbeeld: je hebt een foto waarbij 95% van de foto rood is (de buitenste rand), vervolgens ga je croppen zodat de gehele rode rand eraf valt. Aangezien er niet opnieuw compressie wordt toegepast op het overgebleven gedeelte, hoe goed zal de compressie verhouding dan zijn?

Iemand die hier wat duidelijkheid over kan geven?

[Rob Coops]

Ik denk dat je helemaal gelijk hebt, maar je moet niet vergeten dat als je een raw foto als JPEG opslaat dat de compresie best groot is, als je vervolgens het zelfde algotitme over de al gecomprimeerde foto haalt is de compresie minimaal (ook na een crop zo als je beschrijft) maar omdat iedere pixel opnieuw berekend is en dus mogenlijk ook verandered is de kwalitijd gelijk een heel stuk slechter terwijl de compresie winst niet meer dan 0.01% is.

[TD-er]

Jpeg-compressie werkt in blokken van 8x8 pixels.
Het meest eenvoudige is om het eerst in grijstinten te bekijken.
Deze blokjes van 64 pixels worden opgebouwd uit een aantal basis-patronen, waarbij een basis patroon in bepaalde mate meetelt en de som van dat alles is dan vrijwel gelijk aan wat je oorspronkelijke beeld was.
Door afrondingsfouten krijg je altijd een afwijking en naarmate je deze bewerkingen herhaalt (dus decoderen en encoderen) zal de afwijking groter worden.
Dat is dus precies wat dit programma probeert te voorkomen.

Als je de mate van compressie hoger zet, zal je grotere afwijkingen tov het origineel zien.
In de Jpeg-file zullen de getallen, die aangeven hoe zwaar een basis-vorm meetelt, minder nauwkeurig worden opgeslagen, waardoor de afrondfouten dus toenemen.
Bij vlakken zonder veel detail zal dat dus niet snel opvallen, behalve bij de randen.
Niet alle jpeg-compressoren houden echter rekening met een dergelijk wisselend detail, omdat dat ook nogal onnatuurlijk is. Kortom het kan best zijn dat een blokje van 8x8 pixels zonder detail vrijwel evenveel data in de Jpeg-file inneemt als een zeer gedetailleerd blok in diezelfde Jpeg. (indien dat wel veel verschilt zou dat kunnen duiden op manipulatie)
Kortom het is best mogelijk dat wanneer je een rand zonder veel detail weghaalt, dat de compressieverhouding vrijwel gelijk blijft.

[Adion]

Bij jpeg gaf je typisch al een 'quality' waarde op om de sterkte van de compressie te bepalen, en niet zozeer een compressieratio.
Die quality wordt bij jpeg per 8x8 pixels onafhankelijk gebruikt om dat deel te compresseren. (en andere pixels hebben dus geen invloed op de compressie van dat deel)
Als je dus een foto met rode rand met jpeg compresseert op 90% kwaliteit, en daar dan enkel de middelste blokken uitkiest, of eerst de rand er af knipt en dan het gecropte plaatje op 90% kwaliteit compresseert dan zal dit exact dezelfde kwaliteit opleveren.

Bij de jpeg met veel effen rood zal inderdaad een betere compressie behaald worden (dus per pixel gezien minder bytes gebruikt) maar daar veranderd dit programmaatje dus niets aan.

[Cascade]

JPEG (baseline sequential) gebruikt een transformatie (Discrete Cosine Transform) op blokjes (van 8 bij 8 samples, uit m'n hoofd) in de afbeelding. Bij bewerken hoef je dus alleen die blokjes te hertransformeren en -kwantiseren die ook daadwerkelijk aangepast zijn, de rest kan hetzelfde blijven.

De compressie die je hierna overhoudt is afhankelijk van de inhoud van de aangepaste blokjes en of ze met andere instellingen gekwantiseerd worden.

Uitleg over de details van JPEG compressie is hier te vinden: http://www.w3.org/Graphics/JPEG/itu-t81.pdf

[Verwijderd]

Je verhaal is bijna compleet, na kwantiseren zou je nog steeds een 8*8 (formaat is juist wat je zegt) aan coefficienten over hebben. Echter door het toepassen van run-length encoding op deze blokken worden de 0 coefficienten (die na het zigzaggen) aan het einde staan van de reeks coefficienten weg gecomprimeerd.

Verder wordt als laatste stap Huffman codering toegepast waardoor coefficienten die vaak voorkomen met kortere bitlengtes worden opgeslagen.

[Verwijderd]

Ja, maar je run length en Huffman zijn toch lossless? Dus die kan je toch perfect terug toepassen? Daarmee verander je niets aan de kwaliteit he..

[crashmatrix]

De RLE en Huffman coding is slechts een manier om een betere compressie te behalen binnen het formaat, de echte compressie, het lossy gedeelte, is het puzzelen met die 8x8 DCT blokjes, door die transformatie is het niet meer mogelijk de afbeelding 1:1 terug te krijgen tijdens het decoderen.

[Verwijderd]

De compressie van de foto in zijn geheel zal een stuk minder zijn.
Een vlak met slechts 1 kleur is enorm te comprimeren. Door dit weg te halen zal de compressie van de totale foto veel minder worden, maar het overgebleven stuk zal wel dezelfde compressie hebben als het eerst had.