ViewNX 2.2.1

[franky68]

Hello Murat,

 

with the new Daminion Version you implemented a "rejected" tag. Did I already tell you that I love it?

 

Obviously Nikon thought the same and implemented a "rejected" rating in the new VNX version (2.2.1). I suppose this will be also introduced to CNX with the next update.

 

I did a quick check to see what exactly they are doing to the metadata and found that they set "Rating" to a value of "-1".

 

I prefer the way this is handled in Daminion (Tag/Reject) as this is way more flexible as an image can have a rejected/tagged and stars.

 

The downside of the different approaches is that this probably cause problems when Daminion would export a "Rejected" rating into exif using the "Rating" as both are different things in Daminion.

 

However it might be good to consider this when importing images and have them set to rejected when they have a -1 rating and to be aware of possible negative values so they wont get deleted when Daminion syncs its data back.

[franky68]

...oh and talking about rejected images - are there any plans to implement deletion of files in Daminion? Right now I can delete an image entry in the catalog but not the file itself.

[Murat]

...oh and talking about rejected images - are there any plans to implement deletion of files in Daminion? Right now I can delete an image entry in the catalog but not the file itself.

 

It's possible to delete images within Daminion:

- Select the images, then press Shift + Del key combination.

[Murat]

However it might be good to consider this when importing images and have them set to rejected when they have a -1 rating and to be aware of possible negative values so they wont get deleted when Daminion syncs its data back.

 

We've added the one-directional mapping from Rating (-1) to the Flag tag. So Daminion can determine an image/document as Rejected if Rating "-1" will be located.

 

But if you'll mark an image/document by Rejected flag by Daminion it will not be reflected to the Rating metadata. Because as you said above: in Daminion rating values can be used in conjunction with flag values, and changing the Flag should destroy the rating value.

 

If this approach is OK we can include it to the next release.

[franky68]

Thats great!

 

Full exchange (export) would be perfect but of course this is not possible with the different philosophies. And as said, I personally prefer the Daminion way (seperate accepted/rejected).

 

Does Daminion preserve the "-1" ratings when syncing back its metadata?

 

...thinking about this... - how about having a "-1" rating in Daminion as well (independant of the tag/rejected)? This way syncing back and forth would be possible without loosing the flexibility.

[pgrondin]

Franky, if you think about what the NEF file can contain, I think you will realize that it is impossible to Sync the Daminion Rejected FLAG back to NEF (Rating = -1) and preserve the Rating.

 

