Nikon NEF Format

[franky68]

Hello Murat,

 

first of all congratulations to the new beta-version. It became much more stable since the alpha and youre getting to the point where its actually possible to test the beta :)

 

Since I started to play around with it I also discovered a few minor issues which are probably related to my image format (Nikon NEF). Is it ok to report them here to the forum or is there an email where you would like me to send them to?

 

The contact form doesnt seem to work.

 

Kind regards

Frank

[Murat]

Frank, thanks for your interest in Daminion and supporting us!

 

You can report us about any problems with Daminion by:

- creating a new topic on this forum

- sending a message by contact form

 

I'll wrote you the direct message regarding the NEF files and a problem with contact form.

[franky68]

Whow, you are quick!

 

And yes, the contact form seems working now. At least its fully loading up for me (Firefox) which it wasnt before.

 

Regarding the issues I found with NEF Files:

 

1. I can't seem to rotate them. Normally the rotation is fine after they have been imported into Daminion. However if files have been edited with ViewNX or CaptureNX the portrait orientation gets lost. This is a known bug with CNX/VNX. So with those files I need to correct the orientation inside Daminion. I can select "Rotate 90CW" and the thumbnail flashes for a second. But then it comes back and is still displayed with the wrong orientation. This also persists if I open it in the viewer.

 

2. With some images I get "Unknown" Camera lens. All those images also have been edited with CNX/VNX - untouched images seem to be ok. I know the lens information still is present. So I can only suppose that Daminion has trouble with the modified embedded xml after editing with CNX/VNX.

 

Also I have not yet found a way to clean out the database. Since I am only testing Daminion it of course is not my main DAM application. Once I impoted a directory into Daminion and later moved files from that directory into another one with my regular DAM. Now I have lots of invalid thumbnails which I cant seem to get rid of. Is there any way to clean this out?

 

Thanks in advance

Frank

[Murat]

1. Daminion detects the EXIF Orientation tag for images that were taken by a camera with a device orientation sensor. The program rotates the images according this tag "on the fly". Seems the ViewNX and CaptureNX doesn't adjust this tag after the image rotation.

 

We are not completely implemented the Rotating Images feature yet, but it will be fixed on the upcoming versions!

 

2. Please send those files to [support] email.

 

3. Unfortunately this is not possible with the current Daminion version. I am afraid you need to manually remove those thumbnails.

 

PS. Please take into account that Daminion catalogs store the relative links to the files so if you move the entire folder with a catalog and files you will preserved your file links!

[franky68]

Murat Korkmazov Wrote:

-------------------------------------------------------

> 1. Daminion detects the EXIF Orientation tag for

> images that were taken by a camera with a device

> orientation sensor. The program rotates the images

> according this tag "on the fly". Seems the ViewNX

> and CaptureNX doesn't adjust this tag after the

> image rotation.

 

CNX/VNX reset the tag after editing. They both still preview/display the images correctly but any other application gets confused. As said, this is a historical bug in both applications and Daminion cant be blamed but it would be great to have the option to manually rotate them back again.

 

> 2. Please send those files to email.

 

Thanks, I will do that later today.

 

> PS. Please take into account that Daminion

> catalogs store the relative links to the files so

> if you move the entire folder with a catalog and

> files you will preserved your file links!

 

By default my images are downloaded from the card into a folder e.g. "P:\Images\2010\2010.02" now if I have too many images for a cirtain day I move those images from that folder into e.g. "P:\Images\2010\2010.02.22". So only selected images from a folder are affected. Again I understand that Daminion can't notice files that are moved by other applications. It just would be great if there was a way to check the integritiy of the database and locate broken links.

 

Another one: This already happened with the alpha version and was the reason I stopped testing it any further. Now I had the same issue with the current beta. After working with Daminion for a while it stops displaying images in fullscreen mode.

 

I am getting an error message on top of the screen that reads "Unable to preview media file: Eine Ausnahme vom Typ 'System.OutOfMemoryException' wurde ausgelöst". This is german (my local) and rougly translates to 'An exception of type "System.OutOfMemoryException" was raised'.

 

