Capture NX

Thread Status
Hello, There was no answer in this thread for more than 30 days.
It can take a long time to get an up-to-date response or contact with relevant users.
habe auch lange herumgebastelt : der goldene tipp kam von einem profi
aus wien : m a c (windows mit nx2 ist und bleibt eine lahme ente !!)

hans

Am MAC geht NX2 auf einmal viel schneller?
Erstaunlich, was ein Betriebsystem für Auswirkungen auf den Algorithmus eines Programmes haben soll.
BTW, auf (m)einer lahmen Vista Kiste dauert das Öffnen und das Speichern einer D3 NEF Datei jeweils ca. 1-2 Sekunden.

Have fun with your Mac.

LG, Andy
 
Kommentar
Anzeigen
Am MAC geht NX2 auf einmal viel schneller?
Erstaunlich, was ein Betriebsystem für Auswirkungen auf den Algorithmus eines Programmes haben soll.

Was ist daran so erstaunlich? Du vergleichst hier Äpfel mit Birnen. Auf dem Mac funktioniert die Speicherverwaltung völlig anders und damit auch die zugrunde liegenden Routinen im Programm. Die gleiche Software lässt sich, außer durch reine Messwerte (diese Aktion dauert auf dem und dem System so und so lange) die aber tatsächlich auch nicht viel aussagen, auf unterschiedlichen Systemen überhaupt nicht vergleichen. Es ist ein Trugschluß zu glauben, nur weil eine Programm auf dem PC und dem Mac die gleiche Versionsnummer trägt, es gäbe hier keine Unterschiede. Tatsächlich ist nur ein geringer Teil der Software identisch, ansonsten handelt es sich um völlig eigenständige Parallelentwicklungen. Sehr zum Leidwesen der Mac-User, denn auf Grund der weiteren Verbreitung von Windows-PCs hängt die Mac-Version oft geraume Zeit hinterher, weil die Hersteller sich zuerst auf das System konzentrieren, wo sich erst mal mehr verkaufen lässt. Aber noch mal, die Software ist zwar auf dem PC und dem Mac die Gleiche, aber nicht die Selbe. Auf dem Mac gibt es keine EXEn, DLLs oder gar ein .net-Framework. Die Integration der Anwendungen ins System ist hier viel weiter fortgeschritten, was von Vornherein einge Flaschenhälse gar nicht erst entstehen lässt.

Übrigens ist genau die Speicherverwaltung auf dem Windows-PC der Knackpunkt für Capture NX. Capture NX allokiert während der Verarbeitung unter Windows immer mehr Speicher, ohne diesen vollständig wieder frei zu geben. In Folge läuft während der Berabeitung größerer Bildmengen der Speicher immer mehr voll und das Programm wird immer langsamer. Zu guter Letzt stürzt Capture NX dann auch schon mal gerne ab. Mac OS X lässt ein solches Verhalten gar nicht erst zu. Daher läuft NX auch nach längerer Arbeitszeit immer noch sehr performant. Ich kann mir für Capture NX einen Highend-PC unter oder einen Mac auf den Tisch stellen. Ich habe beides, und arbeite inzwischen in der Bildbearbeitung nur noch am Mac. Denn auch die teilweise merkwürdigen Stockungen von Capture NX beim Aufruf und der Ausführung rechenintensiver Programmteile gibt es am Mac nicht. Hier macht Bildbearbeitung sogar mit Capture NX Spaß.

Unter Windows gibt es mehrere Möglichkeiten, Capture NX (2) zumindest merklich zu beschleunigen. Nicht jeder hat 64-Bit Hardware, deshalb lasse ich den Wechsel zu einem 64-Bit Windows mal außen vor. Die Wichtigste Maßnahme ist maximaler Ausbau des physikalischen Speichers. Achtung, bei einem 32-Bit Windows-System sind das 3 GB. Mehr kann unter XP 32 oder Vista 32 zu unerklärlichen Abstürzen führen. Das System kann einfach nicht mehr addressieren. Und die zweite Möglichkeit, die zu einer merklichen Beschleunigung von Capture NX (2) führt ist, soweit möglich, der Einbau einer zweiten Festplatte in den PC und die Auslagerung des Caches von Capture NX auf diese. Aber Achtung, keine externe USB-Festplatte verwenden! Diese wirkt auf Grund der eher bescheidenen Leistung der USB-Schnittstellen eher kontraproduktiv. Wenn extern, dann nur, sofern der PC dies anbietet, eine eSATA-Platte. Viel mehr kann man an seinem alten Rechner für Capture NX nicht tun. Die Alternative sind nur der Kauf eines sehr gut ausgestatteten, schnellen QuadCore-Systemes mit 64 Bit Windows und RAM satt oder der Kauf eines Mac.