I don`t think it is possible, or advisable to maintain the Daminion Rating while the NEF file has a -1 Rejected rating. It would require that sometimes Ratings are synchronized, and sometimes the Rejected flag over-rides the Rating when syncing back. Then Daminion has a Rating that the NEF file does not have. There are just too many messy issues that arise if you try to maintain consistency between NEF files and the catalog in all cases except for ...

 

Nikon controls the specification, we really need to recognize that and live with it. (Even if we have a better idea)

 

Peter

[franky68]

I already wrote (twice) that syncing back the "rejected" should not be possible. And while I haven't tested I do not even think Daminion writes its tagged/rejected into the files at all (does it?).

 

This gives basicly three options:

1. Ignore the Nikon rejected (bad)

2. Implement one way compability (at import state as Murat wrote)

3. Implement a "-1" rating as well (and keep Tag/Rejected as it is)

 

#3 would give full compability with the Nikon format, allow syncing back and still allow the original Daminion tag/rejected. However "-1" and "rejected" would of course not be linked.

 

The only disadvantage of this would be that "-1" is not a standard rating. So one could argue that writing no standard data is a bad thing to do - but then again Daminion already supports x.5 ratings which are not standard either.

 

I hope this was more clear?

[pgrondin]

Sorry Franky, I must have a real fog bank between my ears today.

 

From posting#1:

I prefer the way this is handled in Daminion (Tag/Reject) as this is way more flexible as an image can have a rejected/tagged and stars.

 

The downside of the different approaches is that this probably cause problems when Daminion would export a "Rejected" rating into exif using the "Rating" as both are different things in Daminion.

 

And from Murat's posting #4

But if you'll mark an image/document within Daminion by Rejected flag it will not be mapped to the Rating metadata. Because as you said above: in Daminion rating values can be used in conjunction with flag values, and changing the Flag should destroy the rating value.

 

Between the two postings I imagined that the objectives, the two of you are discussing, are to preserve Daminion's Ratings, preserve the NEF file's -1 Rejected. and independently FLAG files in Daminion.

 

If the NEF file Rating is -1 do you advocate using Daminion's Ratings as anything other than -1?

 

A FLAG variable in Daminion could carry any On/OFF/Neutral meaning/purpose any user chooses if it is kept completely independent of the NEF -1 Rating. For example, even though it is a five star photo, it may be Rejected for publication because we don't have the signed release form.

 

I would advocate completely synchronizing the NEF and Daminion Ratings (-1 to 5), and keeping the FLAG independent.

 

Please be patient with me I'm sure the fog will clear soon.

[franky68]

Sorry Franky, I must have a real fog bank between my ears today.

 

No problem. I know my writing is sometimes pretty confusing and not beeing a native speaker does not help either. So I actually appreciate you pointing out where I am unclear.

 

In particular with this subject I was a bit confused myself. Because I only realized the #3 option after I made my first post...

 

If the NEF file Rating is -1 do you advocate using Daminion's Ratings as anything other than -1?

 

I would advocate completely synchronizing the NEF and Daminion Ratings (-1 to 5), and keeping the FLAG independent.

 

Yes, thats absolutely what I am thinking too. This would give the most flexibility without causing any inconsistency with either Nikons, the current Daminion or general metadata schemes.

[pgrondin]

So, if Daminion were to completely separate the "Rejected", Rating= -1 from the Flag field, it would be necessary to change the terminology, I think, so that the "Rejected" Rating does not get confused with the "Rejected" Flag.

 

Could use Flagged/Unflag, Flagged/Hide, Yes/No, (I'm not really happy with any of these) or maybe allow the user to define the terms to suit their situation / need.

[franky68]

I think before we argue about nomenclature we should wait which direction Daminion is heading to ;)

 

But youre right - if Murat will implement the "rejected rating" instead of mapping "-1" to the "rejected flag" it probably would be a good idea to give them different names. The difficulty with finding labels is that we have three states instead of just two. Thats why I never felt happy with "Tag/Rejected" as they do not reflect this. The Lightroom nomenclature "Accepted/None/Rejected" is much better. But then again we maybe need "rejected" for the ratings - or we name of of the "rejected" "refused" instead.

 

But as said: There is really no need to twist our brains about this until we know its necessary at all and Murat does not already have a better idea anyway...

[Murat]

Good discussion, guys! My thoughts and comments:

 

1. The approach of mapping a "Reject" Rating to Flag was wrong:

 

If two different tags (Flag and Rating) will be mapped to the same metadata field (Rating) this kills the value of separating Flag and Rating values.

 

In Daminion tags with one-directional mapping (Camera Model, Lens, Exposure values, Width, Height, etc...) are read-only fields. This allows keeping them synchronized with the metadata. Flag is not read-only, so you can change it. And once you'll change it, it should be written to the metadata to provide the synchronization of tags with the metadata.

 

So if I’ll mark the image with Rejected flag (by Daminion) it should change the Rating to -1. And this should be reflected to the Rating again. So we lost here a possibility to mark the image with Rejected and Positive Rating value simultaneously.

 

So we'll not include the mapping of the Flag values to the Rating in the next release.

 

2. Using Rejected in Flag and Rating simultaneously:

 

If we'll add different implementation of the Rejected term to our UI it will add some complexity to the product: which one should I to use to reject an Image? What if I'll accidentally use both: and part of my image archive will be rejected by Flag and the other part by Rating.

Let’s take a look to big-brothers: Apperture uses -1 Rating to reject the images, Lightroom use Flag for this. If we run after two hares, we will catch neither.

 

So I guess we should to stay with just one approach.

3. So how to sync a "Reject" value between ViewNX/CaptureNX and Daminion?

 

IME there is no ideal solution. Each approach has its own disadvantages/advantages. And although MWG Specification mention that value -1.0 of rating represents a “reject” rating, I guess having a "Reject" as Flag sub-value is more flexible approach. BTW Adobe Inc. (the author of the MWG specification) uses a "Reject" Flag instead of a "Reject" Rating.

 

Probably the best way here is to sync a "Reject" value between Nikon products and Daminion by Color Label. This tag also allows having multiple Rejected values, let's say:

(Orange) Rejected for Publication, and (Red) Rejected for All. Plus it supported by short-cuts and visual marks in both products.

[franky68]

Hello Murat,

 

thanks for sharing your thoughts and ideas about this subject.

 

1. The approach of mapping a "Reject" Rating to Flag was wrong:

 

If two different tags (Flag and Rating) will be mapped to the same metadata field (Rating) this kills the value of separating Flag and Rating values.

 

After thinking this over I totally agree. Even if both (currently) are called "rejected" they are different after all. And mixing two different things is never a good idea.

 

2. Using Rejected in Flag and Rating simultaneously:

 

I still belive this is the best approach:

 

If we'll add different implementation of the Rejected term to our UI it will add some complexity to the product: which one should I to use to reject an Image?

 

Of course one has to decide which one to use and it should be easy to distinguish both. So I absolutely vote for a renaming of the current "Rejected/Tag" (I never liked that naming anyway tho I love the functionality).

 

My understanding of those is something like a temporary sort criteria. I select a couple of images (e.g. from the last shooting) and select the good from the bad (kinda like Cinderella ;)). Or I select the ones to print, give away or whatever. Of course I also can use this to determine which images to be deleted. However this is something I use for the duration of the sorting process and basicly throw away when finished. Most important: this is used even on images with different star ratings.

 

The rating however is something permament - once set I keep it that way unless I change my mind. This on the other hand only applies to images that do not have stars. I hardly permanently refuse an image with 5 stars ;)

 

So I think if the "Rejected/Tag" would be renamed to something more meaningfull (rejected and tag are not opposites anyway) the risk of ppl confusing this would be eliminated. At the same time we would gain the ability to use both approaches and could sync our data between CNX/VNX and Apperture.

 

If the "-1" is defined in the standards and used by applications I generally would think that its a smart move to implement this in Daminion. Daminion already has the halfsteps (0.5, 1.5 etc.) why not simply add "-1"?

 

This also would guarantee that ratings given in other applications would be maintained in Daminion. If Daminion reads a "-1" but doesnt have this rating natively youre again in trouble how to deal with it.

 

Probably the best way here is to sync a "Reject" value between Nikon products and Daminion by Color Label. This tag also allows having multiple Rejected values, let's say:

(Orange) Rejected for Publication, and (Red) Rejected for All. Plus it is supported by short-cuts and visual marks in both products.

 

I strongly disagree here. Many people use color marks for different things. There are a lot of tutorials that describe different approaches to use color tags to straighten your workflow. Abusing color tags for syncing data would make them loose this ability.

 

So you see, my ideal solution would be very simple:

 

1. Rename the "Rejected" tag to something else

2. Add "-1" to the set of allowed ratings

 

This wouldnt cause much work in the dev-team, give us users the most options and maintain compatibility with other applications.

[pgrondin]

This has gotten very long, and I may have gotten confused along the way. I would not feel slighted if no one cares to read all of this, or if you do read it and think it is junk.

 

This essay attempts to look at the question from the perspective of the entire range of potential users. How many ways are there to use the variables? If there are a total of five possible ways to use these variables, is it possible to accomodate all users? What has to be done to accomplish that?

 

I don't use either Lightroom or Aperture, so I am unfamiliar with how those programs use the Rejected state.

 

In what follows I am assuming that the Rejected state is used as a toggle or filter condition, essentially:

“AND NOT Rejected”

 

Trying to maintain compatibility is impossible if you are trying to sync Lightroom's Rejected Flag with simultaneous Ratings=3 , back into Aperture, CNX/VNX, which would override Ratings to reject something.

 

Do Lightroom, and Aperture have any conventions to maintain compatibility / synchronization of the Rejected state, and Ratings between their programs? Do they just ignore each other? If they have a standard convention that they use, it may be advisable to follow their practice.

 

The basic question imho is this: Which is more important to maintain when working between applications, the Rating, or the Rejected state? This is partially a set of rules the user would have to follow, and partially a set of rules the program(s) would have to follow to respect the user's decision. To a large extent, it is a user decision, so both options, in various combinations, will be used by different people, and they will figure out how to work around the program(s) limitations if they have to.

 

I have tried to put myself into the shoes of vaious users.

 

-1- The user who wants Rejected to override Ratings. He uses a -1 Rating, and does not assign contradictory Ratings in any of the programs that use the Rejected Flag. He has access to the Rejected state in all programs as long as they give prioity to a -1 Rating. When he comes to a program that uses Flag for Rejected. he wants his -1 Rating to be recognized for that program's use of the rejected state. This raises two possibilities:

 

-1a- Daminion, uses a -1 Rating directly as Rejected, and uses Flag for something else.

 

-1b- Daminion maps -1 to Flag and maps Flag=Rejected back to -1 Rating. If he changes his mind about the Rejected state while using Daminion, by assigning some other Rating to clear the -1 Rejected Rating, Daminion would have to recognize this, and clear the Rejected Flag status. If he clears the Daminion Flag=Rejected status, Daminion would have to set a Rating (Probably=0) to accomodate his wishes. In this case, the user would not be able to use the “Flagged” State without destroying his Rejected Rating.

 

That brings us to the people who consider Rating more important (dominant) and want, in general, to use both the Flag and Ratings. In this case, they have the ability to use two potential meanings of "Rejected" one, if they reject a file through Ratings, and a potentially different meaning if they reject a file through Flag while maintaining a Rating other than -1. Alternatively, they also have the ability to keep the two meanings identical.

 

There are a number of possibilities:

-2- Use Ratings completely separately from the Rejected Flag state, and never set Rating = -1.

This user would not use, or have access to the Rejected state in CNX/VNX or Aperture since these all destroy the Rating. The Rejected state would only be available in programs that use Flag for that purpose. Daminion would keep it's Rejected state as a Flag value only, but could recognize, and sync back a -1 Rating without mapping it to Flag. The Flagged state can still be used.

 

-3- Use both potential means of rejecting a file with different meanings. This user wants the Flag and Ratings to be maintained without mapping one to the other. “Rejected” has diferent meaning in different programs. Daminion again keeps the two variables completly separate. The Flagged state can still be used, (As an aside, do CNX/VNX, and Aperture recognize flag, and if so what do they use it for?)

 

-4- Rating as dominant over Flag. Map a Rating = -1 to a Rejected Flag, but do not use a Rejected Flag to overwrite a Rating. If a file has a -1 Rating this user can extend the Rejected state to more files in programs that use Flag , without that status being carried back to programs that do not use Flag. This person can use Rejected in CNX/VNX and Aperture, by setting Rating = -1, and have a more extensive rejected set in Daminion, or they can maintain a Rating while setting Rejected only in programs that support Flag. Since Rating is dominant over Flag, the Flagged state cannot be used.

 

I think that covers the range of posibilities. To summarize how Daminion responds in each case as the user does something. (I have changed to order of the cases for clarity).

 

--------------------------------------------------------------------------------------------Flag status changed to:

--------------------------------------------------------------------------------------------Flagged------Cleared-----Rejected

User---| -1 Rating Read------rating set to -1 -------Rating set to 0 to 5 -----Rating changes to:

 

-1b----Set Flag=Rejected ---Set Flag=Rejected ---Flag cleared ------------Not used - -- Set to 0 ---- Set to -1

-4-----Set Flag =Rejected ---Set Flag=Rejected ---Flag cleared -------------Not used-----No change to ratings

 

1a- Rejected Rating is used directly – Completly independent of Flag

-2- Rejected Rating is not used – Rating is completly independent of Flag

-3- Rejected Rating is Completly independent of Flag

 

So, for three of the five cases, Flag and Rating are completely independent. Case 1b can be replaced by Case 1a as both achieve exactly the same result.

 

In cases 1a, 2,3 Rejected is implemented directly on Rating, and the Flag choice is renamed to avoid confusion. Maybe Choosen/blank/Hide?

 

That leaves us with Case 4 as a potential configuration option.

Radio button – Map Rating = -1 to Flag = Hide (one way)?

 

I hope the table formatting is readable.

[franky68]

Ok, this is way too complicated for stupid little me. But actually this is why I suggested not to do any mapping but keep ratings and the tag seperate without mapping. Thats so simple even I can understand it and wouldn't require any complicated mapping rules ;)

 

I thought thats what you suggested in #10 yourself?

[pgrondin]

I suggested keeping them separate, and then realized there was potentially a bigger problem when using a wider range of software, so I tried to do a comprehensive look at it. (Not sure I succeeded)

 

I don't think the conclusion is much different, except for #4 which is a possible way of wanting to work, but it's a real stretch to see why anyone would want to do it.

[Murat]

I hope the table formatting is readable.

 

Forum engine doesn't provide built-in table formatting so you can insert it as an image or attached an xml file. But now it's very difficult to read it.

 

Peter, the #4 has a significant drawback: when you mark image as rejected, the remove the image from the catalog and then import it back again you will lost the Flag status.

 

At the moment I don't see the affordable solution for the Rejected mark, so I suggest to leave it as is for some time. Until a better decision will be obvious. Probably we'll receive an extra feedback that might helps.

 

I leave this issue status as open.

[franky68]

At the moment I don't see the affordable solution for the Rejected mark, so I suggest to leave it as is for some time. Until a better decision will be obvious. Probably we'll receive an extra feedback that might helps.

 

Ok, I admit I am a bit impassionate when it comes to CNX/VNX compability ;)

 

However even if you decide to leave this open it might be a good idea to at least change the wording for the current "rejected" to avoid confusion:

 

a. when importing images that already have a "rejected" ppl might wonder why it doesnt show in Daminion rejected

b. if you decide to add a "rejected" rating (-1) its better to distinguish if the names are different

 

Maybe "declined" or "disliked" would be better?