Colors

[JACalvo]

By the software operation, I suppose you cant disallow a color from the list simply by leaving its name blank. And, if you try to disallow more than one of the colors, a "color names must be unique" error appear; I suppose it should not

 

Also, if you edit various times the color name list, you'll get a funny list of old and new color names on the Properties and Catalog panes

[kalain]

Yes color names has to be unique. (a warning message remind you this)

 

I agree with you, What's a bit strange when editing color label name is to have a pre list name.

This is a bit confusing because it suggest you that you can change color label name with only list content.

 

It would be better to have a single editable field.

 

Anyway, you can change names as you want.

 

[Murat]

By the software operation, I suppose you cant disallow a color from the list simply by leaving its name blank. And, if you try to disallow more than one of the colors, a "color names must be unique" error appear; I suppose it should not

 

Will be fixed. Thanks. As a workaround I can suggest you to remove unnecessary Color Labels by "Remove" option in the context menu of the Tags tree.

 

Also, if you edit various times the color name list, you'll get a funny list of old and new color names on the Properties and Catalog panes

 

According to XMP/MWG specification XML:Label is a textual user-defined field. Colors are just helps to visually group and distinguish various labels.

 

Alain shows a nice sample of Label set.

[kalain]

Following this discussion, I do not see the interest to have a choice list here rather than a single and simple editable field.

When having a choice list, most of the time user focuses in proposed choice available in the list and do not think one second these choices can be overwritten. (Most of the time, it's like this in a software.)

 

It took me a long time to know these fields could be editable.

 

With a single and simple editable field this is more obvious.

[Uwe]

Also, if you edit various times the color name list, you'll get a funny list of old and new color names on the Properties and Catalog panes

As far as I understand the background of Daminion in this case, Daminion uses the text of the Color Label as unique key even if it organizes it in the DB table in an other way (see screenshot, example from Server Db for shared catalogs).

That means:

1. every time you change the text of a certain color, egg. from "Red" to "my_color"

2. assign this label to an item

3. writes the metadata to the file (the XMP:label tag is written with your "my_color" value

4. read the metadata again

your text "my_color" is a new entry in the table of the Color Labels in the database. This should be the reason for your "funny list of...".

From my point of view the Color Label belongs to the basic customizing and should be defined before you start to assign tags to an item. kalain did it in a way I like it and this explains very easy what the meaning of a certain color is. Without this "redefinition" of the text of the Color Label the text is just a explanation of the color without a business background, defined here in Daminion.

 

One question remains from my side:

See the screenshot above: I've imported a file with the "XMP:label=Lila" (raw 11). This Label was assigned by Adobe Lightroom. The import into Daminion assigned to this new Label the default color. But if you define a new lable (raw 12 and 13) by Daminion (right click on Color Label tag) you don't get the default color assigned to your new entry.

But I don't want to open a discussion about the question: does Daminion need a Color Management for the Color Label tags. If anybody is interested in this function - please open a new post.

 

Regards, Uwe