I am running Daminion on a Q9550 with 4GB memory (3.5GB available) and Windows 7 Professional. I just checked my ressources and there is still plenty of physical memory available. Daminion is taking up 222.504k so system memory really shouldnt be the issue.

 

Thanks for your quick responses.

 

Frank

[Murat]

> Again I understand that Daminion can't notice files that are moved by other applications. It just would be

> great if there was a way to check the integritiy of the database and locate broken links.

 

This feature will be included in our future list. As you know PicaJet (the Daminion's predecessor) has the similar feature to locate and fix the broken links.

 

 

> I am getting an error message on top of the screen that reads "Unable to preview media file: Eine

> Ausnahme vom Typ 'System.OutOfMemoryException' wurde ausgelöst". This is german (my local) and

> rougly translates to 'An exception of type "System.OutOfMemoryException" was raised'.

 

Does this issue occurs each time you launch Daminion or after a certain period of time after the start of the program?

Could you please send us a bug-report?

 

 

- Please launch the program, press F12 key.

- Close the Daminion.

- On the appeared Windows Explorer window locate '1.0' folder and rename it to '~1.0'.

- Launch Daminion and check this issue again.

[Murat]

Support for Nikon Lens will be improved on the upcoming Daminion version.

[franky68]

Yay!!!

 

I just found that NEF rotation is finally working and better than that: freshly imported images even are rotated correctly no matter of their edit status. This are really great news!

 

Now that Daminion is becoming serious for us Nikon users there are two more things that come up to my mind:

 

1. Would it be possible to automatically update thumbnails for images that have been edited? (e.g. file modification is past last thumbnail update). Either fully automatic when the thumbnail is displayed or by pressing a key. This would help to keep up with files that have been edited in CNX/VNX. I know this already can be done by selecting a single or set of thumbs but an automatic way would be great.

 

2. Will it (in a future version) be possible to sync metadata between Daminion and the NEF? At least transfering ratings and color labels would be really great. Syncing all metadata (in both directions) would be even better of course ;^)

 

Kind regards

Frank

 

 

PS: A minor note: My Nikon AF-D 50/1.8 is reported as AF 50/1.8G. I wish it was indeed the new G-Lens ;)

[Murat]

1. This is one of the most requested features for Daminion. And right after releasing the stable Daminion Server version we begin implementing the most wanted Daminion Standalone features (including automatic thumbnail updating)

 

2. I’ve experimentally turned this feature on (in fact we supported this feature on early Daminion version) for CR2, NEF and DNG formats.

 

>> PS: A minor note: My Nikon AF-D 50/1.8 is reported as AF 50/1.8G. I wish it was indeed the new G-Lens ;)

Could you please send me a photo taken by AF-D 50/1.8 to support at daminion dot net?

[franky68]

Hello Murat,

 

thanks for your fast response! :)

 

re rotating:

I found a minor problem here.

- All imported images with their "natural" orientation (as detected by the cam) are imported correctly now. No matter if they have been edited in CNX/VNX or not. This is something where many other applications fail.

- If I rotate an image anyway in Daminion the new orientation is displayed in Daminion and CNX/VNX (so I suppose you dont anymore rotate on the fly but by setting a flag in the NEF?)

- BUT if I rotate a file inside CNX/VNX the new orientation is not reflected in Daminion. Neither in the thumbnail (even after refreshing) nor in the fullpage view.

 

 

1. This is one of the most requested features for Daminion. And right after releasing the stable Daminion Server version we begin implementing the most wanted Daminion Standalone features (including automatic thumbnail updating)

 

Whow, this is great. I am looking forward to this. Tho I hope this will not be a standaone only feature?

 

I keep my images on a shared drive to access them from my desktop and my laptop so I guess Ill need the Server version?

 

2. I’ve experimentally turned this feature on (in fact we supported this feature on early Daminion version) for CR2, NEF and DNG formats.

 

This is strange. This never really worked for me. Now I found some other oddyties I (again) deleted my settings-folder this works better. However this only works that changes made in Damion can be seen in VNX and not the other way round. I suppose this also will start working once the "auto (thumbnail) update" is working?

 

