Are we there yet?

[franky68]

Hello Murat,

 

as you know I am eagerly awaiting to replace ACDSee with something that allows me to actually manage my images. After much frustration with checking out other DAM applications I am pretty optimistic that Daminion will end up becoming what I am looking for.

 

Right now there still are a few glitches that stop me from actually using it RL:

 

1. Misinterpreting of some Nikon EXIF fields (lens-info, color space etc.). I expect that I can change those values in the database to have consistent values. So after importing all my images I will run a few SQL queries and things should be fixed. However this requires that Daminion will not write those values back into the files and that the final release will definately be able to handle those fields properly.

 

Am I correct that a. only fields will be synced back that can be edited inside daminion and b. that Daminion will read them properly in the near future?

 

2. I need complex queries. Ideally supported by the UI but I could live with the option to use an SQL syntax editor and save them as "Saved search" (see recent topic).

 

3. Another thing that is essential to me is the improved lighttable: a. infinite number of images, b. highlight/shadow warning, c. accept/reject

 

Is there any realistic chance those two fields will be improved?

 

4. Finally from what Im getting I will need the Daminion (Home?) Server Version. In another post you wrote it will be possible to seamlessly switch over from standalone to server. Is this correct?

 

Along with the (yet) missing importer (you already wrote it will be coming) those are my very minimum requirements to use a DAM application so it would be great if you could clarify about those points and I already could start using Daminion for more than just testing ;)

 

After all my biggest and surprisngly hardest to find requirement (compatibility with NEF files) is already met :)

 

Kind regards

Frank

[Murat]

 

1. Misinterpreting of some Nikon EXIF fields (lens-info, color space etc.). I expect that I can change those values in the database to have consistent values. So after importing all my images I will run a few SQL queries and things should be fixed. However this requires that Daminion will not write those values back into the files and that the final release will definately be able to handle those fields properly.

 

Am I correct that a. only fields will be synced back that can be edited inside daminion and b. that Daminion will read them properly in the near future?

 

a. No. It depends from the mapping rules. On the upcoming Daminion versions we'll add an option to display a list of the mapped metadata fields for each tag.

 

b. Yes. The option "Read Metadata" will allow to extract/replace tag values from the metadata.

Could you please send me a few files with embedded color profile that were incorrectly interpreted by Daminion?

 

2. I need complex queries. Ideally supported by the UI but I could live with the option to use an SQL syntax editor and save them as "Saved search" (see recent topic).

 

The most likely scenario at the near future is to automatically wrap tags, conjucted by OR connector, by brakets. As you suggested early. For ex: (tagC OR tagD) AND tagA AND tagB.

 

3. Another thing that is essential to me is the improved lighttable: a. infinite number of images, b. highlight/shadow warning, c. accept/reject

Point C. (Accept/Reject) this is a feature that could be implemented. I am not sure about A feature. It will depends from the number of user requests. It's possible to include a Histogram window instead of the highlight/shadow warning.

 

4. Finally from what Im getting I will need the Daminion (Home?) Server Version. In another post you wrote it will be possible to seamlessly switch over from standalone to server. Is this correct?

Yes. Porting standalone Daminion catalogs (SQLite based database) to Daminion Server catalog(s) (PostgreSQL) will be possible in the future.

 

Daminion Server is the direction where we will put our most efforts. So any feature that improves collaboration capabilities will has the highest priority.

[franky68]

a. No. It depends from the mapping rules. On the upcoming Daminion versions we'll add an option to display a list of the mapped metadata fields for each tag.

 

thanks for clarification So I am afraid I need to stick with my current "DAM" for a while and keep on playing with Daminion in a sandbox.

 

Could you please send me a few files with embedded color profile that were incorrectly interpreted by Daminion?

 

hmm.... I checked some more. Unfortunately playing with sandboxes is very limited when it comes to empiric data. From what I can see is that my (unedited) D300s images are tagged "Unknown", the D70s images have "sRGB", ViewNX does not seem to change it and after editing them with CaptureNX they can have also "Nikon sRGB 4.0.0.300x" and "sRGB IEC61966-2.1" so I suppose the problem is also related to CaptureNX.

 

But generally if you said sRGB would be the default profile each image have unless said otherwise, wouldnt it be correct to tag the "unknown" images with "sRGB"? Thats what all other EXIF/ITPC reader identifies them with.

 

Point C. (Accept/Reject) this is a feature that could be implemented. I am not sure about A feature. It will depends from the number of user requests. It's possible to include a Histogram window instead of the highlight/shadow warning.

 