Ich selbst habe mich für Letzteres entschieden. Rückblickend hätte ich keine bessere Entscheidung treffen können.

Übrigens, auch andere Programme profitieren vom Mac. Ein extremes Beispiel ist z.B. DXO Optics Pro. Ich habe direkt PC (Quadcore) und iMac (Core2Duo) gegeneinander mit DXO antreten lassen. Während DXO auf dem PC noch lustig vor sich hin startet, habe ich auf dem Mac bereits das Projekt im DXO erstellt und angefangen, die ersten Bilder zu bearbeiten.

Gruß Steffen

PS: Capture NX läuft bereits auf meinem QuadCore PC mit Vista Ultimate 32 und 3 GB RAm recht zügig, gerät aber bereits bei kleineren Aktionen wie Kontrast, Lichter und Schatten zunehmend ins Stocken. Mit zunehmender Anzahl der verarbeiteten Bilder (D300 RAW verlustfrei komprimiert, 14 Bit) nimmt die Performance zudem rasch ab und das Arbeiten wird zäh. Solch ein Verhalten gibt es auf dem Mac nicht.
 
Kommentar
Ich hab seit geraumer Zeit auch einen MacPro, allerdings mit nur 2GB Arbeitsspeicher (wird demnächst aufgerüstet) und CNX läuft darauf sehr schleppende mit langen Pausen. Ist das bei CNX2 besser?

Martin
 
Kommentar
Steffen,
danke für deine ausführliche Antwort.

Sie entbehrt leider zum größten Teil einer faktischen Basis.

  • Die OS/X Speicherverwaltung basiert auf einer klassischen Unix Architektur - nothing special here. Apple Memory Verwaltung
  • Deiner Darstellung nach ist Capture NX2 für den Mac ein eigenständiges Programm, daß besser mit OS/X zusammenarbeitet - laut meinen Tests ist es genau umgekehrt. Aufgrund der höheren Stückzahlen im Windows Kundensegment kann Nikon mehr Entwicklerresourcen in die bessere Optimierung der Windowsversion stecken. Daten: Siehe unten
  • EXE und DLL gibt es im Unix zwar als Namen nicht, jedoch als Konzept - executables und shared libraries.
  • Die 3GB Grenze ist genaugenommen 3,25 GB und wird von der HW Architektur der üblichen Motherboards vorgegeben. (Schlagwort: Memory mapped I/O)
Zur überlegenen Geschwindigkeit von NX2 und OS/X konnte ich es diesmal nicht lassen und bin der Sache nachgegangen.

Ich habe auf meinem gut ausgestatteten MacPro (8x3Ghz Xeon, 32 GB RAM) auf jeweils einer neuen 160GB Harddisk sowohl OS/X 10.5 und Vista 64 SP1 aufgespielt. Auf beiden Systemen wurden alle Patches eingespielt und die neueste Version von NX2 dazu.

Mittels der Stapelverarbeitung von NX2 wurden aus einem Verzeichnis mit 300 D3 NEFs ein zweites Verzeichnis mit 300 JPEGs (Höchste Qualität) erzeugt.

Laufzeiten:
  • MacPro mit OS/X 10.5 = 18:52min
  • MacPro mit Vista 64 = 9:20min
  • Notebook Dell M6400 mit Windows 7 = 11:05min.

Ergebnis:
Auf gleicher Hardware ist bei dieser Aufgabe NX2 unter Windows ca. doppelt so schnell wie unter OS/X. Abstürze oder sonstige Memoryprobleme gab es bei allen 3 Versionen keine.

Versteh mich nicht falsch, ich möchte Dir die Arbeit mit deinem Mac beileibe nicht ausreden. Andererseits möchte ich Dich ersuchen, mit so einfach aufgestellten Behauptungen in Zukunft sorgfältiger umzugehen.

Auch wenn sie noch so oft wiederholt werden, sie werden dadurch nicht wahrer.

LG, Andy


Was ist daran so erstaunlich? Du vergleichst hier Äpfel mit Birnen. Auf dem Mac funktioniert die Speicherverwaltung völlig anders und damit auch die zugrunde liegenden Routinen im Programm. Die gleiche Software lässt sich, außer durch reine Messwerte (diese Aktion dauert auf dem und dem System so und so lange) die aber tatsächlich auch nicht viel aussagen, auf unterschiedlichen Systemen überhaupt nicht vergleichen.

