Viele Mega-Pixel neuer Laptop ?

[Wolfsteff]

Werbung (verschwindet nach Registrierung)

Hallo ,

 

könnte günstig eine A 7 R III bekommen und habe eine Frage zur Bildbearbeitung bzw. Croppen usw.

Ich fotografiere (bisher) nur in JPEG mit der A 7 IV ( 200-600,  neu :Sigmar 2.8 105 Macro) und sichte Bilder überwiegend über das Window 10 Programm, bearbeite mal heller oder dunkler oder leicht nachschärfen bzw. Ausschnitte. Komme so eigentlich damit gut zurecht.

Mein Laptop: ist von 12/20 mit 8 GB RAM.

Kann ich die höhere Auflösung bzw. den - mir wichtigen - Croppeffekt damit nutzen ?

Danke für Antworten.

Gruss Wolfgang

 

[Octane]

Willkommen im Forum,

vor 3 Stunden schrieb Wolfsteff:

Mein Laptop: ist von 12/20 mit 8 GB RAM.

Das sagt jetzt nicht sonderlich viel aus. Welcher Prozessor ist drin?  8 GB ist für Adobe Lightroom sicher zuwenig. Wie das ist mit Jpg Bearbeitung weiss ich nicht. Das mache ich nicht.

Ich denke nicht dass die A7RIII dir etwas bringt, wenn du nur jpgs bearbeitest. Das ist doch Perlen vor die Säue geworfen. Bei jedem Croppen von jpgs verlierst du Bildqualität. 

bearbeitet 17. August 2022 von Octane

[Wolfsteff]

Danke.

Intel(R) Core(TM)i3 -10111OU CPU (@) 2.10GGHZ ,2.59 GHZ, 64 BiT System.

Glaube ja auch nicht, dass es mehr bringt. Hab heute mal Vergleichsaufnahmen gemacht (JPG). Sehe eigentlich keinen Unterschied.

Die 9 MGP mehr gegenüber der A 7 IV machen den Kohl wohl  nicht fett. Ich dachte eben nur, dass ich auch bei JPG doch mehr Cropp mit weniger Verlust hätte.

Könnte wohl auch -wie ich gedacht habe- an meinem "veraltetem" System (Laptob) liegen.

[wasabi65]

Es tönt ja so als würdest du mit jpg arbeiten, das sollte viel weniger aufwendig sein als raws und alle halbewegs modernen PCs schaffen das (ich habe bis vor Kurzem meine raws mit LrC auf einem 10 Jahre alten i7 bearbeitet...).

Für LrC spielt (so wie die Software zur Zeit gestrickt ist) am meisten der Prozessortakt eine Rolle weil LrC nicht viele Prozesse hat die auf parallele Cores aublaufen können (guck Mal hier: Recommended PC Hardware for Adobe Lightroom Classic in 2022 (pugetsystems.com)).

RAM möglichst bei 16 GB oder mehr (je nach Betriebssystem) und SDD sehe ich als Pflicht. Bei einem Laptop ist Display Grösse (wäre mir meist zu klein bei tragbaren Geräten) und Farbwiedergabe (sRGB möglichst ganz abdecken, matt vs glänzend) fast wichtiger für mich.

 

[Octane]

vor 35 Minuten schrieb Wolfsteff:

Ich dachte eben nur, dass ich auch bei JPG doch mehr Cropp mit weniger Verlust hätte.

Mach RAW Dateien und bearbeite die. Alles andere bringt meiner Meinung nach nichts und ist nur Geld zum Fenster rausgeworfen. 

Ein Notebook von 2020 ist nicht veraltet aber das hier:

vor 35 Minuten schrieb Wolfsteff:

Intel(R) Core(TM)i3 -10111OU CPU (@) 2.10GGHZ ,2.59 GHZ, 64 BiT System

ist halt eine langsame CPU für Büro PCs.  Mein Bildbearbeitungsrechner ist von 2019 aber den habe ich damals mit einer Achtkern Core i7 CPU ausgerüstet. Der ist immer noch schnell genug. Und 32 GB Ram und drei SSDs. Die erste für das Betriebssystem, die zweite für den Lightroom Katalog und die aktuellsten Bilder und die dritte für das Archiv ( 8TB).

Wenn das bis jetzt für die 33 MP der A7IV funktioniert hat mit den jpgs wirds auch mit den 42 MP jpgs funktionieren.