Another issue: When I set a color label in Daminion the image shows a *white* flag in CNX. Checking the file properties the label is correctly reported as "red" or whatever, still the flag always is white, no matter what.

 

>> PS: A minor note: My Nikon AF-D 50/1.8 is reported as AF 50/1.8G. I wish it was indeed the new G-Lens ;)

Could you please send me a photo taken by AF-D 50/1.8 to support at daminion dot net?

 

Its already in your inbox.

 

Kind regards

Frank

[Murat]

- BUT if I rotate a file inside CNX/VNX the new orientation is not reflected in Daminion. Neither in the thumbnail (even after refreshing) nor in the fullpage view.

 

Even after reimporting this image to Daminion? Could you please send me a photo that has been rotated in CNX/VNX and incorrectly displayed in Daminion.

 

Whow, this is great. I am looking forward to this. Tho I hope this will not be a standaone only feature?

 

Yes. Daminion should reflect for outside file changes not matter if this is a standalone version or a server one.

 

I keep my images on a shared drive to access them from my desktop and my laptop so I guess Ill need the Server version?

 

Daminion Server might drastically reduce the bandwidth and improve the performance because the metadata syncing will occurs on the same computer with the original files (it's valid for Camera RAW image rendering also).

 

 

This is strange. This never really worked for me. Now I found some other oddyties I (again) deleted my settings-folder this works better. However this only works that changes made in Damion can be seen in VNX and not the other way round. I suppose this also will start working once the "auto (thumbnail) update" is working?

 

Please check this with a new build that I've sent you to your email. And please also check if a new version correctly determines Nikone Lens suffixes.

 

 

Another issue: When I set a color label in Daminion the image shows a *white* flag in CNX. Checking the file properties the label is correctly reported as "red" or whatever, still the flag always is white, no matter what.

 

It's because the 0.8.3.340 version doesn't write metadata to .NEF format. It should works with a new build.

[franky68]

Even after reimporting this image to Daminion? Could you please send me a photo that has been rotated in CNX/VNX and incorrectly displayed in Daminion.

 

No, after deleting and re-importing the image is correctly rotated.

 

Here is what I do:

1. Select an image in Daminion

2. Press "E" which brings me to VNX

3. I accept the "check in" dialog

4. Inside VNX I rotate the image

5. Back in Daminion I check the image in again (it still shows the old orientation)

6. I select "update thumbnail" from the context menu for that image (still the old orientation)

7. I hit "DEL" to delete the image from the database

8. I reimport that particular image (now the thumbnail reflects the new orientation)

9. I rotate the image back in Daminion like it was before 4.

10. Now Daminion (thumb and fullview) show the image like it was in the begining but VNX still shows the rotation that was done in 4.

 

To me it seems that Daminion should already update the thumbnail after step 6 and not require the delete/import process. Also normally rotations done in Daminion are also displayed in VNX. This however does not work in 10.

 

Could it be at some point the "connection" between VNX and Daminion gets lost and there is inconsistency in the rotation data?

 

 

 

It's because the 0.8.3.340 version doesn't write metadata to .NEF format. It should works with a new build.

 

It seems it does write metadata to NEF... - As written the stars are displayed in VNX and also the flag itself is there, even with the color property. Its just that the color does not show in the flag, instead its always white. Also (eventhough I did not yet really test it) the keywords given in Daminion seem to be known in VNX.

 

Kind regards

Frank

[Murat]

The problem with rotation is because "Update Thumbnail" command in Daminion doesn't re-read the EXIF-Orientation tag from image. VNX changes this tag when you rotate an image in VNX.

 

I've added this issue to our bug-tracking system. Thank you!

 

It seems it does write metadata to NEF... - As written the stars are displayed in VNX and also the flag itself is there, even with the color property. It's just that the color does not show in the flag, instead its always white. Also (even though I did not yet really test it) the keywords given in Daminion seem to be known in VNX.

 

I am not familiar with VNX and don't know what this flag is means and how it's mapped to the metadata. You can see that Metadata is a bridge between Daminion and other programs that understand metadata. And to understand each other (Daminion & VNX in our case) very well the programs should equally speak in the language of metadata.

[franky68]

I've added this issue to our bug-tracking system. Thank you!

 

Great - thanks! :)

 