Es ist ein Trugschluß zu glauben, nur weil eine Programm auf dem PC und dem Mac die gleiche Versionsnummer trägt, es gäbe hier keine Unterschiede. Tatsächlich ist nur ein geringer Teil der Software identisch, ansonsten handelt es sich um völlig eigenständige Parallelentwicklungen. Sehr zum Leidwesen der Mac-User, denn auf Grund der weiteren Verbreitung von Windows-PCs hängt die Mac-Version oft geraume Zeit hinterher, weil die Hersteller sich zuerst auf das System konzentrieren, wo sich erst mal mehr verkaufen lässt. Aber noch mal, die Software ist zwar auf dem PC und dem Mac die Gleiche, aber nicht die Selbe. Auf dem Mac gibt es keine EXEn, DLLs oder gar ein .net-Framework. Die Integration der Anwendungen ins System ist hier viel weiter fortgeschritten, was von Vornherein einge Flaschenhälse gar nicht erst entstehen lässt.

Übrigens ist genau die Speicherverwaltung auf dem Windows-PC der Knackpunkt für Capture NX. Capture NX allokiert während der Verarbeitung unter Windows immer mehr Speicher, ohne diesen vollständig wieder frei zu geben. In Folge läuft während der Berabeitung größerer Bildmengen der Speicher immer mehr voll und das Programm wird immer langsamer. Zu guter Letzt stürzt Capture NX dann auch schon mal gerne ab. Mac OS X lässt ein solches Verhalten gar nicht erst zu. Daher läuft NX auch nach längerer Arbeitszeit immer noch sehr performant. Ich kann mir für Capture NX einen Highend-PC unter oder einen Mac auf den Tisch stellen. Ich habe beides, und arbeite inzwischen in der Bildbearbeitung nur noch am Mac. Denn auch die teilweise merkwürdigen Stockungen von Capture NX beim Aufruf und der Ausführung rechenintensiver Programmteile gibt es am Mac nicht. Hier macht Bildbearbeitung sogar mit Capture NX Spaß.

Unter Windows gibt es mehrere Möglichkeiten, Capture NX (2) zumindest merklich zu beschleunigen. Nicht jeder hat 64-Bit Hardware, deshalb lasse ich den Wechsel zu einem 64-Bit Windows mal außen vor. Die Wichtigste Maßnahme ist maximaler Ausbau des physikalischen Speichers. Achtung, bei einem 32-Bit Windows-System sind das 3 GB. Mehr kann unter XP 32 oder Vista 32 zu unerklärlichen Abstürzen führen. Das System kann einfach nicht mehr addressieren. Und die zweite Möglichkeit, die zu einer merklichen Beschleunigung von Capture NX (2) führt ist, soweit möglich, der Einbau einer zweiten Festplatte in den PC und die Auslagerung des Caches von Capture NX auf diese. Aber Achtung, keine externe USB-Festplatte verwenden! Diese wirkt auf Grund der eher bescheidenen Leistung der USB-Schnittstellen eher kontraproduktiv. Wenn extern, dann nur, sofern der PC dies anbietet, eine eSATA-Platte. Viel mehr kann man an seinem alten Rechner für Capture NX nicht tun. Die Alternative sind nur der Kauf eines sehr gut ausgestatteten, schnellen QuadCore-Systemes mit 64 Bit Windows und RAM satt oder der Kauf eines Mac.

Ich selbst habe mich für Letzteres entschieden. Rückblickend hätte ich keine bessere Entscheidung treffen können.

Übrigens, auch andere Programme profitieren vom Mac. Ein extremes Beispiel ist z.B. DXO Optics Pro. Ich habe direkt PC (Quadcore) und iMac (Core2Duo) gegeneinander mit DXO antreten lassen. Während DXO auf dem PC noch lustig vor sich hin startet, habe ich auf dem Mac bereits das Projekt im DXO erstellt und angefangen, die ersten Bilder zu bearbeiten.

Gruß Steffen

PS: Capture NX läuft bereits auf meinem QuadCore PC mit Vista Ultimate 32 und 3 GB RAm recht zügig, gerät aber bereits bei kleineren Aktionen wie Kontrast, Lichter und Schatten zunehmend ins Stocken. Mit zunehmender Anzahl der verarbeiteten Bilder (D300 RAW verlustfrei komprimiert, 14 Bit) nimmt die Performance zudem rasch ab und das Arbeiten wird zäh. Solch ein Verhalten gibt es auf dem Mac nicht.
 
Kommentar
Hallo Andy,
hast du bei deinem Test nach der Neuinstallation von OS-X die Indizierung durch Spotlight ausgeschaltet und auch TimeMachine für den Test ausgeschaltet?

