NikonPoint

Nimm Dir ein Bild und stemple mal "ein Weilchen" im Bild rum. Glaub mir, das ist absolut kein Problem, CNX zum "Abrauchen" zu bringen. Nur ist der Monster-Stempel-Fall jetzt IMO kein Standard-Anwendungsfall.

Nein Klaus, so einfach ist es nicht

Ich hab ja schon mal geschrieben, daß ich jahrelang die betroffenen Nutzer für Idioten gehalten habe, weil mein NX2 grundsolide gearbeitet hat - bis es mich wie aus heiterem Himmel nach einer Neuinstallation selber betraf

Allerdings hatte ich das Glück, dass es nach einer erneuten Runde installieren genau so schnell wieder verschwunden ist. Seitdem seh ich die armen Kerle mit anderen Augen, denn viele von denen haben ihr System schon mehrfach neu aufgesetzt und werden den Fehler nicht los.

Es gibt irgendwelche Randbedingungen, die den begünstigen und die bei manchen halt immer auftreten, sodaß man den Fehler nicht wieder los wird Ich habe da massiv .NET als ursächlich mit beteiligte Komponente in Verdacht, weil das in x-Versionen und von y Programmen wild angepaßt/upgedates auf die Platte geschaufelt wird.

@Timo: Wie wäre es mal mit einem Link auf eine Einstellungsdatei, die bei Dir totsicher den Fehler zu 100% hervor ruft. Du könntest statt der Datei ja vorher schnell noch die Bearbeitungen in einer Einstellungsdatei speichern und die Leutchen können das hier mal schnell auf ihr(e) Bild(er) loslassen. Daß da EBV-technisch Quatsch raus kommt, dürfte ja egal sein (oder Du gibst ein Set NEF+Einstellungsdatei raus)... nur mal damit mehr Leute probieren können und so bekommst Du vielleicht mehr Mitstreiter.

Hm, ohne Öl ins Feuer gießen zu wollen: Ich vermute ganz stark, dass es am Speichermanagement von Windows und einem wohl sehr verschwenderischen Umgang von CNX2 mit selbigem Speicher liegt. Standardmäßig bekommen Programme unter Windows 32Bit max 2GB zugewiesen. Durch längeres Arbeiten scheint das Programm sich immer mehr Speicher zu gönnen, bis nichts mehr geht. Dass das beim Speichern auftritt, lässt bei mir die Vermutung wachsen, dass CNX2 beim Speichern eine von nicht speicherungswürdigen Zwischenschritten bereinigte Kopie der Daten im verwendeten Speicher anlegt, um diese dann zu sichern. Der Speicher reicht dann nicht mehr aus. Das würde bei mir auch erklären, warum sich bei Nick nichts tut. Das ist ein großer Designbug in der Software und lässt sich nicht so einfach beseitigen. Viel Vermutungen, von den Indizien gestützt. Wie es wirklich aussieht, weiß ich auch nicht. Aber nur so kann ich mir das erklären.

Edit: mal das probiert: http://www.administrator.de/index.php?content=21084
? Das sollte das Problem zumindest herauszögern.

Ich habe gestern Abend etwa 10 Anwendungsschritte laufen lassen mit Tonwert/Kontrast Korrekturen und Masken und alles moegliche bis das Bild total verunstaltet war, NX2 hat aber problemlos funktioniert. Gestempelt habe ich gestern nicht, aber das mache ich sonst selber ab und an, auch mehrfache Stempel.

Deswegen habe ich ja auch geschrieben, Timo solle mal genau beschreiben was er macht. Und dazu vielleicht mal ein NEF zur Verfuegung stellen.

Ich glaube auch dass es am .NET liegt und nicht direkt an NX selber. Vielleicht verwenden die Adobe Programme das nicht und zeigen u.a. deswegen solche Probleme nicht.

Ist es wirklich so, dass manche Applikationen am .NET Hand anlegen und da irgendwelche Teile austauschen und durch eigene ersetzen?
Falls ja, waere das natuerlich fatal. Dann darf man in Prinzip nur eine Anwendung auf dem Rechner haben die .NET verwendet.

vdaiker hat geschrieben: Ist es wirklich so, dass manche Applikationen am .NET Hand anlegen und da irgendwelche Teile austauschen und durch eigene ersetzen?
Falls ja, waere das natuerlich fatal. Dann darf man in Prinzip nur eine Anwendung auf dem Rechner haben die .NET verwendet.

Direkt am Code werden die wohl nix ändern, aber aktuell ist es z.b. so, daß die Saal-Software (die explizit auch für Win7 sein soll) z.B. .NET 1.x will. Installier das mal als erstes meldet Windows 7, daß .NET 1.x nicht kompatibel ist Was manch einer sich beim Design seiner Sachen denkt, werden wir wohl nie verstehen...