I am not familiar with VNX and don't know what this flag is means and how it's mapped to the metadata. You can see that Metadata is a bridge between Daminion and other programs that understand metadata. And to understand each other (Daminion & VNX in our case) very well the programs should equally speak in the language of metadata.

 

I understand what metadata is ;)

 

I was refering to your statement that Daminion wouldnt write metadata into NEFs with the current version.

 

The issue with the flags probably is related to the strange ways Nikon is going with metadata. Probably CNX/VNX need more information to be set to recognize the label properly.

 

Setting a red label in VNX results in the following changes:

Urgency : 1 (most urgent)

Label : Rot

 

While doing the same in Daminions causes:

Label : Red

 

I see that CNX also changes the "Urgency" and uses the locale color. So I suspect the problem beeing either of that (or both).

 

Kind regards

Frank

[Murat]

I was refering to your statement that Daminion wouldnt write metadata into NEFs with the current version.

 

I've tried to annotate the NEF files you sent me. For some files Adobe XML Toolkit (that is used by Daminion) creates sidecar XMP files. And for some files it writes the metadata directly into the NEF files (without side car files).

 

Does the problem with renaming files is valid for specific files? If yes could you please send me one of those files?

 

The issue with the flags probably is related to the strange ways Nikon is going with metadata. Probably CNX/VNX need more information to be set to recognize the label properly.

 

As you know the XML Label is a text field. And you can rename the Color Label names (right click on the Color Label tag and select Rename option) to match for VNX color label names.

 

I am downloading VNX to check this...

[Murat]

Frank,

 

I've download VNX and checked the issue with the color labels.

 

The problem is because Adobe XML Toolkit and ViewNX write XMP in

different places!! So if you change color label in Daminion and then change color label in ViewNX you will have different 2 XMP info blocks on your file.

 

Adobe XML Toolkit writes xmp at the beginning of the file while ViewNX saves xmp block at the end of file. So we disabled writing XMP for NEF files feature until we found a solution for this.

 

I've tried to assign a Color Label to the NEF files in Lightroom but it creates the sidecar file. And ViewNX ignores it as well.

 

 

 

--

Regards,

Murat

[franky68]

I've tried to annotate the NEF files you sent me. For some files Adobe XML Toolkit (that is used by Daminion) creates sidecar XMP files. And for some files it writes the metadata directly into the NEF files (without side car files).

 

I just found something about the color labels. As said in my pervious post VNX was using locale (german) colortags while Daminion uses english. Now if I set the labels in CNX to english or the labels in Daminion to german the labels *are* able to be exchanged between Daminion and CNX.

 

So I suspect the problem is not the position of the metadata as you mentioned in your next post but only what the labels are reading. Stupid me should have thought of this earlier...

 

Of course Daminion still requires deleting and re-importing the file for the changes to show up - like its needed for star ratings - but generally it works.

 

So probably with the mentioned auto-update this should work too.

 

Does the problem with renaming files is valid for specific files? If yes could you please send me one of those files?

 

No, there is nothing special about the files. The issue occours repeadedly but I havent yet made out a pattern to reproduce it. As said, I suspect Daminion to be responsible for the changes but you should know better if the renaming pattern (prefix "._00_") is something thats done in Daminion.

[franky68]

Adobe XML Toolkit writes xmp at the beginning of the file while ViewNX saves xmp block at the end of file. So we disabled writing XMP for NEF files feature until we found a solution for this.

 

As written before the exchange does seem to work. Do they both write in their specific place only when they *create* the XML field or even create a new one if the field is already present in the other location? And if they do, will they erase the foreign one or do you really end up with two entries for the same data?

 

The ability to transfer the label between both applications seems to indicate that both actually can share one position for the entry.

 

I've tried to assign a Color Label to the NEF files in Lightroom but it creates the sidecar file. And ViewNX ignores it as well.

 

Yes, unfortunately CNX/VNX ignores sidecar files. This (and the ability to use the embedded jpeg) actually makes it hard to find a good DAM for the CNX/VNX workflow and one more reason why I (and probably many other Nikonians) am so interested in Daminion ;)

 