I think the histogram window is nice for image editing but of very limited use to rate images. While you can see *if* there are blown out highlights / lost shaddows you cant see *where* they are. There are many images you accept either of them (sun, shaddow in holes etc.) so as long as you can't see which regions are affected you can't really judge the image. This would mean I need to use ViewNX for the first review and deleting. So I could only import them into Daminion *after* that step (because of the deleting part) - ...and probably would ditch/forget the import after a while...

 

Generally I consider rating/refusing(deleting) images beeing one of the core functionalities of a DAM so I have to admit I am a bit surprised about a-c not beeing part of the todo list anyway. I frankly can not remember any DAM application I checked more toroughly that can not display shadows/highlights and compare only four images.

 

Maybe this was not requested more already because ppl just take it for granted that it will be implemented at a later time?

[Murat]

1. Misinterpreting of some Nikon EXIF fields (lens-info, color space etc.).

 

We've slightly fix the Nikon lens formatting. And I've made some tests with the NEF files you sent me recently.

 

Below is the comparison chart of how different tools interprets lens information for NIKON NEF files (the ones you sent me):

 

DSC_0606.NEF

Daminion poorly formats the lens because we get it from XMP;AUX LenS (as is).

ExifTool 8.4.5: Lens	->	18-70mm f/3.5-4.5
ExifTool 8.4.5:LensID	->	AF-S DX Zoom-Nikkor 18-70mm f/3.5-4.5G IF-ED
Daminion 0.8.5	->	18-70 mm  F3,5-F4,5
Daminion 0.8.6	->	18-70 mm  F3,5-F4,5
Lightroom 3.4.1	->	18-70 mm F3,5-4,5
ViewNX 2.1.1	->	18-70mm F/3,5-4,5G

 

DSC_1869.NEF

ExifTool 8.4.5: Lens	->	18-70mm f/3.5-4.5
ExifTool 8.4.5:LensID	->	AF-S DX Zoom-Nikkor 18-70mm f/3.5-4.5G IF-ED
Daminion 0.8.5	->	18-70 mm  F3,5-F4,5
Daminion 0.8.6	->	18-70 mm  F3,5-F4,5
Lightroom 3.4.1	->	18-70 mm F3,5-4,5
ViewNX 2.1.1	->	18-70mm F/3,5-4,5G

 

D30_0957.NEF

ExifTool 8.4.5: Lens	->	50mm f/1.8
ExifTool 8.4.5:LensID	->	AF Nikkor 50mm f/1.8D
Daminion 0.8.5	->	50mm f/1.8 D
Daminion 0.8.6	->	50mm f/1.8D
Lightroom 3.4.1	->	50.0 mm f/1.8
ViewNX 2.1.1	->	50mm F/1,8D

 

D30_3079.NEF

ExifTool 8.4.5: Lens	->	35mm f/1.8
ExifTool 8.4.5:LensID	->	AF-S DX Nikkor 35mm f/1.8G
Daminion 0.8.5	->	35mm f/1.8 D G
Daminion 0.8.6	->	35mm f/1.8G
Lightroom 3.4.1	->	35.0 mm f/1.8
ViewNX 2.1.1	->	35mm F/1,8G

 

D30_4190.NEF

ExifTool 8.4.5: Lens	->	70-300mm f/4.5-5.6
ExifTool 8.4.5:LensID	->	AF-S VR Zoom-Nikkor 70-300mm f/4.5-5.6G IF-ED
Daminion 0.8.5	->	70-300mm f/4.5-5.6
Daminion 0.8.6	->	70-300mm f/4.5-5.6
Lightroom 3.4.1	->	70-300 mm F4.5-5.6
ViewNX 2.1.1	->	VR 70-300mm F/4,5-5,6G

 

D30_3124.NEF

ExifTool 8.4.5: Lens	->	50mm f/1.8
ExifTool 8.4.5:LensID	->	AF Nikkor 50mm f/1.8D
Daminion 0.8.5	->	50mm f/1.8 D
Daminion 0.8.6	->	50mm f/1.8D
Lightroom 3.4.1	->	50.0 mm f/1.8
ViewNX 2.1.1	->	50mm F/1,8D

 

Frank, as you see the only tool that has an access to LensID is the ExifTool, because it decodes the LensData block. Including the native (.NET) decoding of the Nikon LensData might be time consuming task, so I guess the best solution here is using ExifTool (optionally) to extract the Nikon Lens info. But it might be very slow because we use ExifTool via command line.

[franky68]

Hello Murat,

 