Dann gibt es auch Software, die .NET 2.x will, in Windows 7 ist IIRC .NET 3.5 vom Start weg dabei. So hab ich also schon 3 verschiedene "Unterbauten" im System rumschwirren

Ob das gesund ist

StefanM hat geschrieben:

vdaiker hat geschrieben: Ist es wirklich so, dass manche Applikationen am .NET Hand anlegen und da irgendwelche Teile austauschen und durch eigene ersetzen?
Falls ja, waere das natuerlich fatal. Dann darf man in Prinzip nur eine Anwendung auf dem Rechner haben die .NET verwendet.

Direkt am Code werden die wohl nix ändern, aber aktuell ist es z.b. so, daß die Saal-Software (die explizit auch für Win7 sein soll) z.B. .NET 1.x will. Installier das mal als erstes meldet Windows 7, daß .NET 1.x nicht kompatibel ist Was manch einer sich beim Design seiner Sachen denkt, werden wir wohl nie verstehen...

Dann gibt es auch Software, die .NET 2.x will, in Windows 7 ist IIRC .NET 3.5 vom Start weg dabei. So hab ich also schon 3 verschiedene "Unterbauten" im System rumschwirren

Ob das gesund ist

Naja, die verschiedenen .NET Versionen existieren eigentlich recht friedlich nebeneinander. Problematisch wird es, wenn die Software, die die .NET Bibliotheken benutzen, sich nicht richtig auskäsen, welche sie denn wollen. Dann knallt es gern.

An den Bibliotheken selbst sollten sie übrigens keine Hand anlegen können. Da hat MS einen Riegel vorgeschoben. Allerdings können sie einzelne Bestandteile 'lokal' für ihre Installation überschreiben. Wenn sich da in einer Version von .NET etwas verändert und das alles nicht mehr sauber ineinandergreift, verbiegt sich da schon mal etwas.

Ich denke aber immernoch, dass es an einem schlechten Speichermanagement bzw sogar an einem Speicherloch in CNX liegt, was sie nicht so richtig in den Griff bekommen. Es ist recht eindeutig, dass CNX der zugewiesene Speicher ausgeht (nicht der physische sondern der virtuelle.. da gibt es Unterschiede).

Das wäre also ein massiver Designfehler, oder? D.h. ein NX3 müßte aufwändig(er) teilweise neu angefangen werden und nicht nur etwas beigezimmert und poliert, neu Versionsnummer dran und fertig? Das würde auch die Ruhe erklären.

Ja, das ist, was ich denke. Aber das ist Kaffeesatzleserei. Was da wirklich defekt ist, weiß derzeit nur Nik-SW.

StefanM hat geschrieben: Dann gibt es auch Software, die .NET 2.x will, in Windows 7 ist IIRC .NET 3.5 vom Start weg dabei. So hab ich also schon 3 verschiedene "Unterbauten" im System rumschwirren

Ob das gesund ist

Ja, das nervt mich auch. Wieso kann es nicht sein, dass die hoeheren .NET abwaertskompatibel sind? Das ist wirklich mist-design, aber von M$ und nicht von NIK.

Aergerlich an dieser ganzen Misere finde ich eigentlich nur, dass Nikon sich nicht kuemmert. Wer denn sonst soll das tun. Dass wir hier in Foren diskutieren und herumraetseln kann es doch nicht sein. Wenn der Support-Mitarbeiter von Nikon den Fehler reproduzieren konnte, dann sollte man meinen, muesste es auch weitergehen. Was aber wenn der NIK Software-Ingenieur dummerweise den Fehler auf seinem Rechner nicht reproduzieren kann?
Aber ich denke die wissen das und wollen das aussitzen bis NX3 wo dann (hoffentlich) der Bug behoben ist bzw. das NX3 einfach gewisse problematische Dinge der .NET oder Win Speicherverwaltung nicht mehr nutzt.

Wie ist das eigentlich unter MAC. Gibt es da auch so was wie .NET?

Schön, dass mein erneuter Vorstoß die Diskussion wieder hat aufleben lassen. ... und all'die gut gemeinten Ratschläge - Ihr seid ja soo fürsorglich...

Leider aber bewegen wir uns im Kreis: Die Fragen, die Ihr hier diskutiert, hatten wir schon mal, und auch damals konnten wir alle nur Mutmaßungen machen.

Ich persönlich finde es ärgerlich, dass diese erneuten Diskussionen hier so verlaufen, dass Ihr mich dabei als DAU hinstellt, der diese Punkte womöglich nicht bedacht hat. Warum sonst bringt Ihr hier Fragen wieder hoch, die genau so schon früher in diesem Thread diskutiert wurden? Ihr haltet mich wohl für einen Deppen.