bearbeitet 17. August 2022 von Octane

[n8igall]

Ich denke, der Crop-verlust bei JPG hält sich in Grenzen, wenn das initiale JPG mit hoher Qualität komprimiert wurde und nicht mehrmals gecroppt wird (also _nicht_ gecropptes Bild nochmal croppen).

Bei JPG geht vor allem der Dynamikumfang flöten.

[wasabi65]

Werbung (verschwindet nach Registrierung)

vor 10 Stunden schrieb n8igall:

JPG hält sich in Grenzen,

…kommt auf den Editor an. Gewisse kodieren das jpg bei jedem Sichern neu und damit entstehen immer neue Kompressionsverluste.

[n8igall]

Das verstehe ich jetzt nicht.

Crop von Crop ist schlecht, das hatte ich ja geschrieben. Wenn man nicht Crop von Crop macht, was wird dann neu kodiert? Geschweige denn, akkumuliert?

Auf deinen Kommentar hin habe ich den JPG Wikipedia Eintrag überflogen.

Im Speicher der Programme wird das Bild unkomprimiert gehalten und bei Speichern und beim Lesen wird es durch eine JPG-Engine gejagt. Es können je nach Implementierung tatsächlich Verluste bei Einlesen-Speichern-Einlesen auftreten. Und insbesondere können wohl prinzipiell, je nach Operation, Verluste auftreten auch bei guten Implementierungen. Als Beispiel wurde hier "Einlesen - 90 Grad Rotieren -  Schreiben - Einlesen - 270 Grad Rotieren - Schreiben", was ja eigentlich verlustfrei sein sollte, aber bei ungünstigen Bilddimensionen wohl nicht ist (nicht Vielfaches von JPG Blöcken).

Ich bleibe aber dabei: Wenn eine JPG Datei A.jpg, die mit hoher Qualität erzeugt wurde, eingelesen wird, gecroppt wird und dann mit hoher Qualität in B.jpg gespeichert wird und dann ein anderer Crop erwünscht ist, und Datei A.jpg erneut eingelesen wird, gecroppt und dann Datei C.jpg geschrieben, dann hält sich der Verlust von B.jpg und C.jpg in Grenzen. Der Einlesen-Vorgang (inklusive JPG-Engine) ist ja deterministisch. Anders würde es sich verhalten, wenn für C nicht A sondern B eingeladen werden würde (Crop von Crop).

[Wolfsteff]

Hallo zusammen,

 

zunächst vielen Dank für Eure Gedanken dazu.

Da ich bisher nur mit JPG arbeite und mit meiner "Ausbeute" zufrieden war ( Obwohl  meine RAW-Foto Kollegen hier in unserem Gelände immer überzeugende Argumente pro RAW bringen) konnte ich mich bisher noch nicht durchringen.

Eure o.a. Ausführungen zu Crop usw. mit den Hintergründen dazu sind interessant jedoch auch aus meiner Sicht kompliziert.

Dachte einfach nur über die R III mehr Crop- Möglichkeiten zu haben ( ohne Einbußen) und hab mir das tatsächlich in Bezug auf die notwendige Hardware einfacher vorgestellt (aber bereits geahnt).

"Schuster bleib bei Deinen Leisten"

Vielen Dank und lieben Gruß

 

PS: hätte die A 7 R III mit dem Sigmar 2.8 105 und dem Sony 24-105 4 verwendet.

[Octane]

vor 55 Minuten schrieb Wolfsteff:

PS: hätte die A 7 R III mit dem Sigmar 2.8 105 und dem Sony 24-105 4 verwendet.

Passt schon auch wenn Sigma vom griechischen Buchstaben und nicht vom männlichen Vornamen "Sigmar" kommt 😁

 

vor 55 Minuten schrieb Wolfsteff:

Dachte einfach nur über die R III mehr Crop- Möglichkeiten zu haben ( ohne Einbußen) und hab mir das tatsächlich in Bezug auf die notwendige Hardware einfacher vorgestellt (aber bereits geahnt).

Schade ums Geld und die 7RIII ist deutlich älter als deine 7IV und das merkt man sehr deutlich.  Ich kann dir nur raten auf RAW zu wechseln. 

bearbeitet 18. August 2022 von Octane

[FotoMats]

vor einer Stunde schrieb Wolfsteff:

Dachte einfach nur über die R III mehr Crop- Möglichkeiten zu haben ( ohne Einbußen)...

