Bugs in View NX 1.5

[night.shift]

Donholg schrieb "Man könnte natürlich auch erstmal View 1.4 weiterverwenden".
Damit funktioniert es auch nicht, und unter Windows kommen teilweise falsche Vorschaubilder, das ist schon arm für eine Weltfirma, der aber manche Forumsmitglieder jeden Fehler verzeihen.
Grüße aus Preetz,
Jan

[hajamali]

Ich liebe ViewNX wirklich. Im Workflow fest eingebunden macht es unter Leopard (und früher Windows XP) wirklich Spaß damit zu arbeiten. Aber die Trägheit die Nikon an den Tag legt, um NikonView "Snowleo kompatibel" zu machen frustriert mich wirklich. Hier muß Nikon schneller reagieren. Alle anderen Programme selbst kleinste Freeware Programme laufen mittlerweile sauber ! Mein Hauptrechner muß somit vorerst schneefrei bleiben, Danke Nikon ......und für mein Macbook mit Snowleo muß ich halt meinen Workflow umstellen.

[StefanM]

So, nach einer Neuinstallation von Win7 RC auf die Endversion hab ich den Bug auch



und so sollte es sein:

[Oli K.]

Man könnte natürlich auch erstmal View 1.4 weiterverwenden

Tu' ich auch...

[StefanM]

Ich weiß nicht, was mich dazu bewogen hat, aber ich hab ViewNX 1.5 einfach "nochmal drüber" installiert und der Fehler, daß die Tiefen alle Grün dargestellt werden, ist weg

Vielleicht war es ein Fehler, beim Neuaufsetzen des Systems Capture nach View zu installieren und das hat das Picture Control Utility mit einer älteren Version überschrieben

Naja, ich bin das Problem so los geworden

[FotoOtto]

So - bei mir ist es auch soweit... habe heute meinen neuen MacMini mit Snow Leopard bekommen und ViewNX 1.5 ist absolut nicht zum Funktionieren zu ueberreden... Capture NX 2 habe ich gar nicht mehr probiert. Also am Wochenende Installationsorgie.

ViewNX 1.4 geht uebrigens auch nicht.

Neuer MacMini Downgrade auf Leopard, alter MacMini Upgrade auf Snow Leopard.

Wenn Nikon nur nicht immer den Kopf in den Sand stecken wuerde!

Nacht! Otto

[StefanM]

Die schlechten Zeiten sind angeblich bald zuende

[FotoOtto]

Das waere zwar nicht schlecht, aber nicht bald genug. Solange lasse ich den neuen Rechner nicht rumstehen.

Naja - inzwischen kann ich das richtig gut mit der Installation (ich koennte natuerlich auch mal vom Time-Machine backup wiederherstellen - waere mal einen Versuch wert)

Gruss, Otto

[UweL]

So, nachdem ich ja jetzt nun meinen neuen Rechner habe (Core i7 860, Win 7 Prof 64), und das Problem mit den fehlenden Nachkommestellen immer noch da ist habe ich heute während des Wartens auf Resultate einiger Kollegen auf einem meiner Rechner das Problem näher analysiert.

Die Idee kam mir, weil ich neulich in unserer Software auch einen Bug entdeckt hatte beim Parsen von Datumsfelder, die vom Host immer englisch kommen ("28DEC09") aber vom Programm regionsabhängig geparst wurden - auf einem System, das mit deutschen Regionseinstellungen lief, fiel das Programm auf die Fresse, weil Dezember in Deutschland dann DEZ ist und nicht DEC.

Das Problem ist hier das gleiche... hier mal mein Kommentar an Nikon:

Sehr geehrter Herr XXXX,

ich hatte heute noch eine Idee, da ich im beruflichen Umfeld als Softwareentwickler gerade ein ähnliches Problem hatte.

Das Problem hat mit Regionseinstellungen zu tun. Wie Sie in der GPX-Datei sehen können, werden die Nachkommastellen in der GPX-Datei mit einem "." und nicht einem Komma angegeben, also z.B. lat="42.361511" lon="-71.065857" (und nicht lat="42,361511" lon="-71,065857").

Ich habe darauf hin einmal ViewNX geschlossen, die Regionseinstellungen in der Systemsteuerung auf "Englisch (USA)" gestellt, ViewNX gestartet und die Daten neu importiert - und schwupps hatte NX die richtigen Daten!
Als Gegenprüfung habe ich dann die GPX-Datei manipuliert und die Punkte durch Kommas ersetzt, die Region wieder auf "Deutschland (Deutschland)" zurück gesetzt und die Daten ebenfalls neu importiert - auch hier alles in Ordnung.

Fazit: Das Problem liegt daran, dass der "." in der Längen und Breitenangabe nicht richtig verarbeitet wird. Hintergrund: GPX-Dateien liegt ein XML Schema zugrunde (siehe http://www.topografix.com/GPX/1/1). Die Attribute "lat" und "lon" des trkpt Elements sind vom Typ latitudeType bzw. longitudeType, die beide von xsd:decimal abgeleitet sind. In diesem Datentyp ist der Dezimalpunkt wirklich ein Punkt. Es ist also nur "1.23" erlaubt und nicht "1,23".

Wenn man eine solche XML-Datei einliest (GPX Dateien sind XML-Datein, denen besagten Schema zugewiesen ist) dann muss man das berücksichtigen. Die GPX-Dateien sind korrekt, nur ViewNX liest die Werte als Dezimalwerte regionsabhängig ein. Das ist falsch.

Ich hoffe, das hilft Ihnen weiter.

Mit freundlichen Grüßen

Soll ich den Jungs eine Rechnung schicken

[StefanM]

Oder 'ne Bewerbung direkt hinterher Anscheinend können die einen brauchen