Ich finde, diese Diskussion hier ist echt unproduktiv - anstatt mich hier als Computer-Dödel hinzustellen, solltet Ihr mithelfen, Nikon zu einer Lösung zu bewegen! Um dem Verdacht einen Riegel vorzuschieben, ich sei ein Querulant und hätte keinen wirkliche Problemfall vorzuweisen, werde ich Euch hier weitere Auszüge aus meiner umfangreichen Korrespondenz mit dem Nikon-Kundenservice präsentieren.

Am 11.09.09 habe ich Nikon nach aufwendigen Systemtests eine Reihe von Diagnosedateien zum Status meines Betriebssystem-Installation zugeschickt - und daraufhin KEINE Rückmeldung von Nikon erhalten.

Nach einer Pause von SECHS Monaten, in denen ich von Nikon weder einen Lösungsvorschlag, noch eine Stellungnahme erhalten habe, habe ich denen am 23.03.10 eine erneute Fehlerbeschreibung geschickt, samt Beobachtungen zum Speicherverbrauch von CNX2 (das war nach dem NP-Stammtisch in München, in dessen Verlauf mir Vdaiker einige wichtige Anregungen gab). Zu diesem Zeitpunkt kam .NET zum ersten Mal in die Diskussion, und ich habe das auch an Nikon weiter geleitet. Es folgte wieder keine Antwort von Nikon.

Ich hatte Nikon daraufhin angeboten, Muster-NEFs von mir zu übermitteln, mit denen Sie den Fehler reproduzieren können. Leider erlaubt die Nikon-Site aber nicht das Hochladen sehr großer Dateien, daher bat ich sie um einen Zugang zu einem FTP-Server, auf den ich die Dateien hochladen könnte. Es folgte keine Reaktion.

Nach mehreren Stupsern meinerseits und meinen Verweis, dass genau dieser Programmfehler auch im amerikanischen Nikonians-Forum breit (und ohne Hilfe durch Nikon) diskutiert wurde, war man bereit, sich Musterdateien von mir anzusehen.

Auszug aus meiner Nachricht an Nikon vom 14.04.10:

Arjay hat geschrieben:Hallo Herr XXX,

nun habe ich drei NEF-Dateien aus Capture NX2 auf einem FTP-Server für Sie abgelegt.

Zu den Dateien:

CNX2_D300_Problem.NEF (33MB) ist ein Bild aus meiner D300 und stammt noch aus CNX2 V. 2.2.2. Diese Datei erzeugt das EOOM-Problem früher als bei der CNX2-Version 2.2.4. Einfach den letzten Arbeitsschritt (Gradationskurve) wählen und ein wenig an der Maske herum malen. Dann abspeichern, und schon haben Sie das von mir beschriebene Problem.

CNX2_D300_Problem2.NEF (25MB) stammt auch aus CNX2/D300, wurde aber erstmals mit CNX2 V. 2.2.4 gespeichert. Auch hier führen kleine Änderungen an der Maske in einem der SW-Umwandlungsschritte dazu, dass sich die Datei nicht mehr speichern lässt.

CNX2_NikScan_Problem.nef (139MB) stammt aus CNX2 V. 2.2.4 und stammt ursprünglich aus Nikon Scan. Hier führen selbst kleinste Nachbesserungen mit dem Auto-Retuschepinsel zum EOOM-Fehler.

Und so kommen Sie an die Dateien:

Gehen Sie mit einem FTP-Programm zu ftp://www.promotec.biz, loggen Sie sich mit der ID "p8290152-public" und dem Passwort "oeffentlich" ein, und dann finden Sie die oben genannten Dateien.

Die Systemdaten meines Rechners haben sich seit meinem letzten Bericht kaum geändert. Ich habe nur die laufenden Windows-Updates geholt (einschließlich der aktuellsten Version von .NET) und Capture NX2 auf die Version 2.2.4 aktualisiert.

Dort könnt Ihr die Dateien auch selbst saugen und Euch davon überzeugen, dass ich NICHT phantasiere.

zyx_999 hat geschrieben:Nimm Dir ein Bild und stemple mal "ein Weilchen" im Bild rum. Glaub mir, das ist absolut kein Problem, CNX zum "Abrauchen" zu bringen. Nur ist der Monster-Stempel-Fall jetzt IMO kein Standard-Anwendungsfall.

So unrealistisch ist der Stempel-Fall auch nicht: Versucht doch mal, ein SW-Negativ zu scannen und dann für den Druck aufzubereiten. Wer das ohne massive Stempelorgien schaffen will, muss aus seinem Archiv und seinem Arbeitsraum einen Reinraum machen...