Diskussion:JPEG/Archiv
Verlinkung auf Kinderpornographie?
Der Link http://www.spemaus.de/studium/visjpeg/applet.html führt laut Bundeskriminalamt zu einer Seite, die mit Kinderpornographie in Verbindung gebracht wird (großes rotes Stoppschild).
Sollte jemand wissen, ob diese Seite ungerechtfertigt gesperrt wird, ist das BKA zu informieren. (kontakt@bka.de)
Bis Klarheit besteht, entferne ich den Link aus den Weblinks. -- 77.11.129.201 14:29, 1. Mai 2009 (CEST)
- Nanu. Ist die Filterung denn schon aktiv? Auf der Website des bka steht nichts darüber. --Berthold Werner 17:15, 1. Mai 2009 (CEST)
- Das angezeigte Bild entspricht auch nicht dem in c't 10 auf Seite 52 gezeigten. --Berthold Werner 13:13, 4. Mai 2009 (CEST)
Spart JPG außer Platz auf Datenträger auch Platz im RAM?
Einige Software, z. B. ThumbsPlus, meldet beim Laden einer JPG Datei einen RAM-Bedarf (Grösse der Datei im aktuellen Arbeitsspeicher), der genau so groß ist wie etwa bei einer geladenen TIF Datei. Verringert also eine JPG Codierung die Dateigröße nur auf Datenträger (gegenüber einer Nicht-Codierung) oder auch im RAM? Wie ist das Verhältnis dieser Dateigrößen-Veringerung zwischen Datenträger und RAM? Grüsse Ulrich Roos
- Die meisten, wenn nicht alle, Programme dekomprimieren die JPG-Datei vollständig beim Laden, denn nur mit den dekomprimierten Daten können sie etwas anfangen. Daher die größere Belegung im RAM. Bei einem Farbbild ist mit (3*Höhe*Breite) Byte auszugehen. --Phrood 19:02, 31. Jul 2006 (CEST)
Quantisierung
Kann jemand die Blöcke mal kontrollieren? Mir ist das nicht ganz klar... Da stand viel Müll zwichen den Zeichen. Ggf. ist da noch mehr im Eimer.
- Wenn es stimmt was darueber steht, dass das Ergebnis von F(x,y)/Q(x,y) abgerundet wird, dann stimmt die fertige Tabelle (F^Q) nicht ganz. Dort wurde immer normal gerundet. Koennte ja mal jemand korrigieren. 141.3.164.13 11:23, 25. Jul. 2008 (CEST)
C-Quellcodes zur Analyse von JPEG-Dateien
(Mich würde brennend interessieren, was dieser Quellcode in einem Enzyklopädie-Artikel zu suchen hat(te) -- akl 14:04, 26. Mär 2004 (CET))
void main(argc, argv)
int argc;
char *argv[];
{
FILE *datei;
int i, j, j2, breite, hoehe, teiler, si1, si2, sl1, sl2, icount;
int d, m;
long sig, slg;
char feld[256];
datei = fopen(argv[1],"r");
printf("\n\n");
icount = 0;
for(i=0;i<17;i=0)
{
si1 = fgetc(datei);
if (si1 == 255)
{
si2 = fgetc(datei);
sig = 256*si1+si2;
if (si2 == 216)
{
printf("Segment: SOI (Start Of Image)\n");
icount++;
}
if (si2 == 224)
{
printf("Segment: APP0\n");
sl1 = fgetc(datei);
sl2 = fgetc(datei);
slg = 256*sl1 + sl2;
if(slg <= 255)
{
for(j=0;j<(slg-2);j++)
{
feld[j] = fgetc(datei);
}
printf("Segmentl„nge : %d\n",slg);
printf("ID : %c%c%c%c%c\n",feld[0],feld[1],feld[2],feld[3],feld[4]);
printf("Version : %d.%d\n",feld[5],feld[6]);
}
if(slg >= 256)
{
for(j=0;j<6;j++)
{
feld[j] = fgetc(datei);
}
printf("Segmentl„nge : %d\n",8);
printf("ID : %c%c%c%c%c\n",feld[0],feld[1],feld[2],feld[3],feld[4]);
}
}
if (si2 == 238 || si2 == 254)
{
printf("Segment: Copyright\n");
sl1 = fgetc(datei);
sl2 = fgetc(datei);
slg = 256*sl1 + sl2;
for(j=0;j<(slg-2);j++)
{
feld[j] = fgetc(datei);
}
printf("Segmentl„nge : %d\n",slg);
printf("ID : ");
for(j=0;j<(slg-3);j++)
{
printf("%c",feld[j]);
}
printf("\n");
}
if (si2 == 219)
{
printf("Segment: DQT (Define Quantisation Table)\n");
sl1 = fgetc(datei);
sl2 = fgetc(datei);
slg = 256*sl1 + sl2;
if (slg == 67) slg = 66;
printf("Segmentl„nge : %d\n",slg);
d = slg / 16;
m = slg % 16;
printf(" ");
for(j=0;j<d;j++)
{
for (j2=0; j2<16; j2++)
{
feld[j2] = fgetc(datei);
printf(" %02x ",feld[j2]);
}
printf("\n ");
}
for(j=0;j<(m-2);j++)
{
feld[j] = fgetc(datei);
printf(" %02x ",feld[j]);
}
printf("\n");
}
if (si2 == 192 || si2 == 193)
{
printf("Segment: \n");
sl1 = fgetc(datei);
sl2 = fgetc(datei);
slg = 256*sl1+sl2;
for(j=0;j<(slg-2);j++)
{
feld[j] = fgetc(datei);
}
printf("Segmentl„nge : %d\n",slg);
printf("Data Precision: %d\n",feld[0]);
printf("Bildbreite : %d\n",256*feld[3]+feld[4]);
printf("Bildh”he : %d\n",256*feld[1]+feld[2]);
}
if (si2 == 196)
{
printf("Segment: DHT (Define Huffman Table)\n");
sl1 = fgetc(datei);
sl2 = fgetc(datei);
slg = 256*sl1+sl2;
printf("Segmentl„nge : %d\n",slg);
d = slg / 16;
m = slg % 16;
printf(" ");
for(j=0;j<d;j++)
{
for(j2=0;j2<16;j2++)
{
feld[j2] = fgetc(datei);
printf(" %02x ",feld[j2]);
}
printf("\n ");
}
for(j=0;j<(m-2);j++)
{
feld[j] = fgetc(datei);
printf(" %02x ",feld[j]);
}
printf("\n");
}
if (si2 == 237)
{
printf("Segment: ???\n");
sl1 = fgetc(datei);
sl2 = fgetc(datei);
slg = 256*sl1+sl2;
printf("Segmentl„nge : %d\n",slg);
d = slg / 16;
m = slg % 16;
printf(" ");
for(j=0;j<d;j++)
{
for(j2=0;j2<16;j2++)
{
feld[j2] = fgetc(datei);
printf(" %02x ",feld[j2]);
}
printf("\n ");
}
for(j=0;j<(m-2);j++)
{
feld[j] = fgetc(datei);
printf(" %02x ",feld[j]);
}
printf("\n");
}
if (si2 == 217)
{
printf("Segment: EOI (End Of Image)\n");
icount--;
if (icount == 0)
{
fclose(datei);
exit();
}
}
}
}
fclose(datei);
}
- Ein Angebot! Ich habe mich vor mehreren Jahren mal mit Bildformaten beschäftigt, und mich unter anderem dafür interessiert, was für Informationen ich aus den JPEG-Dateien herausbekommen kann. Dabei sind diese Programme entstanden. Sie sind auschlieslich nützlich, um JPEG-Dateien zu analysieren, und den Aufbau dieser Dateien etwas besser zu verstehen. Die Listings enthalten keinen Entpacker oder Decoder, da ich dafür die Kenntnisse nicht habe. Aber man kann darauf aufbauen. --Arbol01 14:27, 26. Mär 2004 (CET)
- Soweit so gut, aber hier finde ich das reichlich deplaziert. Schließlich ist die Wikipedia eine Enzyklopädie; für Quellcodes gibt es genügend und besser geeignete Sammelstellen im Netz. Viel hilfreicher fände ich einen Absatz darüber, welche Informationen man in einer JPEG-Datei so alles finden kann. -- akl 14:38, 26. Mär 2004 (CET)
- Ich bin dabei, aber eine Person sieht nicht alles. Wie wäre es, wenn ich ein paar analysierte JPEG-Dateien reinstelle, und sei es nur in der Diskussion??? --Arbol01 14:42, 26. Mär 2004 (CET)
Das ausgefeilste Listing lasse ich hier mal stehen! --Arbol01 14:44, 26. Mär 2004 (CET)
Aus dem Artikel hierher kopiert:
--- Kleiner Nachtrag:
Hallo Leute, ich hatte vor einiger Zeit zum Thema einen netten Nachrichtenartikel auf meiner Seite verfasst. Hier der Text, vielleicht könnt Ihr ja was damit anfangen ggf. ein Nachtrag?
Schlagzeile: Forgent holt zum Rundumschlag aus Katgorie: Software - Patente Datum: 26.04.2004 - 19:22 Inhalt: Der Software-Hersteller Forgent Networks aus Austin (USA, Texas) hat eine Patentklage gegen 31 große IT-Unternehmen eingereicht, genauer gesagt geht es um Lizenzgebühren der JPEG-Nutzung. Das Format JPEG wurde bereits 1985 als Patent bei dem Tochter-Unternehmen "Compression Labs" angemeldet. Forgent fordert daher unter Anderem von Adobe, Agfa, Apple, Canon, Dell, Hewlett Packard, IBM, JVC, Kodak, Macromedia und Xerox Lizenzgebühren für das Bildkompressionsformat. Die Unternehmen, haben Forgent nach - JPEG bisher in Ihrer kommerziellen Software verwendet, aber nicht dafür bezahlt. Die Unternehmen weigern sich zu zahlen - Hintergrund der Weigerung ist ein Streit zwischen Forgent Networks und dem JPEG-Gremium, dass die Rechte an dem Bildkompressions-Standard verwaltet. Laut dem offiziellen JPEG-Gremium, war Compression Labs zwar Anfangs maßgeblich an der Entwicklung des Formates beteiligt, die Algorithmen zur Berechnung von Farbwerten in Bilddateien seien jedoch nicht im Patent angemeldet. Die erwähnten Firmen haben sich einfach gemeinsam verbündet um den Kosten zu entgehen, man kann schließlich das Geld für andere Sachen ausgeben wie Industrie-Spionage für das nächste "Opfer", dass man dann gemeinsam ausbeutet. Egal wenn sich dieses 19. Jahre später meldet und seine Rechte einklagt - Geld für gute Rechtsanwälte ist schließlich genug da - traurig.
Mehr Nachrichtenartikel und vor allem Reports gibt es auf meiner Seite selbst - http://www.ttecx.com - wobei ich die Rechte an diesem Nachrichtenartikel an die Wikipedia weitergebe, wie und ob Ihr das implementiert - überlasse ich Euch :-)
Gruß
Tobias Topyla, sollte etwas sein, so kann ich über E-Mail erreicht werden (tobias@ttecx.com).
(Artikelversion: http://de.wikipedia.org/w/wiki.phtml?title=Joint_Photographic_Experts_Group&curid=2568&diff=0&oldid=0)
--Vulture 09:47, 8. Mai 2004 (CEST) Als Neueinsteiger in die Programmierung von Bildbearbeitung hat mit der C Code, nach dem Lesen der Theorie schon weitergeholfen - Vielen Dank dass Ihr ihn nicht ganz gelöscht habt.
JPEG-Patent
Kann jemand das JPEG-Patent im Artikel erklären? Ich war über http://www.heise.de/newsticker/meldung/49624 gestolpert, dachte immer JPEG wäre frei? Verwirrt: 128.176.114.42 12:36, 31. Jul 2004 (CEST)
- Zur Patenten steht hier etwas auf der Offiziellen JPEG-Homepage--Uwe W. 12:55, 19. Jan. 2008 (CET)
- Diese Webseite erklärt leider überhaupt nichts. --Phrood 14:06, 19. Jan. 2008 (CET)
Artikel aufsplitten?
Derzeit enthält der Artikel viele Informationen, ist aber für Laien schlicht unverständlich. Spricht was dagegen, den Artikel zu splitten in
- jpeg - allgemeinverständliche erklärung ()Bildformat, was es tut, geschichte, patent usw)
- jpeg - Joint Photographic Experts Group (teilnehmer, geschichte usw)
- jpeg - Komprimierungsalgorithmus, JFIF und Co
?? Thomas Springer 11:34, 4. Okt 2004 (CEST)
- Gute Idee! Solange die Detailinfos nicht verloren gehen (wie oben jemand schreibt, kostet es immer sehr viel Zeit, bis man sie aus dem Web zusammen gesucht hat). Anton 13:48, 26. Mär 2005 (CET)
- Bin auch dafür. Außerdem denke ich, dass der erstgenannte Artikel den Namen JPEG (Dateiformat) oder einfach nur JPEG tragen sollte, und im Text kann man dann ethymologisch werden (vgl. englische Wikipedia). Der voll ausgeschriebene Titel ist einfach nur verwirrend - insbesondere für Laien. --Pumbaa80 18:31, 10. Apr 2006 (CEST)
- Bitte nicht aufsplitten, oder wenn, dann nur in JFIF und JPEG. Das Thema ist z.Z. grauenhaft beschrieben, das wird aber wohl nur durch eine vollständige Neufassung möglich sein. Eine Aufsplittung ist unnötig und wird den Artikel nicht verbessern. --Phrood 18:45, 10. Apr 2006 (CEST)
- Aber umbenennen würde ich den Artikel schon. Es macht doch keinen Sinn, in einem Artikel, der vermeintlich eine Expertengruppe zum Thema hat, fast ausschließlich über das danach benannte Grafikformat zu schreiben, oder? --Pumbaa80 12:46, 12. Apr 2006 (CEST)
- JPEG bezeichnet nicht nur die Expertengruppe, sondern auch das Komprimierungsverfahren. Im Moment beschreibt der Artikel allerdings auch das Dateiformat, JFIF. --Phrood 17:11, 12. Apr 2006 (CEST)
- Aber umbenennen würde ich den Artikel schon. Es macht doch keinen Sinn, in einem Artikel, der vermeintlich eine Expertengruppe zum Thema hat, fast ausschließlich über das danach benannte Grafikformat zu schreiben, oder? --Pumbaa80 12:46, 12. Apr 2006 (CEST)
- Bitte nicht aufsplitten, oder wenn, dann nur in JFIF und JPEG. Das Thema ist z.Z. grauenhaft beschrieben, das wird aber wohl nur durch eine vollständige Neufassung möglich sein. Eine Aufsplittung ist unnötig und wird den Artikel nicht verbessern. --Phrood 18:45, 10. Apr 2006 (CEST)
Komprimierung durch Unterabtastung
Zitat aus dem Artikel: "wird eine vertikale und horizontale Unterabtastung um den Faktor 2 verwendet (YUV 4:2:0), die die Datenmenge um den Faktor 2 reduziert"
Wenn aber horizontal und vertikal je um den Faktor 2 unterabgetastet wird (= Mittelwert aus je zwei Spalten und zwei Zeilen = 4Pixel?),müsste dann nicht die Datenmenge um den Faktor 4 abnehmen? Oder verstehe ich da was falsch? -- Engywuck 00:02, 30. Sep 2005 (CEST)
da hat sich ein Fehler eingeschlichen ... bei der Reduktion in h und v nehmen die Farbdaten natürlich um den Faktor 4 ab! (ich habs korrgiert) http://en.wikipedia.org/wiki/Chroma_subsampling liestet für 4:2:0 auch JPEG ... irgendwie find ich den entsprechenden Artikel in der dt. WP nicht ...
Ja, die Datenmenge von Cb und Cr nehmen um Faktor 4 ab. Die Datenmenge des gesamten Bildes um Faktor 2.
Bsp: 8x8 Bild (24Bit RGB) = 192 Byte -> 8x8 Y (8Bit) = 64 Byte, 4x4 Cb (8Bit) = 16 Byte, 4x4 Cr (8bit) = 16 Byte gesamt = 96 Byte ( Abnahme um Faktor 2 )
Die Farbinformationen (Cb, Cr) haben jedoch von 128 auf 32 Byte ( Faktor 4 ) abgenommen.
Unverständlich
ich finde den artikel eigentlich sehr unverständlich ... schade --145.243.190.133 15:57, 23. Nov 2005 (CET)
- Ist das eine Frage? Anton 22:58, 11. Mär 2006 (CET)
Ich weiß zwar nicht, was der Kerl über mir wollte, aber mir ist aufgefallen, dass nirgendwo erklärt wird, was mit DC-Anteil gemeint ist. ("Umsortierung und Differenzkodierung des DC-Anteils")
Hier bin ich dann fündig geworden. --141.44.226.37 02:43, 20. Mär 2006 (CET)
Ich sehe das genauso: Die Umsortierung der Koeffizienten habe ich nicht verstanden, dafür mußte ich zusätzliche Quellen zu Rate ziehen
Beispielbilder
Hallo Uwe, deine Bilder habe ich hierher verschoben:
.png){kind=spacer}
Begründung: (1) Weiter unten finden sich bereits zwei Beispiele, die die Artefakte demonstrieren. (2) Der Inhalt der Bilder ist irreführend: die Schemazeichnungen mit den Beschriftungen haben nichts mit dem Artikel zu tun.
Anton 22:58, 11. Mär 2006 (CET)
- Ein weiteres Beispielbild gibt es uebrigens im Artikel Gibbssches Phänomen. --Phrood 23:13, 11. Mär 2006 (CET)
An dieser Stelle möchte ich mal anfragen, was denn die Prozentzahlen im jetzt noch verbliebenen Beispiel im Abschnitt "Visuelle Qualität von JPEG-Bildern" bedeuten. Ich weiß, dass man in vielen Bildverarbeitungsprogrammen so die Qualität festlegt, aber was hat z.B. die Angabe 20% konkret zu bedeuten? --Pumbaa80 18:25, 10. Apr 2006 (CEST)
- Überhaupt nichts. Die Prozentzahlen basieren auf einer vmm jeweiligen Programm definierten Qualitätsheuristik. Die maximale Qualitätsstufe bzw. 100% bedeutet nicht, dass das Bild verlustfrei ist. --Phrood 18:41, 10. Apr 2006 (CEST)
Beispielbild "Sonnenblume"
Mir scheint es so, als ob die Qualität dieses Sonnenblumen-Bildes schon von Haus aus sehr schlecht ist. Das Bild liese sich ja Problemlos durch ein anderes "hochqualitatives", aber stark JPEG-komprimiertes Bild ersetzen, jedoch wird diese Sonnenblume auch bei vielen anderen Kompressionsverfahren als Beispiel eingestzt. Was meint ihr, wäre es sinnvoll diese Beispielbilder zu erneuern? --Mr.checker 10:27, 27. Jul. 2007 (CEST)
Qualitätsminderung durch Löschen?
Hallo! Ich bin in Sachen JPEG Laie. Wenn ich ein abgespeichertes Bild "herunterlade" um des auszudrucken und nachher wieder lösche - findet dadurch bereits eine Qualitätsminderung statt. Ich meine nein, denn der Löschvorgang ist ja keine Wiederabspeicherung. Da sind jedoch einige meiner Kollegen anderer Meinung, und darunter ist ein Informatiker mit Hochschulabschluss. Wie verhält es sich in Wirklichkeit? (SP) 10.05.06
- Ich verstehe die Frage nicht. Wo soll durch löschen die Qualität schlechter werden? Durch löschen geht die Qualität auf Null, schleißlich ist das Bild komplett verschwunden, aber das hast du sicher nicht gemeint? --Berthold Werner 14:07, 10. Mai 2006 (CEST)
Entschuldigung, meine Frage war nicht gut formuliert. Also versuch ich es nochmals. Beim drehen und spiegeln gehen keine Daten verloren, das hab ich eben gelesen. Wie verhält es sich aber, wenn ich eine Datei auf der Festplatte von einem Ordner in einen anderen kopiere? Wenn ich eine heruntergeladene Datei nach dem ausdrucken wieder lösche, wird sie dann auf die Festplatte zurückgelegt und erneut gespeichert? Ich meinte also nicht, eine Datei von der Festplatte löschen. (SP) 13.08.06
- Beim Drehen und Spiegeln gehen nur dann keine Daten verloren, wenn die Transformation mit speziellen Programmen wie jpegtran vorgenommen wird. Was den Rest deiner Frage angeht: Computer arbeiten digital, beim Kopieren von Ordner zu Ordner bleiben die Daten daher absolut identisch. Tja, und vom Ausdrucken alleine wird eine gelöschte Datei nicht wiederhergestellt :) --Phrood 13:14, 13. Aug 2006 (CEST)
Weblinks
in den Weblinks muss es heißen "Artikel über versteckte Daten" ... bitte ändern
Stimmt. Ich hab's geändert. Danke für den Hinweis ;) --Gabbahead. 15:22, 3. Aug 2006 (CEST)
Der Link: jpegoptim http://www.cc.jyu.fi/~tjko/projects.html scheint tot zu sein. Bitte mal überprüfen. Danke.
Danke für den Hinweis ;-) Werde ihn entfernen. --Gabbahead. 15:35, 16. Sep 2006 (CEST)
Author hat jetzt eine eigene Seite: http://www.kokkonen.net/tjko/projects.html Bei mir bringt dieses Tool im Normalfall nur eine Verbesserung um 1-1.5% aber dafür verlustlos. Danke für den Tip!
Vorlage: Mediaformate
Bitte Vorlage "Mediaformate" hinzufügen :)
- Wollte das eigentlich probieren, aber da der Artikel nicht "JPEG" heißt, wird dieser Teil auch nicht hervorgehoben. --Cbuilder 12:40, 26. Aug 2006 (CEST)
- Habe die Vorlage entsprechend angepasst :) -84.58.155.190 13:57, 26. Aug 2006 (CEST)
Stufenweise schärfer werdene JPEG Bilder
Es fehlt noch die Beschreibung wie JPEG Bilder Funktionieren die Stufenweise schärfer werden, um schon nach der Übertragung eines geringen Teiles der Bilddaten ein schemenhaftes Bild anzuzeigen? Wo liegen die Unterschiede zum Interlaceing bei GIF Bildern? --Uwe W. 15:05, 8. Jan. 2007 (CET)
- Was du meinst, ist das so genannte Progressive JPEG. Es ist wichtig zu wissen, dass bei JPEG ein Bild ganz anders als bei verlustfreien Formaten repräsentiert wird, nämlich im Frequenzbereich mittels DCT-Koeffizienten. Diese Koeffizienten speichern keine Pixel, sondern Annäherungen des gesamten Bildinhalts eines 8x8-Bildblocks. Beim Progressive JPEG werden erst die ersten Koeffizienten jedes Bildblocks, dann die zweiten usw. der Reihe nach abgespeichert, so dass die Annäherung an das Originalbild immer besser wird. --Phrood 17:47, 11. Jan. 2007 (CET)
- Hallo Phood, ich habe aus deiner Antwort einen kurzen Abschnitt über Progressives JPEG im Artikel gemacht.--Uwe W. 18:58, 17. Mär. 2007 (CET)
Interlacing
Das Thema Interlacing sollte unbedingt auch angesprochen werden. --AndreR 16:28, 3. Feb. 2007 (CET)
- Es heißt bei JPEGs nicht Interlacing, sondern Progressive JPEG. Siehe auch den vorherigen Diskussionsabschnitt. --Phrood 16:33, 3. Feb. 2007 (CET)
Artikel teilen?
Dieser Artikel beschreibt die Joint Photographic Experts Group der ITU und das nach ihr benannte Grafikformat. Es währe jedoch sinnvoll nach [1] den Artikel über das Format unter die übliche Abkürzung zu setzen und für das Gremium der ITU den Namen Joint Photographic Experts Group beizubehalten, weil dieser normalerweise nicht abgekürzt wird. Außerdem dürfte es über das Gremium inzwischen wohl mehr zu schreiben geben als das Gründungsdatum und dass JPEG nach ihm benannt wurde. Für Weiterleitungen können Begriffserklärungsleiten gesetzt werden.--Uwe W. 13:32, 18. Mär. 2007 (CET)
- Ich stimme zu, würde sogar noch weiter gehen: Eine Teilung Gremium (Joint Photographic Experts Group) - Standard (JPEG) - Dateiformat (JIF/JFIF/SPIFF) wäre angemessen. --Phrood 14:55, 18. Mär. 2007 (CET)
- Ich habe den Artikel en:Joint Photographic Experts Group Übersetzt. Ich schlage desshalb vor ihn von Joint Photographic Experts Group (Organisation) auf diesen Atikelnamen zu verschiben, nachdem dieser Artikel nach JPEG verschoben wurde.--Uwe W. 16:49, 9. Jun. 2007 (CEST)
- Einverstanden, danke für die Übersetzung! --Phrood 18:15, 9. Jun. 2007 (CEST)
- Habe die Atikel Verschieben lassen.--Uwe W. 20:21, 9. Jun. 2007 (CEST)
- Einverstanden, danke für die Übersetzung! --Phrood 18:15, 9. Jun. 2007 (CEST)
- Ich habe den Artikel en:Joint Photographic Experts Group Übersetzt. Ich schlage desshalb vor ihn von Joint Photographic Experts Group (Organisation) auf diesen Atikelnamen zu verschiben, nachdem dieser Artikel nach JPEG verschoben wurde.--Uwe W. 16:49, 9. Jun. 2007 (CEST)
Laienfrage
Hallo, mal ne dumme Frage: Inwieweit kann man eine JPEG-Datei denn überhaupt von Hand schreiben? Müsste das in sehr einfachen Fällen nicht gehen? Oder geht das wirklich ausschliesslich mit Bildbearbeitungsprogrammen, die dann die im Artikel erläuterten codierungsschritte abarbeiten?Stoll 14:56, 4. Jun. 2007 (CEST)
- Die genannten Codierungsschritte sind erforderlich. Nichts hindert dich daran, eine JPEG-Datei von Hand mit einem Hex-Editor zu schreiben, aber es dürfte kaum Spaß machen, sich aus dem Kopf DCT-Koeffizienten auszudenken. --Phrood 18:15, 9. Jun. 2007 (CEST)
Fehler in "Umsortierung und Differenzkodierung des Gleichstromanteils"
In diesem Abschnitt hat sich wohl ein Fehler eingeschlichen. Die Umsortierung der Matrix-Koeffizienten erleichtert nicht die Entropiekodierung, sondern optimert das Ergebnis der Lauflängenkodierung! Ich habe das gleich mal korrigiert...
- Klingt vernünftig und stimmt aber wohl nur, wenn die Lauflängenkodierung vor der Huffman-Kodierung durchgeführt wird. Diese Reihenfolge steht nicht explizit im Artikel. Außerdem gibt es doch einen speziellen Huffman-Code für "Ab hier kommen nur noch Nullen". -- Jens m0 12:42, 26. Mär. 2009 (CET)
Wo Kompressionsrate verwendet
Hi
Vielleicht auch nur überlesen und die Mathematik fehlt mir auch. Wo wird die Kompressionsrate eingerechnet? --Georgius 21:21, 7. Sep. 2007 (CEST)
Artikel zusammenfassen? (JPEG und JPEG File Interchange Format)
Hallo,
auf der Suche nach Informationen zu jpg-Dateien habe ich in der Wikipedia-Suche die drei Buchstaben "jpg" eingegeben und bin auf die Seite http://de.wikipedia.org/wiki/JPEG_File_Interchange_Format JPEG File Interchange Format geleitet worden.
Hier gibt es nur spärliche Informationen zum Datei- und Grafikformat und nur wenig hilfreiche weblinks.
Dafür einen interessanten mir bisher unbekannten Hinweis auf "Versteckte Daten in JPEG-Dateien" und einen entsprechenden weblink. http://netzreport.googlepages.com/versteckte_daten_in_jpeg_dateien.html
Also habe ichs mal bei google mit "jpg" probiert und finde gleich als ersten link den zur Wikipediaseite http://de.wikipedia.org/wiki/JPEG JPEG
Hier stehen nun all die Informationen, die ich mir mit dem Suchbegriff "jpg" erhofft hatte.
Leider fehlt dafür zum Beispiel der Hinweis auf die versteckten Daten in JPEG-Dateien.
Spricht etwas dagegen die beiden Artikel sinnvoll zusammenzufassen?
oder erstmal jeweils einen "Begriffsklärungshinweis" voranzustellen?
Und welche Möglichkeit gibt es, die Suche so zu beeinflussen, dass beide Artikel gefunden werden?
Vielleicht kann sich dazu ja mal jemand äussern.
Möglicherweise übersehe ich als Nichtfachmann da ja irgendwelche wesentlichen Unterschiede?
--Wibelo 22:10, 27. Mär. 2008 (CET)
- Einen BKL-Hinweis könnte man wenn nötig einfügen, aber da der Unterschied zwischen JPEG und JFIF in den Einleitungen beider Artikel erklärt wird, möchte ich erst fragen, was du daran missverständlich findest? --Phrood 07:42, 28. Mär. 2008 (CET)
Es geht mir nicht um die Missverständlichkeit der Artikel, sondern um das Finden der gesuchten Informationen unter dem Suchbegriff "jpg".
Die Eingabe dieses Suchbegriffs in der Wikipedia führt per Weiterleitung einzig und allein zum Begriff "JPEG File Interchange Format" und es gibt keinerlei Hinweis darauf, dass es noch eine weitere Seite Namens "JPEG" in der Wikipedia gibt.
Auf dieser (zweiten) JPEG-Seite finden sich aber erst die Informationen, die in der Regel unter dem Begriff "jpg" gesucht werden. Das ist jedenfalls meine Einschätzung als Nichtfachmann für Grafik- und Datenformate, der in einem Nachschlagewerk unter diesem Begriff Informationen gesucht hat.
Inhaltlich ist mir der Unterschied zwischen JPEG und JFIF verständlich geworden. Wichtig ist mir aber in erster Linie, dass beide Artikel gefunden werden, wenn nach "jpg" gesucht wird. Am einfachsten über einen vorangestellten Begriffsklärungshinweis, ideal über eine Begriffsklärungsseite. --Wibelo 00:16, 30. Mär. 2008 (CET)
- Ich habe mal einen BKL-Hinweis zu beiden Artikeln hinzugefügt. --Phrood 09:51, 30. Mär. 2008 (CEST)
Ja, ich denke so ist es jetzt prima auseinander zu halten und man findet von einem Begriff zum anderen.
Fehlende laienverständliche Grundinformationen
Aus dem Artikel kann ich als Laie nicht entnehmen, wie viele Farben ein JPG darstellen kann. Irgend jemand meinte, es seien 256 (natürlich Quatsch), dann lese ich auf einer anderen Website, es seien 16,7 Millionen. Warum wird das in diesem Artikel nicht erwähnt und hergeleitet? So eine grundlegende Information sollte bereits in der Einleitung stehen. --87.178.139.232 13:34, 14. Aug. 2008 (CEST)
- 8 Bit und selten 12 Bit pro Farbkanal, also 16,7 Mio. bzw. 68,7 Mia. Farben --Phrood 20:11, 18. Aug. 2008 (CEST)
Vorteile und Nachteile ?
Warum sollte ich etwa .jpg verwenden und nicht etwa .bmp ?
- geringerer platzbedarf auf der festplatte, wenn es um fotos geht und der informationsverlust dir nix ausmacht ;) --.love.is.war. 16:40, 29. Mai 2009 (CEST)
"Stattdessen werden Formate eingesetzt, die verlustfrei komprimieren (...) Beispiele sind TIFF," stimmt nicht ganz, wenn ich mich nicht täusche bietet baseline TIFF (ein subset von TIFF das jedes programm verstehen sollte) sogar jpeg-komprimierung an .... --.love.is.war. 16:40, 29. Mai 2009 (CEST)
Aussprache von JPEG
Ein Aussprachehinweis wäre nicht schlecht ... (nicht signierter Beitrag von 217.65.29.34 (Diskussion | Beiträge) 15:51, 20. Okt. 2009 (CEST))
- Dann hier mal eine, wie wir sie vom Fach her aussprechen, und das als IPA: [] d...l.r..s kläranliegen 16:01, 20. Okt. 2009 (CEST)
Fehler im Artikel nicht korrigierbar, da kein "Seite bearbeiten" vorhanden !?
Weiss jemand, wieso man den Artickel nicht bearbeiten kann?
Habe da jetzt schon nen paar Fehler gefunden, aber mangels Bearbeitungsfunktion kann ich die nicht beheben. Beispiele:
Grober Inhaltlicher Fehler: "Y ist das Intensitätssignal (Luminanz)..." Es handel sich bei dem "Y" in YCbCr nicht um einen Luminanzwert. Richtig wäre Y', das einen von der Helligkeit abgeleiteten Wert darstellt. Das richtig als Y' zu bezeichnete Y hängt namlich nichteinmal linear mit der Helligkeit zusammen, sondern über eine Funktion die versucht das Helligkeits/Farbempfinden der menschlichen Auges nachzubilden (Funktion kommt weiter unten im Artickel). Siehe hierzu z.B. die englische Wikiseite über Farbunterabtastung http://en.wikipedia.org/wiki/Chroma_subsampling oder ein PDF zur Enstehung dieser zwischenzeitlich leider recht verbreiteten Y-Fehlinformation unter http://www.poynton.com/papers/YUV_and_luminance_harmful.html
Eher Schreibfehler wie: "..unter Nutzung einer fast Fourier transform (FFT) mit sehr wenig Aufwand implementieren." Sollte wohl eher Fast Fourier Transformation (FFT) heißen. (nicht signierter Beitrag von 84.57.255.253 (Diskussion | Beiträge) 14:05, 29. Sep. 2006 (CEST))
Farbraumumrechung
Im Artikel "Farbraumumrechnung" wird geschrieben, dass das Bild nach IEC 601 in den YCbCr-Farbraum umgerechnet wird. Meines Wissens existiert keine IEC 601-Norm. Sollte vielleicht die ITU-R BT.601 gemeint sein!? (vgl. Artikel YCbCr) Außerdem wird im Artikel "YCbCr" genannt, dass YCbCr kein Farbraum, sondern nur ein Farbmodell darstellt. Bitte gegebenenfalls ändern.
Bitte entschuldigt, falls ich irgendwo falsch gepostet habe, bzw. dass ich den Artikel nicht direkt geändert habe, aber dies ist mein erster Eintrag bei Wikipedia. (nicht signierter Beitrag von 217.82.29.254 (Diskussion | Beiträge) 18:49, 6. Dez. 2006 (CET))
Was bedeutet Energiekommpressionseigenschaft?
Im Zusammenhang mit der diskreten Fourier Transformation und dem JPEG-Algorithmus ist mir unklar, was der Ausdruck "gute Energiekompressionseigenschaft" bedeuten soll?
Vielleicht kann mir jemand auf die Sprünge helfen, falls meine Kritik berechtigt sein sollte, sollte der Artikel verbessert werden. (nicht signierter Beitrag von 84.148.100.64 (Diskussion | Beiträge) 23:00, 31. Jul. 2008 (CEST))
Exif-Info in Datei nicht angesprochen?
Ich hab intensiv gesucht, aber die in Jpg möglichen EXIF-Infos sind nirgendwo erwähnt ... Sollte aber wohl besser, oder? Spacesson 22:46, 26. Jul. 2010 (CEST)
- Die Möglichkeit, EXIF-Daten zu speichern, gibt es beim umgangssprachlich so genannten "JPG-Dateiformat", dessen richtige Bezeichnung JPEG File Interchange Format (JFIF) ist. JPEG ist im Gegensatz dazu nur der Name des Kompressionsverfahrens und des Gremiums, das das Verfahren entwickelt hat. Siehe dazu auch die BKL-Leisten der beiden Artikel -- 89.182.141.135 16:10, 21. Sep. 2010 (CEST)
Häh?
"jedoch wurde 2002 Stand der Technik gefunden, der das beanspruchte Verfahren offenbart, sodass die Ansprüche kaum durchsetzbar sind"
der satz ergibt grammatikalisch keinen sinn. --Bothary 00:45, 3. Okt. 2010 (CEST)
Metadaten
Es gibt in dem Artikel keinerlei Informationen über die verfügbaren Möglichkeiten, Metadaten in JPEG-Dateien zu speichern. Es wäre schön, wenn dies, inklusive ggf. existenter Standards eingearbeitet werden würde. --Sepp 13:50, 10. Feb. 2011 (CET)
- Meinst du die Exif-Daten usw.? Dazu siehe oben. -- Bernhard F. J. H. 16:06, 11. Feb. 2011 (CET)
Hups, ja, habe ich übersehen. Dann hat sich das hiermit erledigt… --Sepp 22:39, 13. Feb. 2011 (CET)
DCT nicht verlustfrei
"was auch bedeutet, dass die DCT verlustfrei ist, es gingen keine Informationen verloren, da die Daten lediglich in eine für die weitere Verarbeitung günstigere Form gebracht wurden"
DCT ist nicht verlustfrei !??! (nicht signierter Beitrag von 217.224.186.85 (Diskussion) 00:26, 25. Jul 2011 (CEST))
- Die DCT ist tatsächlich verlustfrei (von Rundungsfehlern abgesehen). Erst bei der nachfolgenden Quantisierung gehen Informationen verloren. --Phrood 12:07, 25. Jul. 2011 (CEST)
Ich denke, dass die DCT verlustbehaftet ist, da sie letzendlich auf den Fourierreihen basiert. Im Artikel zur Diskreten Kosinustransformation (deutsch und englisch) steht auch eindeutig, dass es sich um ein verlustbehaftetes Verfahren handelt. Die Anzahl der Koeffizienten ist begrenzt, sodass es nicht möglich ist, alle Schwingungsanteile auch wirklich zu erfassen. Für sehr hohe Frequenzen steht kein Mittel der Darstellung zur Verfügung, weil die Koeffizientenanzahl fest ist. Beim Googeln findet man renommierte Unis, die es auch als verlustbehaftet bezeichenen. (nicht signierter Beitrag von 87.188.56.246 (Diskussion) 17:07, 21. Jan. 2013 (CET))
- Das ist etwas "Theorie vs. Praxis", sowie muntere Durchmischung der beiden.
- In der Praxis sind die Farbwerte RGB jeweils 8 Bit, also die Werte 0..255 . Wenn man hierauf DCT betreibt mit Gleitkommazahlen ausreichender Genauigkeit, keine Quantisierung, dann kann man die RGB-Werte wieder rückwärts rechnen, und (mit Runden) kommen wieder dieselben RGB-Werte heraus.
- Insofern war das Verfahren in der Praxis also "komplett verlustfrei". --arilou (Diskussion) 13:26, 23. Jan. 2013 (CET)
Verlustfreie Nachbearbeitung von JPEG
Meines Erachtens gehört da noch XNView hinein - nicht nur IrfanView.
Peter B.
- Nein, denn für Beispiel-Nennung genügen wenige.
- "Das noch, das auch noch, jenes sollte noch genannt werden, das noch, ..."
- Eigentlich sollte man die beiden Beispiele sowieso rausschmeißen, sowas findet man in Google leicht.
- --arilou (Diskussion) 12:22, 13. Feb. 2013 (CET)
Kompressionsfaktor
Wie ermittelt man den Kompressionsfaktor? Naiverweise könnte man annehmen, dass man "Originalgröße / Größe der komprimierten Datei" berechnen kann. Offensichtlich ist das nicht so: Manche Programme haben einen "Komprimierungsgrad" von 0 bis 100, andere geben nur "Faktoren" von 0 bis 20 oder 25 an. Manchmal sprechen die Unterlagen auch von einer Kompressionsrate. Ich vermute, dass es sich dabei um das Verhältnis "Originalgröße / Größe der komprimierten Datei" handelt.
Vorschlag einer Formulierung: Kompressionsrate berechnet sich durch .... Der Begriff Kompressionsfaktor wird nicht einheitlich verwendet... und wird meist als synonym zum Begriff Qualitätsfaktor bzw. Quantisierungsfaktor (dieser wird als Teiler für die Amplituden der berechneten Kosinusfunktionen verwendet).
Peter B. (nicht signierter Beitrag von 80.187.107.32 (Diskussion) 08:37, 12. Feb. 2013 (CET))
- Da gibt's leider nix verbindliches.
- Oft wird als Kompressionsrate
- entweder angegeben "wurde auf nn % der Ursprungsgröße komprimiert"
- oder "wurde um mm % der Ursprungsgröße komprimiert".
- Wenn also aus 1000 Bytes 10 Bytes werden, sagt der eine "auf 1% komprimiert", der andere "um 99% komprimiert".
- Der "Kompressionsfaktor" ist i.A. wohl der Kehrwert des "auf"-Prozentsatzes, hier also =100 .
- --arilou (Diskussion) 12:28, 13. Feb. 2013 (CET)
JPEG in CMYK
Photoshop und andere Software erlaubt es auch JPEG im Farbraum CMYK abzuspeichern. Ist das dem Standard nach erlaubt oder ist das eine Photoshop Workaround? CMYK müsste doch dann auch irgendwie vom Algorithmus in YCbCr umgerechnet werden... Weiß da jemand was dazu zu ergänzen? --Phoenixxxxxx (Diskussion) 10:38, 16. Sep. 2014 (CEST)
Problematische Bildunterschrift bzw. problematische Versuchsreihe
Unter der "Versuchsreihe" im Abschnitt "Verlustfreie Nachbearbeitung von JPEG" rechts steht:
Verluste beim wiederholten Rotieren und Speichern eines JPEG-Bildes mit „krummer“ Auflösung 1021 × 767 (nicht durch 16 teilbar). Das wiederholte Rotieren von JPEG-Bildern mit durch 16 teilbarer Auflösung (z. B. 1024 × 768) bei Verwendung immer der gleichen Quantisierungsmatrix ist dagegen (bei ordnungsgemäßer Implementierung) verlustfrei.
Ich beweifle, dass die gezeigten Verluste etwas mit dem Rotieren zu tun haben. Ebenso dürfte das nichts mit der "ungeraden" Größe des Bildes zu tun haben. Die nicht durch 16 teilbare Größe bewirkt ja lediglich, dass ich es nicht mit einer verlustfreien Bearbeitungsoption manipulieren kann. (Außer, diese schneidet die "überstehenden" Pixel ab, was die mir bekannten Programme mit dieser Option tun und was natürlich auch einen Verlust darstellt.)
Vermutlich soll das Bild doch lediglich zeigen, was bei wiederholtem Kodieren und wieder Dekodieren passiert. Das muss dann mit einem üblichen EBV-Programm gemacht worden sein, wobei die Frage ist, mit welcher Programm und mit welcher Qualitäts- bzw. Kompressionsstufe da gearbeitet wurde. Dann gehört das Bild aber auch nicht in diesen Abschnitt!
Übrigens haben meine eigenen Versuche gezeigt, dass ein 100-facher Durchlauf des Musters Laden - Speichern als - eben gespeichertes Bild laden usw. keine visuellen Unterschiede zeigt, wenn es sich um ein "übliches" Foto handelt und mit einer geringen Kompression gearbeitet wird. Aber natürlich unterscheiden sich die Dateien im binärvergleich. --Karsten Meyer-Konstanz (D) 12:18, 19. Nov. 2014 (CET)
Texturierung aus ähnlichsten Blöcken kopieren!
/*
Das ist das neue "Loesch' das halbe Bild raus und klatsch die aehnlichen
Teile aus der uebrigen Haelfte drueber'.
Man kann die "Technologie" der MPEG-Bewegungssuche naemlich auch auf
Standbilder anwenden. Die Bloecke werden einfach auf Aehnlichkeit ver-
glichen, indem man Pixel fuer Pixel den Betrag der Differenzen addiert.
Und das Aehnliche loescht man raus
und die geloeschten Bereiche
schnoerkelt man mit dem aehnlichsten
uebriggebliebenen Block aus, auf
den man einen Referenzwert speichert.
Mit der DCT hat man kein Glueck. Es bleibt bei der Kontrastschwellenbegrenzten Flood-Fill-Mittelwertbildung.
Die bringt kombiniert mit Ziv-Lempel eine Kompressionsrate von einem
halben JPEG und die uebrige Haelfte vom
Bild kann man wie gesagt einfach rausloeschen.
*/
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
unsigned char bild[64000];
unsigned char maske[64000];
unsigned char ausgabe[64000];
float mvalue, mvalue_sum;
int main(int argc, char*argv[])
{
FILE *input, *output;
int n=0, n2=0,copy_dest;
int x_add, y_add;
struct
{
float phase, streck, dehn ;
} welle[6];
struct
{
float phase, streck, dehn ;
} probier[6];
int wellnum ;
int naehernum;
double abweich=0.0, old_abweich=1000000.0, pixdiff ;
input=fopen(argv[1],"rb");
if ( argc != 2 )
{
printf("Falsche Anzahl Argumente!\n");
return 1;
}
if ( input == NULL )
{
printf("Datei nicht gefunden!\n");
return 1;
}
fread( bild, sizeof(unsigned char), 64000, input);
fclose(input);
n=0;
while(n<64000) { maske[n]=0; n++; }
n2=0;
while ( n2 < 61440)
{
if ( n2>= 61440 ) break;
if ( n2%320 ==0 && n2 > 0 ) n2+= ( 320*3 );
if ( n2 >= 61440 ) break;
old_abweich=100000000.0 ;
n=n2+4;
if ( n%320 ==0 && n > 0 ) n+= ( 320*3 );
while ( n < 61440 )
{
abweich=0;
x_add=0, y_add=0;
while ( y_add < 4 )
{
x_add=0;
while ( x_add < 4 )
{
if ( maske[(n2+x_add) %320+ (n2/320+y_add)*320]==0 )
ausgabe[(n2+x_add) %320+ (n2/320+y_add)*320]=bild[ (n2+x_add) %320+ (n2/320+y_add)*320 ];
abweich+= fabs( bild[ (n2+x_add) %320+ (n2/320+y_add)*320 ]- bild[ (n+x_add) %320+ (n/320+y_add)*320 ] );
x_add++;
}
y_add++;
}
if ( abweich < old_abweich )
{
old_abweich=abweich;
copy_dest=n;
}
n+=4;
if ( n%320 ==0 && n > 0 ) n+= ( 320*3 );
}
x_add=0, y_add=0;
while ( y_add < 4 )
{
x_add=0;
while ( x_add < 4 )
{
ausgabe[ (copy_dest+x_add) %320+ (copy_dest/320+y_add)*320 ]= 255; /* bild[ (n2+x_add) %320+ (n2/320+y_add)*320 ] */;
maske[(copy_dest+x_add) %320+ (copy_dest/320+y_add)*320]=1;
x_add++;
}
y_add++;
}
n2+=4;
}
output=fopen("outff.raw","wb");
fwrite(ausgabe,sizeof(unsigned char),64000, output);
fclose(output);
}
(nicht signierter Beitrag von 87.143.95.241 (Diskussion) 11:36, 4. Jul 2015 (CEST))
- Kann es sein, dass eine wild gewordene Maschine diese Einträge generiert? Ich verstehe nämlich nur Bahnhof. --Karsten Meyer-Konstanz (D) 14:51, 4. Jul. 2015 (CEST)
Ich erkläre es: wenn man sich so umblickt, sieht man viele Flächen mit relativ ähnlicher Helligkeit und Farbe. Erst da, wo diese Flächen enden, nimmt man einen deutlichen Übergang wahr. Würde man nun in einem Bitmap den Flood-Fill-Algorithmus über diese Flächen ausbreiten, den Mittelwert der erfaßten Pixel berechnen, den Flood-Fill an den Kontrasträndern abbrechen und den erfaßten Bereich mit dessen Farb- und Helligkeitsmittelwert füllen, hätte man eine Menge Redundanz ins Bitmap eingebracht. Wie "Malen nach Zahlen" mit lauter gleichfarbigen Flächen. Die Redundanz kann von einem Packprogramm dann erfaßt werden. Aber das allein zieht mit JPEG noch nicht gleich auf. Die nächste Idee war, man kennt das ja von diesen computererzeugten Bildern, die als ein Mosaik aus Einzelfotographien zusammengesetzt sind und in denen man als Ganzheit trotzdem eine bildliche Darstellung erkennt: einen Bereich(z.B. eine kleine Kachel) des Bildes über ähnliche Bereiche kopieren, dann braucht man diese Bereiche nicht zu speichern. Genau das macht das (noch immer fehlerhafte) Programm im Listing auch. Die Flächentexturierung bleibt erhalten und es fällt auf den ersten Blick auch nicht auf. Beide Sachen zusammengenommen müßten reichen, um gegen JPEG anzukommen. Die Sache mit der diskreten Cosinustransformation halte ich für ein Märchen. Ich habe es erst gestern noch versucht, die Helligkeitsverläufe in Bildblöcken als Summe von Sinusfunktionen anzunähern (es gab mal einen visuellen Plasmaeffekt in Grafikdemos, der war Grundlage der Idee), aber ich glaube nicht, daß das effektiv ist. Die verraten ganz einfach nicht, wie sie es gemacht haben. (nicht signierter Beitrag von 93.201.1.161 (Diskussion) 06:13, 5. Jul 2015 (CEST))
- Kannst du den Algorithmus mal auf ein paar Beispielbilder wie File:Eristalis tenax auf Tragopogon pratensis 01.JPG anwenden und uns die Ergebnisse zeigen? --McZusatz (Diskussion) 09:04, 5. Jul. 2015 (CEST)
Bitte keine WP:Originäre Forschung in der Wikipedia.
Wer ein neues Kompressionsverfahren erfinden möchte darf das gerne tun, aber bitte nicht hier. Dafür kann man Bücher oder ähnliche Veröffentlichungen schreiben.
Außerdem bewirken Quantisierungsmatrix sowie LZH-Kompression von JPEG bereits eine starke Komprimierung sehr ähnlicher Bereiche, sodass ich kaum glaube, dass man da noch einen großen Vorteil rausholen kann.
--arilou (Diskussion) 11:29, 8. Jul. 2015 (CEST)
Beispielbild
http://cloud.directupload.net/1UFp
Dateigröße ging auf ca. 6KB runter. Die Farbtiefe wurde durch binäres Shiften auf 5Bit reduziert.
Beim Blockrauslöschen fehlt noch einiges, da muß ein besseres Verfahren her. (nicht signierter Beitrag von 87.143.89.49 (Diskussion) 02:21, 6. Jul 2015 (CEST))