the "problem" is not the format of the tag but the inconsistency. I have one lens that creates a couple of lens entries.

 

However it seems that I was able to track down the problem a little further.

 

I have two images. Both taken on the same day, with the same camera and the same lens:

 

D30_6021.NEF - 18-70mm f/3.5-4.5 D G

D30_6024.NEF - 18-70mm f/3.5-4.5

 

The only difference between them is that D30_6021.NEF has been touched by ViewNX2. If I copy D30_6024.NEF and edit the copy with ViewNX it also shows the "D G" appendix in Daminion. So there must be something happening in ViewNX that confuses Daminion.

 

ViewNX shows for both images: 18-70mm 1:3,5-4,5G

 

Lets see what exiftool says:

 

C:\Users\Franky\Neuer Ordner>exiftool D30_6021.NEF | grep -i lens

Lens Type : G

Lens : 18-70mm f/3.5-4.5

Lens Data Version : 0204

Lens ID Number : 127

Lens F Stops : 5.33

Lens ID : AF-S DX Zoom-Nikkor 18-70mm f/3.5-4.5G IF-ED

Lens : 18-70mm f/3.5-4.5 G

 

C:\Users\Franky\Neuer Ordner>exiftool D30_6024.NEF | grep -i lens

Lens Type : G

Lens : 18-70mm f/3.5-4.5

Lens Data Version : 0204

Lens ID Number : 127

Lens F Stops : 5.33

Lens ID : AF-S DX Zoom-Nikkor 18-70mm f/3.5-4.5G IF-ED

Lens : 18-70mm f/3.5-4.5 G

 

Now PhotoME:

D30_6021.NEF:

LensType: D, G

Lens: 18-70mm F3.5-4.5

LensID: AF-S DX Zoom-Nikkor 18-70mm F3.5-4.5G IF-ED

D30_6024.NEF:

LensType: D, G

Lens: 18-70mm F3.5-4.5

LensID: AF-S DX Zoom-Nikkor 18-70mm F3.5-4.5G IF-ED

 

Obviously neither ViewNX (of course) nor exiftool and PhotoME are confused about the lens. I am not sure if you really need exiftool to decode the lens or if there is anything about the way you decode the data.

 

Ill send both example images to your support email in case you'd like to play around with them.

[Murat]

the "problem" is not the format of the tag but the inconsistency. I have one lens that creates a couple of lens entries.

 

It's because images were imported to the same by different Daminion versions. And formatting of the lens were slightly differ in each version.

 

However it seems that I was able to track down the problem a little further.

 

I have two images. Both taken on the same day, with the same camera and the same lens:

 

D30_6021.NEF - 18-70mm f/3.5-4.5 D G

D30_6024.NEF - 18-70mm f/3.5-4.5

 

The only difference between them is that D30_6021.NEF has been touched by ViewNX2. If I copy D30_6024.NEF and edit the copy with ViewNX it also shows the "D G" appendix in Daminion. So there must be something happening in ViewNX that confuses Daminion.

 

ViewNX shows for both images: 18-70mm 1:3,5-4,5G

 

Daminion 0.8.6 will interpret it as "18-70mm f/3.5-4.5G". Because "D G" should be replaced with "G".

But only if xmp aux:lens field is not exist.

 

 

Ill send both example images to your support email in case you'd like to play around with them.

 

Yes. Please. I'd be appreciate it if your send me the files with built-in color profile that is incorrectly interpreted in Daminion.

[franky68]

It's because images were imported to the same by different Daminion versions. And formatting of the lens were slightly differ in each version.

 

Daminion 0.8.6 will interpret it as "18-70mm f/3.5-4.5G". Because "D G" should be replaced with "G".

But only if xmp aux:lens field is not exist.

 

The images both have been imported with 0.8.5 - of course I could not yet test with 0.8.6 - its not released yet ;)

 

Yes. Please. I'd be appreciate it if your send me the files with built-in color profile that is incorrectly interpreted in Daminion.

 

The files are on its way. My DSL is not the fastest and your mailserver does not allow to send both files at once.

 

The color profile seems to be a different beast tho. I will check more into that tomorrow morning.

[Murat]

The files are on its way. My DSL is not the fastest and your mailserver does not allow to send both files at once.

 

We use Google Apps. Probably this is their limitation.

 

Thanks for the files. I've checked them, and Daminion 0.8.6 shows me:

18-70mm f/3.5-4.5 for D30_6024.NEF

18-70mm f/3.5-4.5G for D30_6021.NEF

 