Grade nach einer Neuinstallation ist der Rechner erst mal sehr zäh wenn die ganze Platte neu indiziert wird und ein parallel laufendes Backup ist auch nicht förderlich.
Parallel dazu ein Benchmark ist für die Tonne.

Ich schätze du hast daran gedacht, wollte nur sicher gehen.

//
Kai
 
Kommentar
Hallo Andy,
hast du bei deinem Test nach der Neuinstallation von OS-X die Indizierung durch Spotlight ausgeschaltet und auch TimeMachine für den Test ausgeschaltet?

Grade nach einer Neuinstallation ist der Rechner erst mal sehr zäh wenn die ganze Platte neu indiziert wird und ein parallel laufendes Backup ist auch nicht förderlich.
Parallel dazu ein Benchmark ist für die Tonne.

Ich schätze du hast daran gedacht, wollte nur sicher gehen.

//
Kai

Servus Kai,
Spotlight war nicht ausgeschalten, Desktop Search bei Vista war auch in Betrieb -es spiegelt den Normalbetrieb wieder.
Ich hatte gestern abends OS/X installiert und über die Nacht laufen lassen. Benchmarks erfolgten heute früh.

LG,Andy
 
Kommentar
Hast du eine Theorie über den signifikanten Unterschied? Ich benutze zwar kein CNX, ich hätte aber geschätzt dass der Unterschied im Rahmen von max. 10-15% liegt.

Ich denke dass die grundlegenden grafischen Algorithmen bei beiden Systemen gleich sind. Die meisten Unterschiede sind wohl im UI Umfeld zu finden.

Selbst wenn beide OS gleichzeitig auf der gleichen Platte installiert wurden (eins innnen, eins aussen) kann ich mir diesen Unterschied nicht erklären.

//
Kai
 
Kommentar
Hast du eine Theorie über den signifikanten Unterschied? Ich benutze zwar kein CNX, ich hätte aber geschätzt dass der Unterschied im Rahmen von max. 10-15% liegt.

Ich denke dass die grundlegenden grafischen Algorithmen bei beiden Systemen gleich sind. Die meisten Unterschiede sind wohl im UI Umfeld zu finden.

Selbst wenn beide OS gleichzeitig auf der gleichen Platte installiert wurden (eins innnen, eins aussen) kann ich mir diesen Unterschied nicht erklären.

//
Kai

Kai,
ich habe 2 x 160 GB Platten verwendet, und sie jeweils neu formatiert bevor die Betriebsysteme draufkamen. Für die vergleichenden Läufe wurde dann das Laufwerk gewechselt - von daher Gleichstand.

Ich habe mir die Ursachen nicht wirklich angesehen, mich hat zuerst einmal die Verifikation/Falsifikation der so oft gehörten Behauptung interessiert.

Was könnte den Unterschied ausmachen?
  • Der wichtigste Unterschied ist aus meiner Sicht, auf welchem System der Entwickler sitzt. Dem Ergebnis nach zu urteilen, sitzen die Nikon Developer vor Windows PC's. Man müßte sich ansehen, wieviel % der Laufzeit das Programm im Betriebsystem zubringt, und wieviel es im eigenen Code "verbrennt".
  • Es würde mich mehr als nur wundern, daß der Unterschied aus einer Ineffizienz von OS/X selbst stammt. Meine Vermutung geht in die Effizienz der unterschiedlichen Supportbibliotheken die das Programm intern verwendet um den Kontakt zur Aussenwelt (Betriebsystem) zu halten. Es hat eine Reihe von architektonischen Veränderungen in den letzten Jahren bei Apple gegeben (Cocoa), die u.U. noch nicht optimal implementiert wurden.(Eine Vermutung)
  • Sollte die Mac Version von CNX auf eine eingebaute JavaVM in OS/X zugreifen, dann ist das für mich die offensichtlichste Erklärung. DotNET ist wesentlich effizienter als alle Java VMs, egal auf welcher Plattform. Die Leistungsunterschiede .NET/Java betragen bis zu 5:1.
  • Ich hoffe, daß die Nikon Entwickler an einer wirklich parallelen zukünftigen Version von CNX arbeiten. Allerdings denke ich, daß der Leistungsunterschied sich dann uU noch mehr zu Gunsten von Windows verlagern wird. Das hat mehrere mögliche Gründe:
  • Für .NET gibt es seit einiger Zeit (ab 4.0 im Standardprodukt) die Task Parallel Library, die dem Entwickler sehr viel (wirklich viel) Arbeit des Parallelisierens abnimmt. Das gängige OpenMP unter Unix ist ungleich schwerer zu beherrschen.
  • Apple hat einen ersten Schritt in Richtung OpenCL getan (kommt auch von Apple) um die Leistung der Grafikkarten dem Benutzer als Rechenleistung zur Verfügung zu stellen - es fehlen nur noch leistungsfähige Grafikkarten im Applesortiment. Die Grafikkartenfreaks in der Windowswelt bauen heute schon Maschinen mit 8 Grafik GPUs und 1920 CPUs für ca. 3000 Euro zusammen. Diese Dinger sind bei manchen Aufgaben wie zBsp in der Computertomographie, Astrophysik oder Bioinformatik schneller als millionen Euro teure Cluster.
  • Es gibt in Betriebsystemen neben den klassischen Betriebsystemthreads noch sogenannte "lightweight" oder "user" threads. In den aktuellen Windowsversionen heißen diese "Fibre" und im Unixumfeld "pthreads". Die "Invokation" (Erzeugung) geht mit pthreads etwas langsamer (ca. 1500 CPU Befehle vs. ca. 3000).
