12 Bit haben immer Vorteile, egal ob RAW oder einem andern Format.
Hier geht es ja darum, dass zwei JPEG s, einmal in 8 und einmal in 12Bit als (vermutlich) im TIFF verglichen wurden.
Und was ist das für ein Vergleich.
Es liegt also nicht in erster Linie am RAW, sondern der ungleichen Voraussetzung.
Man müsste also auch ein 12Bit Bild der Kamera dagegen halten.
WoWu hat geschrieben:
Aber immerhin 12 Bit ... ich hatte das nun nicht richtig verstanden. Ist das nun nur Photo oder ist das Video ?
Video ???
mehrere 1000€ teure DSLRs können keine 12bit-Videos - denkst du wirklich, ein Telefon würde dies bieten.
Können kein 12Bit Video raustun.... weil die Kompression dem Anspuch nicht genügt.
Wenn sie es ähnlich komprimieren, könnten Sie das auch.
Warum sollte also ein Handy kein hochkomprimiertes 12 Bit Video raustun ?
Es ist alles eine Frage des Anspruchs. Und bei Handys war der bisher nicht allzu hoch.
Und wenn die Pocket BMD das kann, warum kein Handy, mit mehr Abstrichen in Bezug auf Qualität ?
WoWu hat geschrieben:Ist das nun nur Photo oder ist das Video ?
hast dir einmal so überschlagsmäßig ausgerechnet, welche datenmenge bzw. i/o bandbreite ein derartiges format bei 25fps ergeben würde:
ein frame belegt laut dem schreenshot vom kluster 24.79 mega byte.
das sind (24.79 * 8 * 2**20) etwa 207953592 bit
multipliziert mit den 25 bildern pro sekunde, würde das einen duchsatz von (_ * 25 / 2**20) 4958 mbps mit sich bringen. ein bisserl viel für ein gebräuchliche micro sd karte würde ich sagen... (oder ich hab mich schon wieder verrechnet ;)) ...und gleichzeit viel zu wenig für echte slashcam helden, die es ja erst ab mind 60fps für brauchbar halten würden. ;)
Zuletzt geändert von mash_gh4 am So 21 Aug, 2016 16:05, insgesamt 1-mal geändert.
Ja, ich hatte das oben noch kurz nachgereicht ...
IASI. stellt da ja eine Grundsatzfrage in Bezug auf Handys ... aber wenn die BMD das zufriedenstellend kann, warum dann kein Handy mit mehr Abstrichen, denn einen Bildvergleich zwischen dem Handy und der Pocket gibt es ja noch nicht, also ... warum nicht ?
Und in Handys passen auch andere Speicher, es bleibt aber trotzdem ein Handy.
Ich weiß zwar nicht, wie hoch die Pocket integriert ist, kann mir aber gut vorstellen, dass BMD auch nur auf Massendesign zurückgreift, um die Preise niedrig zu halten.
Das wäre dann aber dieselbe Quelle, auf die auch Handyfirmen zugreifen könnten.
Da sehe ich also durchaus keine Hürden.
WoWu hat geschrieben:Schau doch mal, ob in den IPTC CORE und EXTENTIONS noch was steht, denn IPCT beschreibt eigentlich auch, in welchem Format abgelegt wird.
Aber immerhin 12 Bit ... ich hatte das nun nicht richtig verstanden. Ist das nun nur Photo oder ist das Video ?
Zieh doch einfach mal das RAW File auf Media Info, dann müsste in "General" auch das Bildformat sichtbar sein und es würde mich wundern, wenn da kein Tiff rauskommt.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
klusterdegenerierung hat geschrieben: Dann schaue Dir doch mal meinen letzten Screenshot etwas genauer an, besonders den Tisch, da wirst Du die natürliche Struktur und Schärfe des Holzes gegenüber dem matschigen irgendtwas des jpg gut erkennen
Ja, die erkenne ich. Für mich persönlich ist das Ergebnis Deiner RAW-Konvertierung ja auch klar besser als das JPEG. Aber das allein wäre auch mit einem besseren/flexibleren JPEG-Engine innerhalb des Handys machbar; dazu müsste der Hersteller noch nicht gleich eine RAW-Option einbauen.
Der Sinn von RAW liegt für mich generell in den Nachbearbeitungsreserven - nicht in einem sofort sichtbaren Qualitätsvorteil. Es gibt doch jede Menge Beispiele von Kameras, wo die JPEGs aus der Kamera erst mal "besser" aussehen als das, was der RAW-Konverter standardmäßig auswirft (und, wie schon erwähnt, würde auch bei Deinem Beispiel so mancher Laie das JPEG vorziehen, weil es schärfer und bunter ist als Deine Konvertierung). Trotzdem hat RAW hier natürlich klare Vorteile für den, der damit umzugehen weiß.
Danke übrigens für das Hochladen der DNG-Datei.
Ich bin mir relativ sicher, dass es eine echte RAW-Datei ist (also im Vor-Bayer-Zustand). MediaInfo zeigt "RAW" an, und in Lightroom kann ich eine echte Farbtemperatur für den Weißabgleich einstellen (nicht nur +-100, wie es beim Öffnen von anderen Formaten möglich ist).
Das DNG-Format erlaubt ja das Verarbeiten von (Bayersensor-)Rohdaten in Adobe-Software, auch wenn die entsprechende Kamera noch nicht bekannt ist. So dürfte das auch in diesem Fall funktionieren. Die Folge ist, dass Lightroom kein spezifisches Kameraprofil anwenden kann, wie es für bekannte Kameratypen gemacht wird. Deswegen ist die Grundeinstellung (die man sieht, wenn man Deine mitgespeicherten Einstellungen zurücksetzt) erst mal ziemlich langweilig.
Interessant wäre, was man rausholen kann, wenn man sich mittels ColorChecker ein eigenes Profil für diese Handykamera erstellt. Dann müsste es gleich wesentlich besser aussehen.
WoWu hat geschrieben:12 Bit haben immer Vorteile, egal ob RAW oder einem andern Format.
Hier geht es ja darum, dass zwei JPEG s, einmal in 8 und einmal in 12Bit als (vermutlich) im TIFF verglichen wurden.
Und was ist das für ein Vergleich.
Es liegt also nicht in erster Linie am RAW, sondern der ungleichen Voraussetzung.
Man müsste also auch ein 12Bit Bild der Kamera dagegen halten.
na - ein 8-bit- oder ein 12-bit-Bild - wie es nun auch immer genannt wird - wie du ja auch sagst, haben 12 Bit immer Vorteile.
Die Möglichkeiten, die in den 12-Bit stecken, zeigt der Vergleich ja durchaus.
Ich find es durchaus auch spannend - zumal die Fotofähigkeiten der Smartphones ja durchaus ziemlich zugelegt haben.
Gute Linsen, eben die 12-Bit bis hin zu OIS holen durchaus etwas aus den kleinen Sensoren.
Ja, aber daran zweifelt auch kein vernünftiger Mensch, nur hier wurden zwei paar Schuhe verglichen, die man gar nicht vergleichen kann, es sei denn, ich stelle die Kameras gegenüber aber darf kein 8Bit Bild mit einem 12Bit Bild vergleichen und sagen, es liegt am RAW.
Das ist nun weit daneben geschossen.
was mich übrigens verwundert, ist die 12bit angabe in adobe?
as format bzw. die metainformationen im file geben immer 16bit an, aber es ist natürlich bei tiffs mit höherer farbtiefe, aber eben auch DNG, üblich, dass nur ein teil der 16bit breite tatsächlich genutzt wird.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Weil TIFF Implementierungen nichts anderes vorsieht und lediglich eine, im Standard festgeschriebene Codelänge des Variable length Code von 12Bit benutzt.
We will arbitrarily limit ourselves to 12-bit codes, so that our table can have at most 4096 entries. The table should not be any larger.
Whenever you add a code to the output stream, it “counts” toward the decision about bumping the code bit length. This is important when writing the last code word before an EOI code or ClearCode, to avoid code length errors.
What happens if we run out of room in our string table? This is where the ClearCode comes in. As soon as we use entry 4094, we write out a (12-bit) ClearCode. (If we wait any longer to write the ClearCode, the decompressor might try to interpret the ClearCode as a 13-bit code.) At this point, the compres- sor reinitializes the string table and then writes out 9-bit codes again.
WoWu hat geschrieben:Weil TIFF Implementierungen nichts anderes vorsieht und lediglich eine, im Standard festgeschriebene Codelänge des Variable length Code von 12Bit benutzt.
du solltest das nicht unbedingt auf DNG übertragen. dort werden zwar ganz wesentliche mechnismen genutz, mit denen tiff die files intern strukturiert, aber ich bezweifle, dass das auch in puncto komprimierung alles übernommen würde. das würde so gar nicht zu den anforderungen im RAW umfeld passen. ich hab mich allerdings zum glück mit diesem detail auch noch nie näher herumschlagen müssen.
Ich beziehe das auch gar nicht auf ein allgemeines RAW Umfeld sondern auf den, hier diskutierten DNG Fall in dem ein TIFF über ein lossless JPEG (also nicht über die DCT sondern basiert auf DPCM) entsteht und somit gar kein RAW Umfeld mehr im eigentlichen Sinn repräsentiert, so wie der Fall hier vorliegt.
die DNG spezifikation sieht, neben der von dir angesprochenen JPEG variante mit all ihren eigenwilligkeiten, auch eine unkomprimierte variante vor (s.18 in der spezifikation). genau diese kommt auch im konkret vorliegenden fall zur anwendung. das lässt sich ganz einfach mit einem:
DAnn schau doch nochmal, was da oben in Media Info steht.
Da steht nämlich TIFF.
Zu Anwendung (in diesem Fall) kommen also die TIFF Spezifikationen und nicht die vagen Möglichkeiten, die DNG so alles bietet.
IN DNG kannst Du auch parallel das Original RAW mitführen, das sagt aber in unserm Fall nicht, dass das so gemacht wurde.
Orientier Dich doch mal an der aktuellen Sachlage sonst reden wir nämlich über zwei verschiedene Dinge, einmal über den Bildvergleich dieses Threads und ein anderes Mal darüber, was man alles mit DNG machen könnte.
Und ein Hinweis, dass in den Metadaten das Pettern aufgeführt ist ist kein Hinweis darauf, dass RAW durchgereicht wird sondern lediglich ein Hinweis darauf, dass das Konvertierungsprogramm in die Lage versetzt worden ist, das Pattern zu nutzen, in dem Fall also DNG ... und nicht wie in RAW Formaten, in denen das nicht in den Metadaten steht, sowas schätzen muss.
Die Metadaten sind für den DNG Konverter einfügt. (dankenswerter Weise, was durchaus nicht von jedem Hersteller gemacht wird).
DNG verwendet zwar die tiff file-strukturierung, weicht aber in anderen wichtigen punkten deutlich davon ab bzw. erweitert die klassische tiff konventionen. das ist ungefähr so, wie ja auch in verschiedenen video-typischen containeren verschiedenste codecs platz finden können, die teilweise gar nicht in der ursprünglichen container-spezifikation vorgesehen waren. das "Compression Scheme: None" spricht hier jedefalls eine klare sprache.
WoWu hat geschrieben:Und ein Hinweis, dass in den Metadaten das Pettern aufgeführt ist ist kein Hinweis darauf, dass RAW durchgereicht wird sondern lediglich ein Hinweis darauf, dass das Konvertierungsprogramm in die Lage versetzt worden ist, das Pattern zu nutzen, in dem Fall also DNG ... und nicht wie in RAW Formaten, in denen das nicht in den Metadaten steht, sowas schätzen muss.
Die Metadaten sind für den DNG Konverter einfügt. (dankenswerter Weise, was durchaus nicht von jedem Hersteller gemacht wird).
also -- nachdem ich schon für zwei kameras, für die unter linux noch kein raw support verfügbar war, die entsprechende unterstützung mitentwickelt habe, solltest mir eigentlich glauben können, dass ich ein bisserl was drüber weiß, wo man die entsprechenden infos findet und was sie bedeuten!
Fehlen Dir nun wieder die sachlichen Argumente ?
Lies mal die TIFF Spezifikationen und dann beschwer' Dich bei Media Info, was sie da für einen Quatsch aus dem File rauslesen.
WoWu hat geschrieben:Fehlen Dir nun wieder die sachlichen Argumente?
nein -- ich hab versucht, es so gut wie möglich mit fakten zu belegen bzw. auf die betreffenden stellen der hier tatsächlich relevanten spezifikation zu verweisen.
was soll noch mehr unternehmen, um notorisch ungläubigen besserwissern zu begegnen?
WoWu hat geschrieben:Lies mal die TIFF Spezifikationen und dann beschwer' Dich bei Media Info, was sie da für einen Quatsch aus dem File rauslesen.
wie gesagt, ich halte die DNG spezifikation für die deutlich naheliegendere quelle. sie erklärt ohnehin ganz genau, in welcher weise TIFF als technische rahmenvorgabe zu verstehen ist.
WoWu hat geschrieben:DAnn schau doch nochmal, was da oben in Media Info steht.
Da steht nämlich TIFF.
Nach der Theorie dürften dann aber meine CR2, ARW und auch RAF Rawformate alle keine Raws sein, denn in allen steht auch nur die Auflösung und TIFF in Mediainfo!
Das ist ja gerade die alte RAW -echt oder nicht echt- Diskussion.
Jeder kann sein Format RAW nennen, egal, was da raus kommt.
Wenn man aber die Trennlinie dort zieht, wo De-Bayering noch erforderlich ist, dann macht das etwas mehr Sinn, weil dann davor nur LUminanzdaten liegen und noch kein sichtbares Bild und noch keine Zuordnung zu einem Farbraum.
Bei TIFF hingegen sind beide Bedingungen nicht mehr erfüllt und egal, ob das nun in einer der beiden JPEG Kategorien codiert wird, also mit DCT oder Über eine der lossless Codierungen (Huffmann oder Arithmetik), es ist ein kodiertes Bild.
Man mag das nun als RAW bezeichnen, das steht jeder Firma frei, aber es besteht ein Unterschied zu Material, in dem Du noch ins De-Bayering eingreifen kannst und in dem Du noch den Farbraum selbst bestimmen kannst. (und noch ein paar Sachen).
Wenn als alles hint dem De-Bayering noch RAW ist, dann muss man die Frage stellen, was sind dann die wirklichen Sensordaten ?
Oder anders herum, wo hört dann RAW auf ?
Denn dann könnte man den Spieß natürlich umdrehen und einfach sagen, "dann ist Dein 8Bit JPEG eben auch RAW, nur einwenig schlechter. :-)
Du musst Dir immer anschauen, was Du mit dem Signal noch anstellen kannst (musst) und musst selbst wissen, was für Dich noch RAW ist und was nicht.
Wie gesagt, RAW kann jeder benutzen und auf seine Produkte schreiben, wie er will.
Die Definition liegt bei Dir.
Nur nach meinem Empfinden ist es kein Datensatz mehr, wenn da bereits ein Bildformat codiert ist und Du nicht mal mehr den Farbraum wählen kannst, in dem Du arbeiten möchtest.
Da Huawei offiziell kein DNG für dieses Handy anbietet, glaube ich erst Recht nicht, das dies ein fake Raw ist.
Ich denke die App schafft es es an der richtigen Stelle abzugreifen, wahrscheinlich ähnlich wie Filmic Pro mit ihren 50MBit statt den üblichen 15,
das wird ja auch kein interpolierter nonsense sein, da die quali ja wirklich um einiges besser ist.
Bin zwar kein Fachmann, aber ich verstehe das so, das mash das Tiff Format als Container ansieht und jeder seine Infos reinpackt die er hat, ob bearbeitet oder unbearbeitet.
Zuletzt geändert von klusterdegenerierung am So 21 Aug, 2016 19:58, insgesamt 1-mal geändert.
Nein, DNG ist der Container und Datenkonverter, aus dem hinterher ein TIFF raus kommt, also ein JPEG kodiertes Signal.
Deswegen interessiert es auch nicht, was vor der Konvertierung im Container los war.
TIFF ist präzise als Bildformat spezifiziert.
Da gibt es auch nur im Rahmen der Spezifikation Varianten.
Es wird nur gern bei RAW Konvertierung benutzt, weil es 32Bit pro Farbkanals kann.
Und weil das ja ein Adobe Format ist, werden sie das in SNG schon korrekt benutzt haben.
Aber. das ist eben der Ausgangspunkt. Du vergleichst zwei JPEGs miteinander.
Eines lossless in 12 Bit und eines lossy in 8 Bit, aber beides JPEGs
Dass das erste besser aussieht, steht ja außer Frage... wen wundert's ?
es hat zwar wenig sinn, die ungläbigen dieser welt von ganz simpel einzusehenden wahrheiten überzeugen zu wollen, aber ein bisserl was kann ich hier vielleicht doch noch ganz praktisch demonstrien, damit wesentliches klarerer wird bzw. ein nachweis für die RAW-natur der datei erbracht wird.
man verwende ein paar ganz simple zeilen python, um das bild einzulesen:
#/us/bin/env python
# -*- encoding: utf-8 -*-
import numpy as np
from libtiff import TIFF
import matplotlib.pyplot as plt
tiff = TIFF.open('IMG_20160820_172815_307.dng', mode='r')
ar = tiff.read_image()
print("größe: %s, datentyp: %s" % (ar.shape, ar.dtype))
beim ausführen bekommt man zwar einige "unknown field" fehlermeldungen, weil es sich bei der betreffenden datei um kein ganz normales TIFF handelt, sondern eben um ein DNG, trotzdem kann die libtiff die grundsätzliche struktur richtig deuten und liest ein bild ein.
das programm liefert also die meldung:
größe: (3120, 4160), datentyp: uint16
aus dieser größenangabe bzw. einem array.shape, der nur zwei dimensionen aufweist, kann man bereits ziemlich klar ablesen, das offenbar keine farben im sinne von drei RGB kanälen enthalten sind!
eine weitere interessante untersuchung die man nun anstellen kann, betrifft die tatsächlich genutzten bits der 16bit integer werte. das lässt sich ganz einfach ermitteln, indem man die binärwerte aller bildpunkte mit einem bitwise_or auf ein einzige zahl bzw. deren binäre darstellung reduziert:
auffallend darin ist, dass zwar tatsächlich offenbar eine 12bit darstellung genutzt wird, die beiden letzten stellen aber im ganzen bild nie einen anderen wert als 0 annehmen. man kann also davon ausgehen, dass in wahrheit nur werte mit maximal 10bit auflösung enthalten sind.
um das ganze nun auch noch visuell näher untersuchen zu können, brauchen wir noch zwei weitere einfache zeilen code:
es zeigt ziemlich störende interferenzmuster, weil es eben kein normales graustufenbild ist. wenn man weit genug bis zu den einzelnen pixeln hineinzoomt, erkennt man die ursache: ganz charakteristische schachbrettartige muster, wie sie für derartige RAW daten vor dem debayern typisch sind.
ich hätte es zwar gerne noch ein bisserl hübscher eingefärbt, aber da wird es dann schnell einmal komplizierter...
für denjenigen, der die sache tatsächlich verstehen will, kann man aber vermutlich auch schon an dieser stelle getrost ein:
Q.E.D.
drunter setzten.
EDIT -- noch ein kleiner nachtrag:
die daten, die ich hier form von grauwerten angezeigt habe, kann man natürlich auch als zahlen auflisten
genau die selben werte bzw. raw daten findet man auch direkt im file (im vorliegenden fall zw. 0x6944 und 0x18c8144) in intel typischer little endian anordnung. sie werden also definitiv nicht erst beim öffnen aus einem versteckten JPEG hervorgezaubert!
Zuletzt geändert von mash_gh4 am Mo 22 Aug, 2016 06:43, insgesamt 5-mal geändert.
Hört doch bitte auf euch zu streiten!
Ich würde gerne noch ein DNG aus einer anderen App hochladen, die in keinem Raw Programm eingelesen werden kann und wie ein defektes Bild gezeigt wird.
Vielleicht tauchen ja in diesem DNG ganz andere Werte auf und jemad findet eine Erklärung warum es nicht korrekt angezeigt wird?
klusterdegenerierung hat geschrieben:Hört doch bitte auf euch zu streiten!
ja -- hast eh recht! ;)
mir ist es nur wichtig, dass manchen geschichten, wie man sie ja auch selbst gerne übernimmt und nachplappert, weil man ja nicht allen dingen auf den grund gehen kann bzw. immer auf informationen von außen angewiesen ist, auch tatsächlich klar widersprochen wird, wenn sie einer nähern prüfung nicht standhalten.
aber natürlich ist der soziale friede hier im forum mindestens genauso bedeutsam, da gebe ich dir schon recht.
klusterdegenerierung hat geschrieben:Ich würde gerne noch ein DNG aus einer anderen App hochladen, die in keinem Raw Programm eingelesen werden kann und wie ein defektes Bild gezeigt wird. Vielleicht tauchen ja in diesem DNG ganz andere Werte auf und jemad findet eine Erklärung warum es nicht korrekt angezeigt wird?
das file ist tatsächlich korrupt. ich kann es auch mit anderen raw-bearbeitungswerkzeugen nicht vernünftig darstellen. in vielen punketen hat es mit dem anderen file große ähnlichkeit, nur scheint es im hochformat vorzuliegen -- d.h. die metadaten unterscheiden sich im feld "orientation". was da aber wirklich schief gelaufen ist, kann ich dir aber leider auch nicht sagen. es dürfte jedenfalls ein gröberes problem bei der erstellung des files gegeben haben.
was mir übrigens am rand dieser geschichte noch aufgefallen ist:
ich hab ja oben schon geschrieben, dass es nicht ganz trivial ist, die farbinformation der einzlenen werte auch tatsächlich einer visuellen repräsentation zuzuordnen, wie wir sie normalerweise von bildern gewohnt sind. das liegt u.a. daran, dass die werte der helligkeitsinformation in raw material gewöhnlich in linearer darstellung vorliegen und erst mit einem schwarz- und weißpunkt für jeden kanal und multiplikatoren für den weißabgleich aufbereitet werden müssen, bevor man irgendwas einigermaßen realistisch wirkendes erhält. wenn man die werte ohne diese übersetzung einfach nur als 16bit tiff interpretiert, zeigt sich nur ein ausgesprochen dunkles bild. das ist insofern auch für die praxis relevant, da sich der vorteil der 10bit auflösung durch diese lineare darstellung leider weiter relativiert. in den dunklern passagen bleiben da nicht mehr besonders viele werte über (die meisten fotokameras bieten in ihren raw-files hier deutlich mehr bittiefe). ich glaube also, dass du dich bei der verwendung dieser aufnahmemöglichkeit vorsehen solltest, die bilder tatsächlich sehr korrekt und ggf. mit ein bisserl ETTR aufzunehmen, weil sich ansonsten, auch bei nachträglicher aufbereitung mit leistungsfähiger software außerhalb des handys, ziemlich störende einschränkungen der farbwiedergabe in den dunklen passagen zeigen dürften.
Danke Dir!
Ja das ist mir auch schon aufgefallen.
Bin aber eh ein ETTR Freund und belichte eh eher über als unter.
Natürlich wollte ich damit nicht meine Cam ersetzen, aber wie auch schon CameraRick meinte, ist es klasse wenn man die Möglichkeit hat, mit dem Handy eine "verwertbare" Aufnahme zu realisieren, die nicht immer nur für die Tonne sind, weil sie einfach so minderwertig sind.
Es hat sich über die Jahre ein riesen Ordner Handyfotos angehäuft und bei so manch einem wäre ich froh, wenn es nicht so eine miese JPG Compression hätte und ich zumindest ein bisschen Puffer in der post gehabt hätte.
Ich finde mit Raw macht das ganze mehr Spaß und ist verwertbarer.
klusterdegenerierung hat geschrieben:Es hat sich über die Jahre ein riesen Ordner Handyfotos angehäuft...
mit den RAWs wächst der order halt gleich noch üppiger ;)
ich würde es allerdings, angesichts der betreffenden vorzüge, trotzdem ähnlich halten wie du.
hab jedenfalls gestern aus diesem grund und einer großen portion neugierde auch noch versucht, wie weit sich die betreffenden RAW files verlustfrei komprimieren lassen. mit einer leicht modifizierten fassung des raw2flif-scripts, um auch dieses konkrete raw format zu unterstützen, habe ich dabei folgendes resultat erzielt:
-rw-r--r-- 1 mash mash 25M Aug 21 16:33 IMG_20160820_172815_307.dng
-rw-r--r-- 1 mash mash 6,9M Aug 22 08:09 IMG_20160820_172815_307.flif
das file belegt also nach der entsprechenden komprimierung, trotz völlig gleichem informationsgehalt, nur mehr 27.5% der ursprünglichen größe. da das aber den rechner ganz schön zum schwitzen bingt, kann ich sehr gut nachvollziehen, warum das im handy nicht in gleicher weise genutzt wird. ;)
Oh habe sie schon gelöscht, aber ich meine das war um die 5MB.
Aber jeder App liefert anscheinend eine andere Jpg Compression.
Habe auch eine die mit sogar 9MB abspeichert.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