Lens Type for the first file is G (checked by ExifTool), but out core image library is unable to retrieve it.

[franky68]

Yes. Please. I'd be appreciate it if your send me the files with built-in color profile that is incorrectly interpreted in Daminion.

 

The color profile also seems to depend on the processing... The same two images I sent you work as an example here as well.

 

Daminion detects:

D30_6021.NEF: sRGB IEC61966-2.1

D30_6024.NEF: sRGB

 

But according to exiftool this is correct:

 

D30_6021.NEF

Color Space : sRGB

Device Model : sRGB

Profile Description : sRGB IEC61966-2.1

Device Model Desc : IEC 61966-2.1 Default RGB colour space - sRGB

 

D30_6024.NEF

Color Space : sRGB

 

So it seems that ViewNX adds the other labels while only "Color Space" is already set by the camera. Now Daminion normally seems to read "Profile Description" but falls back to "Color Space" if the first is not readable.

 

This is of course totally correct - but still its nasty because it clutters the color profile. It doesnt really matter to me since I only work with sRGB anyway but if I had multiple (real) profiles the additional branches would bother me.

 

Suggestion: Would it be possible to have the "plain" profiles as stored in "Color Space" as parent and if there is a more detailed name put this in a child. This way people still had the detailed name if this is really necessary but would be able to select all sRGB images with a single click.

 

 

Thanks for the files. I've checked them, and Daminion 0.8.6 shows me:

18-70mm f/3.5-4.5 for D30_6024.NEF

18-70mm f/3.5-4.5G for D30_6021.NEF

 

Lens Type for the first file is G (checked by ExifTool), but out core image library is unable to retrieve it.

 

Drats... - This means your library is not able to properly read NEF images that are written by the camera?

 

Do you see any chance the library will be updated or alternatively the native nikon libraries will be utilized? The Nikon D300(s) and her little sister D90 are the most spread Nikon cameras after all. And while I can not test it, newer cameras probably suffer from the same problem.

 

For a quick fix it probably would be better to ignore the "Lens Type" than to report it incorrectly.

[Murat]

If an image doesn't contain any color profile information we determine it as sRGB.

sRGB IEC61966-2.1 is the official specification of sRGB. So sRGB IEC61966-2.1 and sRGB means the same. At the moment we can replace the long name with sRGB.

 

We thought about an idea to group the tags. For example camera model tags can be grouped by vendor names: Nikon, Canon, Fuji, Pentax... And probably it can be done for color profile tags, but I would like to collect more feedback here.

 

Drats... - This means your library is not able to properly read NEF images that are written by the camera?

 

Do you see any chance the library will be updated or alternatively the native nikon libraries will be utilized? The Nikon D300(s) and her little sister D90 are the most spread Nikon cameras after all. And while I can not test it, newer cameras probably suffer from the same problem.

 

For a quick fix it probably would be better to ignore the "Lens Type" than to report it incorrectly.

 

I can't to say about all the Nikon fields. The issue is about the only Nikon LensType field. May I send your image (D30_6024.NEF) to the library developer?

[franky68]

If an image doesn't contain any color profile information we determine it as sRGB.

sRGB IEC61966-2.1 is the official specification of sRGB. So sRGB IEC61966-2.1 and sRGB means the same. At the moment we can replace the long name with sRGB.

 

Yes, in former versions I got an "Unknown" but when I reimport those images with 0.8.5. they now are tagged "sRGB". Thats good :)

 

Now if "sRGB" and "sRGB IEC61966-2.1" are identical and there are no different versions/revisions or whatever of sRGB it would make sense to give them the same label too.

 

We thought about an idea to group the tags. For example camera model tags can be grouped by vendor names: Nikon, Canon, Fuji, Pentax... And probably it can be done for color profile tags, but I would like to collect more feedback here.

 

Independant of the color space thingy I like the idea of grouping tags as it would help to structure the images (which actually is the point of a DAM ;)). The only disadvantage I can see with that is that it requires one click more to open a tree (add an expand all childs option to the context-menu) and that the tag area would grow in length for the additional group entries. But then again I could adjust that list better by opening only those groups I really need.

 

Of course grouping only makes sense if:

1. Checking the parent label would optionally select all child labels

2. The number (of images) for the parent label would optionally include the number for all of its childs.

 

I only mention this because the behaviour is currently different in the "Keywords" where grouping/parenting is already possible.

 

I can't to say about all the Nikon fields. The issue is about the only Nikon LensType field. May I send your image (D30_6024.NEF) to the library developer?

 

Yes, please feel free.