Na ja, ist ein langer Post geworden. Bin mir nicht sicher ob ich Deine Frage überhaupt beantwortet habe :D

LG,
Andy
 
Kommentar
Sicher dass CNX2 auf OS-X in Java programmiert ist? Nunja, das UI sieht so lieblos aus, das könnte schon stimmen.

Eine grafiklastige Software wie CNX mit Java zu entwickeln halte ich für gewagt. Dafür kommt eigentlich nur C/C++ in Frage.
Java hat mich noch in keinem Projekt von der Performance wirklich überzeugt. Das liegt auch teilweise daran, dass die Entwickler sich kaum um das Tuning der VM kümmern. An den Speicherparametern der VM wird erst rumgespielt, wenn das Programm mangels Speicher abstürzt.
Und warum sollte man auf einer Platform Java einsetzen und auf der anderen (auf der Java auch läuft) alles neu entwickeln. Die bessere Performance von .NET mag ein Grund sein, ich glaube aber dass das den Erbsenzählern egal ist. Schliesslich macht Nikon mit Kameras Geld und nicht mit Software.

Wenn immerhin irgendwas parallel gemacht wird ist das schon ein Vorteil gegenüber früher.
Ich habe hier nur CNX 1.3. Wenn ich hier NEF nach JPG konvertiere wird hier im 35s Takt eine Datei nach der anderen ausgespuckt. Der Rechner ist grade mal zur Hälfte ausgelastet. Der könnte locker 2 NEFs parallel konvertieren.

Muss heute abend mal LR testen. Ich meine, dort wird das ganze parallel auf mehrere Threads aufgeteilt.
 
Kommentar
Sicher dass CNX2 auf OS-X in Java programmiert ist? Nunja, das UI sieht so lieblos aus, das könnte schon stimmen.

Kai,
ich habe mir nicht im Detail angesehen, ob CNX2 Java verwendet. Mein Argument war, daß wenn sie Java verwenden, dann wäre das eine Erklärung.

Dein Punkt betreff UI greift im durchgeführten Vergleich nicht, da in diesen 9 - 18 Minuten so gut wie gar nichts am Schirm passiert. Ich denke, daß einige interne Berechnungsalgorithmen sich auf zugekaufte Bibliotheken abstützen.

Zur Parallelisierung:
Was so einfach klingt ist ein großer Aufwand, der tief in die Architektur eingreift. Einfach n x NEF Bilder parallel verarbeiten würde bedeuten, daß das Programm n-Mal in den Hauptspeicher geladen werden muß, vs. 1-mal, wenn es korrekt (multithreaded und re-entrant fähig) entwickelt wurde.

Hier scheint das LR Development Team schon weiter zu sein.

Schliesslich macht Nikon mit Kameras Geld und nicht mit Software.
Diesen Satz würde ich in der Zwischenzeit in Frage stellen. War dir bekannt, daß der 7-er BMW das erste Auto in der Geschichte war, bei dem die SW Entwicklung teurer als die HW Entwicklung war? Würde der Wert der Kamera rein in der HW liegen, könnten alle Kamerahersteller locker die SW als OpenSource hergeben, daß sie es nicht tun, zeigt, daß da viel "Wert" und Wettbewerb drinnensteckt. Wir Kunden sehen die HW, aber der Großteil des Ergebnisses wird durch SW bestimmt.


LG,
Andy
 
Kommentar
-Anzeige-
Zurück
Oben Unten