Ohne Einbußen schafft für mich maximal die R4 mit dem Pixelpitch einer X-T4 und GFX 100s.

[wasabi65]

vor 7 Stunden schrieb Wolfsteff:

Eure o.a. Ausführungen zu Crop usw. mit den Hintergründen dazu sind interessant jedoch auch aus meiner Sicht kompliziert.

Hmmm

vor 7 Stunden schrieb Wolfsteff:

Dachte einfach

…denken ist prinzipiell gut!

vor 7 Stunden schrieb Wolfsteff:

Schuster bleib bei Deinen Leisten"

…als ich mit Fotografie begonnen habe, kam mir vieles Spanisch vor und ich musste mich einlesen, bzw in Forum Fragen stellen. Wenn mir das damals zu kompliziert geblieben wäre, hätte ich nie dazugelernt. Und meine Fotos hätten sich nicht weiter verbessert. Das wäre für die Menschheit kein Verlust gewesen, aber für mich schon.

[wasabi65]

vor 11 Stunden schrieb n8igall:

Es können je nach Implementierung tatsächlich Verluste bei Einlesen-Speichern-Einlesen auftreten. Und insbesondere können wohl prinzipiell, je nach Operation, Verluste auftreten auch bei guten Implementierungen. Als Beispiel wurde hier "Einlesen - 90 Grad Rotieren -  Schreiben - Einlesen - 270 Grad Rotieren - Schreiben", was ja eigentlich verlustfrei sein sollte, aber bei ungünstigen Bilddimensionen wohl nicht ist

Genau darum geht es. Gewisse Programme (ich denke das meinst du mit Implementierung) rechnen das jpg neu, selbst bei einer Drehung oder ähnlichen Operation, von der User denken, diese sei „verlustlos“.

[n8igall]

Ich bin mir nicht sicher, ob wir vielleicht doch aneinander vorbeireden... Was meinst du mit "neu rechnen" ?

Das Bild wird im Hauptspeicher sicher nicht "als JPG" gehalten. Das wird als zweidimensionaler Array von Pixeln bestimmter Bittiefe gehalten. Wenn das Bild im Hauptspeicher um 90 Grad gedreht wird und zurück, tritt kein Verlust auf.

Anders sieht es aus, wenn andere Drehwinkel verwendet werden (z.B. 36x um 10 Grad). Hier treten durch die unvermeidliche Interpolation sicher Verluste auf. Aber das hat mit JPG nichts zu tun.

JPG Verluste treten beim Speichern auf. Zum einen gewollt, weil verlustbehaftete Kompression, zum anderen wohl durch Rundungsfehler bei der Kosinustransformation. Soweit ich das verstanden habe, gibt es gute Implementationen, die Rundungsfehler so im Griff haben, dass sich keine Fehler bei wiederholtem Lesen und Schreiben aufschaukeln.

bearbeitet 19. August 2022 von n8igall
"Bild" statt "Programm"

[wasabi65]

vor 9 Stunden schrieb n8igall:

, tritt kein Verlust auf.

 

Versuch Mal danach zu Googeln. Wir hatten das irgendwo diskutiert und auch gestestet. Es gibt durchaus Software, die so ein Bild neu rechnet beim sichern (damit meinen wir wohl das selbe, siehe deinen zweiten Abschnitt). Will sagen - sichern auch bei 100 % Qualität beinhaltet Kompressionsartefakte die vorher nicht da waren. Kann es im Moment nicht finden.

vor 9 Stunden schrieb n8igall:

Soweit ich das verstanden habe, gibt es gute Implementatione

Aber auch schlechte.

bearbeitet 19. August 2022 von wasabi65

[n8igall]

Dann sind wir ja einer Meinung, beim Sichern wird verlustbehaftete komprimiert natürlich. Das gilt aber unabhängig von der Implementierung. JPG hat immer Kompressionsartefakte. Außer JPG 2000. Da gibt es auch eine verlustfreie Variante.

bearbeitet 19. August 2022 von n8igall

[wasabi65]

vor 4 Stunden schrieb n8igall:

Das gilt aber unabhängig von der Implementierung

Jein, ich dachte bei dem erwähnten Test hätte es Software gegeben, wo das (bei 100 % Qualität) nicht sichtbar war. Aber eben, ich finde es nicht mehr und mehr Zeit zu Thema möchte ich nicht aufwenden, weil für mich irrelevant.