Gast_226386
Guest
Ah, ok, via Batch. Das kann natürlich gut klappen (wobei ggf. auch konkurrierende Zugriffe auf die SSD stattfinden sollten). Ich bearbeite jedes Bild individuell - hier funktioniert das leider nicht.
-
In eigener Sache!
Liebe Mitglieder, liebe Besucher und Gäste
ich weiß, es ist ein leidiges Thema, aber ich muss es ansprechen: Werbung, Werbeblocker und Finanzierung des Forums.
Bitte hier weiterlesen ... -
DSLR-Forum Fotowettbewerb neu erfunden!
Nach wochenlanger intensiver Arbeit an der Erneuerung des Formates unseres internen Fotowettbewerbes ist es Frosty als Moderator
und au lait als Programmierer gelungen, unseren Wettbewerb auf ein völlig neues Level zu heben!
Lest hier alle Infos zum DSLR-Forum Fotowettbewerb 2.0
Einen voll funktionsfähigen Demowettbewerb kannst du dir hier ansehen. -
Neuer Partner: AkkuShop.de
Akkus, Ladegeräte und mehr (nicht nur) für Digitalkameras und Drohnen
-
Neuer Gutscheincode unseres Partners Schutzfolien24:
DSLR-Forum2024
Dauerhaft 10% Rabatt auf alle Displayschutzfolien der Eigenmarken "Upscreen", "Brotec", "Savvies".
Der Code ist für alle Geräteklassen gültig. -
Stimmt ab über die Sieger des DSLR-Forum Fotowettbewerbs April 2024.
Thema: "Sprichwörtlich"
Nur noch bis zum 30.04.2024 23:59!
Jeder darf abstimmen!
Zur Abstimmung und Bewertung hier lang
WERBUNG
Ah, ok, via Batch. Das kann natürlich gut klappen (wobei ggf. auch konkurrierende Zugriffe auf die SSD stattfinden sollten). Ich bearbeite jedes Bild individuell - hier funktioniert das leider nicht.
Gast_488590
Guest
Ich bearbeite meine Bilder auch individuell, aber der größte Teil geht vorab schon sehr gut per Batch.
Wenn ich das so lese gibt es für dich wirklich nur 2 Möglichkeiten:
- CPU tauschen + übertakten und zufrieden sein
- nix an der Hardware machen, dann aber still sein, weil du es weißt.
Es bringt nix über die Programmierung von LR zu debattieren. Ja, sie ist schlecht. Aber man muss eine Konsequenz daraus ziehen. Andernfalls verschwendet man Zeit und Nerven.
Deine Hardware ist einfach für LR zu schlecht. Punkt.
Gast_226386
Guest
Auch ein Skylake 7900X mit 128GB und GeForce 1800 Ti ist für LR "zu schlecht", auch wenn er doppelt so schnell wie meine CPU wäre. Die bekannten "Denkpausen" werden auch nach so einem Update weiterhin bestehen und richtig flüssig wird es sich anschließend auch nicht anfühlen. Punkt!
Alles was an Optionen im Raum steht (es gibt weitaus mehr als die beiden) mildern nur die "Problematik" (nicht für jeden ist es eine), oder werfen neue Probleme auf (wie z.B. ein Umstieg auf einen anderen Konverter).
Recht gebe ich dir, dass es müßig ist über Adobe zu nörgeln. Das nutzt seit Jahren nix. und bis sich hier etwas tut dürfte es noch sehr sehr lange dauern...
Ich werde mich wohl zwischen den beiden Kompromissen entscheiden:
- ein X299-Board zulegen und den relativ günstigen 7800X mit 6 Kernen kaufen; dank recht hohem Takt ist er pro Kern kaum langsamer als ein 7700k. Aus meiner Sicht ein guter Kompromiss für Single-Core-Anwendungen, aber auch recht flott bei Multicore (bis auf wenige Ausnahmen in der Regel schneller als ein Ryzen 1800x bei ähnlichem Preis für CPU+Board). Der Energieverbrauch ist niedriger als bei den schnelleren Modellen, aber aus meiner Sicht immer noch zu hoch. Das ist mein Hauptkritikpunkt bei dieser Lösung.
- Wie du gesagt hast: Nix machen und abwarten. Letztendlich sind alle diese "Probleme" reine Luxusprobleme
Zuletzt bearbeitet:
Jap Genau.
Aber bei mir fühlt sich schon alles einigermaßen flüssig an. Der Wechsel zwischen den Modulen geht wirklich in 0,5s... das stört doch nicht.
Vergleichsansicht ist schnell geladen, auch keine 0,5s... und Pinseloperationen sind auch fast Just-in-time.
Ich kann da nicht meckern. Schlimm ist es, wenn es ganze Sekunden dauert - aber so...
Der Export als TIF und die Berechnung eines Fotos dauern halt mal 3s... das ist doch aber normal, rechnen muss er schon etwas.
Vielleicht hast du auch nen krass hohen Anspruch
Auch ein Skylake 7900X mit 128GB und GeForce 1800 Ti ist für LR "zu schlecht", auch wenn er doppelt so schnell wie meine CPU wäre. Die bekannten "Denkpausen" werden auch nach so einem Update weiterhin bestehen und richtig flüssig wird es sich anschließend auch nicht anfühlen. Punkt!
Aber bei mir fühlt sich schon alles einigermaßen flüssig an. Der Wechsel zwischen den Modulen geht wirklich in 0,5s... das stört doch nicht.
Vergleichsansicht ist schnell geladen, auch keine 0,5s... und Pinseloperationen sind auch fast Just-in-time.
Ich kann da nicht meckern. Schlimm ist es, wenn es ganze Sekunden dauert - aber so...
Der Export als TIF und die Berechnung eines Fotos dauern halt mal 3s... das ist doch aber normal, rechnen muss er schon etwas.
Vielleicht hast du auch nen krass hohen Anspruch
Das wurde irgendwann hier auch schon mal im Detail beleuchtet. Die Sache
scheint doch die zu sein dass die Algorithmen die hinter Lightroom stecken nicht
wirklich parallelisierbar sind. Insofern ist da mal so eben nichts zu machen.
Das ist das Problem wenn man ungleiches vergleicht. Die letzten 10% kosten 90% - das ist ein bekanntes Phänomen bei vielen technischen Produkten. Vergleicht man stattdessen gleiches, muss man den i7-7700K mit dem Ryzen 5 1600 vergleichen - die liegen laut Passmark ungefähr gleich auf, der Ryzen liegt sogar mit 12,403 leicht vor dem Intel (getaktet @4,2GHz) mit 12,169.
Und da ist der Intel dann satte 50% teurer als der AMD (325€ vs. 208,-€ boxed). Das ist durchaus ein Hammer.
Da vergleichst Du aber 4 Core gegen 6 Core .... also definitiv nichts "gleiches", zumal hohe Passmark Ergebnisse die durch eine hohe Anzahl an Cores erreicht werden nicht so viel für LR bringen wie weniger Cores die aber schneller arbeiten.
Gast_226386
Guest
Nene
Bild- und Video-Bearbeitungsalgorithmen sind wohl mit die am besten parallelisierbaren Algorithmen überhaupt. Du kannst ein Video-/ ein Bild wunderbar in unabhängige Bereiche unterteilen und diese sepparat in verschiedenen Prozessen/Threads behandeln. Sicherlich nimmt mit der Anzahl der Kerne der Overhead zu, aber generell ist gerade in diesem Bereich eine gute Skalierung der Normalfall.
Man kenn das ja auch von 3D-Render-Software, oder von Systemen mit mehreren 3D-Grafikkarten (bei 2 Karten rendert z.B. die eine Karte die geraden Zeilen, die andere die ungeraden des Bildes).
Problematisch wird es natürlich, wenn ein historisch gewachsener Code mit vielen Querbeziehungen vorliegt und dieser erst mal refactored werden muss; ein Problem vieler großer Softwareprojekte. Aus diesem Grund gibt es bei vielen Softwareprojekten immer mal wieder einen Punkt an dem man "fast" wieder von vorne anfängt, da der alte historisch gewachsene Code kaum noch beherrschbar ist.
Mir scheint es so, als wenn die Entwicklung von Lightroom diesen kritischen Punkt schon länger überschritten hat.
Aber wie gesagt - es hilft ja nichts dieses festzustellen; ändern kann man aus Anwendersicht da eh nichts dran (außer seine Unzufriedenheit durchaus mal dem Hersteller mitzuteilen).
Diese Debatte ist jetzt reichlich sinnfrei geworden. Man kann ein Produkt halt nur nehmen & anwenden. Oder zu was Besserem wechseln.
Und Performance-Probleme hab ich mit LR 6 auf einem 6 Jahre alten System mit CPU Core i5-2500 & 4 GB RAM nicht. Manches könnte fixer gehen, aber störend ist das nicht.
Und Performance-Probleme hab ich mit LR 6 auf einem 6 Jahre alten System mit CPU Core i5-2500 & 4 GB RAM nicht. Manches könnte fixer gehen, aber störend ist das nicht.
Gast_226386
Guest
Wie vieles andere auch ist es wohl eine subjektive Sache ab wann etwas störrt bzw. nicht als Problem angesehen wird. Mich persönlich störrt es, da ich in meinem Bedienfluss deutlich gebremst werde. Andere sind "gemütlicher" unterwegs und verstehen die Kritik nicht.
Nene
Bild- und Video-Bearbeitungsalgorithmen sind wohl mit die am besten parallelisierbaren Algorithmen überhaupt. Du kannst ein Video-/ ein Bild wunderbar in unabhängige Bereiche unterteilen und diese sepparat in verschiedenen Prozessen/Threads behandeln.
Allgemein mag das stimmen, es wurde hier aber schon mal recht detailiert
erläutert weshalb das bei Lightroom nicht so einfach ist.
Darüber hinaus frage ich mich wieso sich nicht endlich einer der vielen Star-
Programmierer die das Forum hier hat mal in der Mittagspause
hinsetzt und bei einer Tasse Kaffee ein neues Lightroom programmiert ...
Gast_226386
Guest
...weil Softwareprojekte in dieser Größenordnung heute nicht mehr von einer Person alleine in der Freizeit gestämmt werden können.
Es gibt viele Menschen, die sich in einem Fachgebiet sehr gut auskennen, ohne selbst aktiv eingreifen zu müssen. Sonst müsste ja auch Joachim Löw demnächst die Tore für Deutschland selbst schießen.
Hallo Dachstein,
es steht dir natürlich frei Leute welche die extremen Leistungszuwächse der letzen Jahre bei Adobe nicht zu finden vermögen als "Starprogrammierer" zu betiteln. Aber diese Kritik steht ja nicht im luftleeren Raum und existiert ja auch nicht erst seit gestern. Es gibt da Softwareprojekte von sehr viel kleineren Firmen als Adobe die in den letzten Jahren Ihre Produkte trotz geringerer Ressourcen konsequent optimiert und so die Geschwindigkeit vervielfacht haben. Wenn Du mal sehen willst wie Leistungssprünge aussehen kannst Du ja mal bei PTGui die Versionen 9 und 10 vergleichen. Gern auch mit alternativen Blendern. Ich denke sowas darf man von einem angeblichen Marktführer wie Adobe durchaus erwarten ...
MfG
Rainmaker
es steht dir natürlich frei Leute welche die extremen Leistungszuwächse der letzen Jahre bei Adobe nicht zu finden vermögen als "Starprogrammierer" zu betiteln. Aber diese Kritik steht ja nicht im luftleeren Raum und existiert ja auch nicht erst seit gestern. Es gibt da Softwareprojekte von sehr viel kleineren Firmen als Adobe die in den letzten Jahren Ihre Produkte trotz geringerer Ressourcen konsequent optimiert und so die Geschwindigkeit vervielfacht haben. Wenn Du mal sehen willst wie Leistungssprünge aussehen kannst Du ja mal bei PTGui die Versionen 9 und 10 vergleichen. Gern auch mit alternativen Blendern. Ich denke sowas darf man von einem angeblichen Marktführer wie Adobe durchaus erwarten ...
MfG
Rainmaker
Gast_212710
Guest
Wird evtl. ein bischen offtopic ...
Wir sollten die Kirche mal im Dorf lassen.
Im bezahlbaren Bereich sind die Leistungszuwächse in den letzten Jahren
eher dürftig wenn man mit den prozentualen Leistungsgewinnen über
einen vergleichbaren Zeitraum vor 10 oder vor 15 Jahren vergleicht.
Man sieht auch, wie im CPU-Entwicklungsbereich die lange gewohnten
Zyklen (Intels Tic/Toc) aus dem Tritt geraten sind.
Bis etwa zur 22nm Technologie und bis etwas oberhalb von 4Ghz liess sich
das bisherige Verfahren, einmal die Architektur verbessern (bei gleicher
Grundtechnologie) und im nächsten Schritt dann eine bessere (kleinere
und schnellere) Grundtechnologie zu nehmen, durchhalten. ... Mit der
Konsequenz, das "Moore's Law" im CPU Bereich funktionierte ... und eben
nicht nur das, es funktionierte sogar dann, wenn man sich allein
die Single-Thread-Performance ansah.
Seit dem, läuft die Entwicklung an einige Grenzen, deren Überwindung
(oder nur deren Verschiebung) extrem teuer ist. Es ist einfacher für die
CPU-Entwickler, dem Problem auszuweichen, und statt dessen für eine
Weile "in die Breite" zu entwickeln ... das heisst mehr Kerne ... ggf.
hierfür nötig verbesserte Wärmeabfuhr. Die Zuwachsorgien bei den
Taktfrequenzen sind jedenfalls in den letzten Jahren praktisch ausgeblieben.
Und wenn man den Leistungszuwachs über ca. 35 Jahre, von einem
4.7Mhz 8088 PC zu einem 4.xGhz Core-i7 ansieht, dann entstammen
die wesentlichen Zugewinne nur ganz wenigen Ursprüngen ...
... allen voran ... die vertausendfachung der Taktfrequenz ...
keine andere Massnahme hat auch nur ansatzweise allein eine ähnliche
Wirkung.
... Registerbreite von 16bit hin zu 64bit (bzw. 128bit je nach Befehlssatz).
... Benötigte Takte pro Befehl (der 8088 benötigte für diverse Befehle
etliche Takte ... das passiert heute praktisch gar nicht mehr).
... Durchsatz beim Speicherzugriff (die Beschränkung der Datenleitungen
beim 8088 im Vergleich zum 8086, hat diese CPU allein ca. 40% Leistung
gekostet).
... Verfügbarkeit und Effizienz von Cache, Diverse interne Spiele wie
Branch-prediction etc.
Nur ... das Schwergewicht in dieser Folge von Dingen ... nämlich die
Steigerungsfähigkeit bei der Taktfrequenz ist seit einiger Zeit praktisch
ausgeschöpft ... und damit sind die erreichbaren Single-Thread-Gewinne
nur noch sehr mager.
Wenn man ein Programm neu entwickelt, und man von vornherein konsequent
darauf setzt alles (aber auch wirklich alles) zu parallelisieren was sinnvoll geht,
dann gewinnt ein Programm auch durch den Zuwachs an Kernen.
Tut man das nicht, oder entstammt viel Programmcode aus einer Zeit,
in der die entsprechende Unterstützung in der Entwicklungsumgebung fehlte
man es also entweder sein lies, oder sich vieles selber schnitzen musste),
dann schaut es anders aus. Dann geht man erstmal die schlimmsten
Baustellen an (z.B. bei Lightroom die Batch-Entwicklung) ... und lässt die
anderen Stellen (die für sich genommen auch jeweils weniger bringen) sein.
Insofern kann man Lightroom bestenfalls den Vorwurf machen, dass es
einerseits bereits "zu alt" ist, und dass es andererseits seine Resourcen
in die Unterstützung neuer Kameras steckte (statt die Kameras zu ignorieren
und stattessen das Programm den sich abzeichnenden Änderung der
Hardware (Multicore-CPUs) anzupassen). En Programm verdient durch
Verkäufe sein Geld ... ein Teil davon kann in Wartung und Erweiterung
reinvestiert werden ... dauerhaft mehr als das zu investieren kann
sich keine Firma leisten.
Fakt ist, dass Lightroom in der Bearbeitung des einzelnen Bildes durch
die vielen Kerne praktisch keinen Gewinn hat, und nur schneller würde,
wenn die Single-Thread-Performance deutlich steigt.
Fakt ist auch, dass die Raw-Dateien moderner Kameras allein durch die
derzeit noch möglichen Steigerungen der Pixelzahl Programme wie
Lightroom vor immer grössere Probleme stellen. Über kurz oder lang, werden
also entweder die grossen Raw-Dateien nicht mehr sinnvoll bearbeitbar sein
(jedenfalls nicht in grösserer Zahl), oder es wird jemand Geld und
Entwicklungskapazität in die Hand nehmen, weil er einen Markt sieht.
Wir sollten die Kirche mal im Dorf lassen.
Im bezahlbaren Bereich sind die Leistungszuwächse in den letzten Jahren
eher dürftig wenn man mit den prozentualen Leistungsgewinnen über
einen vergleichbaren Zeitraum vor 10 oder vor 15 Jahren vergleicht.
Man sieht auch, wie im CPU-Entwicklungsbereich die lange gewohnten
Zyklen (Intels Tic/Toc) aus dem Tritt geraten sind.
Bis etwa zur 22nm Technologie und bis etwas oberhalb von 4Ghz liess sich
das bisherige Verfahren, einmal die Architektur verbessern (bei gleicher
Grundtechnologie) und im nächsten Schritt dann eine bessere (kleinere
und schnellere) Grundtechnologie zu nehmen, durchhalten. ... Mit der
Konsequenz, das "Moore's Law" im CPU Bereich funktionierte ... und eben
nicht nur das, es funktionierte sogar dann, wenn man sich allein
die Single-Thread-Performance ansah.
Seit dem, läuft die Entwicklung an einige Grenzen, deren Überwindung
(oder nur deren Verschiebung) extrem teuer ist. Es ist einfacher für die
CPU-Entwickler, dem Problem auszuweichen, und statt dessen für eine
Weile "in die Breite" zu entwickeln ... das heisst mehr Kerne ... ggf.
hierfür nötig verbesserte Wärmeabfuhr. Die Zuwachsorgien bei den
Taktfrequenzen sind jedenfalls in den letzten Jahren praktisch ausgeblieben.
Und wenn man den Leistungszuwachs über ca. 35 Jahre, von einem
4.7Mhz 8088 PC zu einem 4.xGhz Core-i7 ansieht, dann entstammen
die wesentlichen Zugewinne nur ganz wenigen Ursprüngen ...
... allen voran ... die vertausendfachung der Taktfrequenz ...
keine andere Massnahme hat auch nur ansatzweise allein eine ähnliche
Wirkung.
... Registerbreite von 16bit hin zu 64bit (bzw. 128bit je nach Befehlssatz).
... Benötigte Takte pro Befehl (der 8088 benötigte für diverse Befehle
etliche Takte ... das passiert heute praktisch gar nicht mehr).
... Durchsatz beim Speicherzugriff (die Beschränkung der Datenleitungen
beim 8088 im Vergleich zum 8086, hat diese CPU allein ca. 40% Leistung
gekostet).
... Verfügbarkeit und Effizienz von Cache, Diverse interne Spiele wie
Branch-prediction etc.
Nur ... das Schwergewicht in dieser Folge von Dingen ... nämlich die
Steigerungsfähigkeit bei der Taktfrequenz ist seit einiger Zeit praktisch
ausgeschöpft ... und damit sind die erreichbaren Single-Thread-Gewinne
nur noch sehr mager.
Wenn man ein Programm neu entwickelt, und man von vornherein konsequent
darauf setzt alles (aber auch wirklich alles) zu parallelisieren was sinnvoll geht,
dann gewinnt ein Programm auch durch den Zuwachs an Kernen.
Tut man das nicht, oder entstammt viel Programmcode aus einer Zeit,
in der die entsprechende Unterstützung in der Entwicklungsumgebung fehlte
man es also entweder sein lies, oder sich vieles selber schnitzen musste),
dann schaut es anders aus. Dann geht man erstmal die schlimmsten
Baustellen an (z.B. bei Lightroom die Batch-Entwicklung) ... und lässt die
anderen Stellen (die für sich genommen auch jeweils weniger bringen) sein.
Insofern kann man Lightroom bestenfalls den Vorwurf machen, dass es
einerseits bereits "zu alt" ist, und dass es andererseits seine Resourcen
in die Unterstützung neuer Kameras steckte (statt die Kameras zu ignorieren
und stattessen das Programm den sich abzeichnenden Änderung der
Hardware (Multicore-CPUs) anzupassen). En Programm verdient durch
Verkäufe sein Geld ... ein Teil davon kann in Wartung und Erweiterung
reinvestiert werden ... dauerhaft mehr als das zu investieren kann
sich keine Firma leisten.
Fakt ist, dass Lightroom in der Bearbeitung des einzelnen Bildes durch
die vielen Kerne praktisch keinen Gewinn hat, und nur schneller würde,
wenn die Single-Thread-Performance deutlich steigt.
Fakt ist auch, dass die Raw-Dateien moderner Kameras allein durch die
derzeit noch möglichen Steigerungen der Pixelzahl Programme wie
Lightroom vor immer grössere Probleme stellen. Über kurz oder lang, werden
also entweder die grossen Raw-Dateien nicht mehr sinnvoll bearbeitbar sein
(jedenfalls nicht in grösserer Zahl), oder es wird jemand Geld und
Entwicklungskapazität in die Hand nehmen, weil er einen Markt sieht.
Zuletzt bearbeitet:
Hallo,
ich dachte die Verbindung aus extremen Leistungszuwächsen und Adobe wäre leicht als Ironie zu erkennen gewesen. O.K., nächstes mal hänge ich ein dickes Schild dran.
MfG
Rainmaker
ich dachte die Verbindung aus extremen Leistungszuwächsen und Adobe wäre leicht als Ironie zu erkennen gewesen.
O.K., nächstes mal hänge ich ein dickes Schild dran. MfG
Rainmaker
Gast_212710
Guest
ich dachte die Verbindung aus extremen Leistungszuwächsen und Adobe wäre leicht als Ironie zu erkennen gewesen.
Oh ... dann bin ich dir quasi auf den Leim gegangen ...
ja, in der Tat, ein Ironiemarkierer hätte mir etwas Tipperei erspart ...
aber schadet ja nix ... ;-)
Also irgendwie hab ich Mühe damit das alles hier nachzuvollziehen. Gerade z.B. beim Batch Export von Bildern sehe ich wie im Activity Monitor alle 6 Kerne (mehr hab ich leider nicht) meines Rechners ausgelastet werden teilweise sogar mit Hyperthreading. Hier wird also ganz ordentlich parallelisiert. Vielleicht hab ich auch Glück und es skaliert erst ab mehr als 6 Kernen nicht mehr richtig.
Auch beim normalen bearbeiten kann ich den beobachten wie die CPU Auslastung hochschnellt auf Werte die deutlich mehr als einen Kern auslasten und es ist absolut flüssig.
Das exportieren von 45 D810 RAWs (von der SSD auf die SSD) dauert knapp ~ 90 Sekunden und lastet dabei alle Kerne ordentlich aus.
Dabei ist meine Kiste dreieinhalb Jahre alt und mit einem UHD Monitor. Irgendwas mach ich falsch ...
Sam
Auch beim normalen bearbeiten kann ich den beobachten wie die CPU Auslastung hochschnellt auf Werte die deutlich mehr als einen Kern auslasten und es ist absolut flüssig.
Das exportieren von 45 D810 RAWs (von der SSD auf die SSD) dauert knapp ~ 90 Sekunden und lastet dabei alle Kerne ordentlich aus.
Dabei ist meine Kiste dreieinhalb Jahre alt und mit einem UHD Monitor. Irgendwas mach ich falsch ...
Sam
Gast_488590
Guest
Und wenn man mal 450 RAWs konvertiert? Dann klaut man dem Batchprozess einfach mal 1-2 Kerne und kann parallel noch etwas andere machen.
Ich nutze diese Zeit z.B. um parallel die Verträge zu tippen, ohne dass ich in Word ausgebremst werde.
WERBUNG