However from what I know you can get and use the Nikon NEF library for free if you contact their technical support. But right now it looks to me like the Adobe XML Toolkit would work fine.

 

Kind regards

Frank

[Murat]

The main problems with Adobe XMP Toolkit and Nikon software are:

- they both create different XMP sections within the same file. So if you change a color label by VNX it saves it's own XMP block. Adobe XMP Toolkit read the file and locate the XMP block written by VNX. And Daminion recognizes the XMP info written by VNX if the file has JUST ONE XMP block.

 

But once you change the file info from Daminion it saves the second XMP block and VNX xmp block is no longer available from Daminion. Thats the biggest problem with the current XMP Toolkit version.

 

- XMP Toolkit creates XMP sidecar for some NEF files. I don't know why, and this option is out of our control.

 

- Seems the issue with renaming files is related to XMP Toolkit. It creates a temporary file (in rare cases) for a few seconds that is deleted later.

 

I've requested Nikon NEF library from their web-site.

[franky68]

Yes, I just double checked and youre (of course) right.

 

The labels only work as long as you only set them with one application. Once you start altering it with the other app it all becomes messed up. Strangely the same works for stars without problems tho.

 

Anyway, I hope the nikon library will fix this. Thanks for investigating!

 

Kind regards

Frank

[Murat]

Frank, you are right. Seems VNX uses:

- XMP:IPTC:Urgency to set Number (and Color based on Number)

- and XMP:Label for Label Name

 

So it uses color presentation of IPTC:Urgency while Daminion represents Color marks based on XMP:Label.

 

Unfortunately I don't see the connection between Urgency and Label in XMP, IPTC specifications.

[franky68]

I am not too familar with all this but I did a little search on this issue. Unfortunately I have not found anything reliable. But from what I read there used to be a connection but the whole "Urgency" field has been deprecated back in 2005. But this connection seems still be required for quite a few applications even outside CNX/VNX that still use the old sceme.

 

Since the whole "urgency" has been depricated it shouldnt harm to set it according to the "label". Either the application uses the old standard, then this should be fine. Or the application does not use the "urgency" at all so setting it wont do any harm ;)

 

Another option would be to turn it into an option if this field should be used or not. I found quite a number of references about application that need this connection to work with labels correctly. So I think its definately a good idea supporting it.

[Murat]

Since the whole "urgency" has been depricated it shouldnt harm to set it according to the "label". Either the application uses the old standard, then this should be fine. Or the application does not use the "urgency" at all so setting it wont do any harm ;)

 

The problem here is there are might be other application that use Urgency somehow. So by changing ColorLabel user corrupt the Urgency field.

 

 

Another option would be to turn it into an option if this field should be used or not. I found quite a number of references about application that need this connection to work with labels correctly. So I think its definately a good idea supporting it.

 

The more natural way I see here is using Events/Triggers. But we don't plan to implement this feature early than 1.0 version.

[franky68]

The problem here is there are might be other application that use Urgency somehow. So by changing ColorLabel user corrupt the Urgency field.

 

Well, if its "depricated" now and formerly was used together with the "label" field other applications that use it for other purposes work definately outside the standard and so those are to blame ;^)

 

Ok, thats the pragmatic approach, from a more purist one you are right of course.

 

The more natural way I see here is using Events/Triggers. But we don't plan to implement this feature early than 1.0 version.

 

I admit I am a bit selfish about this. But I found references about ACR, Bridge, Lightroom (virtually all Adobe products at least up to CS2), Capture One (tested myself), Photomechanic, Digikam and of course the Nikon apps. I am not sure about other RAW converters but I wouldnt be suprised if the'd follow Adobes lead.

 

I also found that a couple of other DAM applications have a setting to optionally sync both fields.

 

So this might push it a little up in your priority list? ;)

[Murat]

Lightroom doesn't care about IPTC:Urgency.

 

Adding this feature as a workaround is a question of the priority (as you said).

 

Let's wait till we'll release the Daminion Server. It takes our main efforts at the moment.

 

But collecting a feedback is much faster than releasing new versions so any suggestions are welcome! :)