Diskussion:JPEG/Archiv

message: 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)
replies: text: Nanu. Ist die Filterung denn schon aktiv? Auf der Website des bka steht nichts darüber. --Berthold Werner 17:15, 1. Mai 2009 (CEST)
replies: text: Das angezeigte Bild entspricht auch nicht dem in c't 10 auf Seite 52 gezeigten. --Berthold Werner 13:13, 4. Mai 2009 (CEST)
thread_title:  Verlinkung auf Kinderpornographie? 

message: 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)
thread_title:  Spart JPG außer Platz auf Datenträger auch Platz im RAM? 

message: 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)
thread_title:  Quantisierung 

message: (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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  C-Quellcodes zur Analyse von JPEG-Dateien 

message: 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)
replies: text: Zur Patenten steht hier etwas auf der Offiziellen JPEG-Homepage--Uwe W. 12:55, 19. Jan. 2008 (CET)
replies: text: Diese Webseite erklärt leider überhaupt nichts. --Phrood 14:06, 19. Jan. 2008 (CET)
thread_title:  JPEG-Patent 

message: 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)
replies: text: 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)

text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Artikel aufsplitten? 

message: 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)
thread_title:  Komprimierung durch Unterabtastung 

message: ich finde den artikel eigentlich sehr unverständlich ... schade --145.243.190.133 15:57, 23. Nov 2005 (CET)
replies: text: Ist das eine Frage? Anton 22:58, 11. Mär 2006 (CET)
thread_title:  Unverständlich 

message: Hallo Uwe, deine Bilder habe ich hierher verschoben:
	
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)
replies: text: Ein weiteres Beispielbild gibt es uebrigens im Artikel Gibbssches Phänomen. --Phrood 23:13, 11. Mär 2006 (CET)

text: Ü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)
thread_title:  Beispielbilder 

message: 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)
thread_title:  Beispielbild "Sonnenblume" 

message: 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)
replies: text: 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)
thread_title:  Qualitätsminderung durch Löschen? 

message: 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)
thread_title:  Weblinks 

message: 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)
replies: text: Habe die Vorlage entsprechend angepasst :) -84.58.155.190 13:57, 26. Aug 2006 (CEST)
thread_title:  Vorlage: Mediaformate 

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Stufenweise schärfer werdene JPEG Bilder 

message: Das Thema Interlacing sollte unbedingt auch angesprochen werden. --AndreR 16:28, 3. Feb. 2007 (CET)
replies: text: Es heißt bei JPEGs nicht Interlacing, sondern Progressive JPEG. Siehe auch den vorherigen Diskussionsabschnitt. --Phrood 16:33, 3. Feb. 2007 (CET)
thread_title:  Interlacing 

message: Dieser Artikel beschreibt die Joint Photographic Experts Group der ITU und das nach ihr benannte Grafikformat. Es währe jedoch sinnvoll nach  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)
replies: text: 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)
replies: text: 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)
replies: text: Einverstanden, danke für die Übersetzung! --Phrood 18:15, 9. Jun. 2007 (CEST)
replies: text: Habe die Atikel Verschieben lassen.--Uwe W. 20:21, 9. Jun. 2007 (CEST)
thread_title:  Artikel teilen? 

message: 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)
replies: text: 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)
thread_title:  Laienfrage 

message: 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)
thread_title:  Fehler in "Umsortierung und Differenzkodierung des Gleichstromanteils" 

message: Hi
Vielleicht auch nur überlesen und die Mathematik fehlt mir auch. Wo wird die Kompressionsrate eingerechnet?
--Georgius 21:21, 7. Sep. 2007 (CEST)
thread_title:  Wo Kompressionsrate verwendet 

message: 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)
replies: text: 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)

text: Ich habe mal einen BKL-Hinweis zu beiden Artikeln hinzugefügt. --Phrood 09:51, 30. Mär. 2008 (CEST)
thread_title:  Artikel zusammenfassen? (JPEG und JPEG File Interchange Format) 

message: 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)
replies: text: 8 Bit und selten 12 Bit pro Farbkanal, also 16,7 Mio. bzw. 68,7 Mia. Farben --Phrood 20:11, 18. Aug. 2008 (CEST)
thread_title:  Fehlende laienverständliche Grundinformationen 

message: 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)
thread_title:  Vorteile und Nachteile ? 

message: Ein Aussprachehinweis wäre nicht schlecht ... (nicht signierter Beitrag von 217.65.29.34 (Diskussion | Beiträge) 15:51, 20. Okt. 2009 (CEST)
replies: text: 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)
thread_title:  Aussprache von JPEG 

message: 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)
thread_title:  Fehler im Artikel nicht korrigierbar, da kein "Seite bearbeiten" vorhanden !? 

message: 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)
thread_title:  Farbraumumrechung 

message: 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)
thread_title:  Was bedeutet Energiekommpressionseigenschaft? 

message: 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)
replies: text: 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)
thread_title:  Exif-Info in Datei nicht angesprochen? 

message: "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)
thread_title:  Häh? 

message: 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)
replies: text: Meinst du die Exif-Daten usw.? Dazu siehe oben. -- Bernhard F. J. H. 16:06, 11. Feb. 2011 (CET)
thread_title:  Metadaten 

message: 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)
thread_title:  Verlustfreie Nachbearbeitung von JPEG 

message: 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)
thread_title:  JPEG in CMYK 

message: 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)
thread_title:  Problematische Bildunterschrift bzw. problematische Versuchsreihe 

message: /*
  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)
replies: text: 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)

text: 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)
thread_title:  Texturierung aus ähnlichsten Blöcken kopieren! 

message: 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)
thread_title:  Beispielbild