different color codes for RAW, JPEG, TIFF and other mappings

[rjp]

I would love to have the ability to have color codes or some other distinguishing feature be automatically applied to photos on a contact sheet to clearly identify different file types at a glance. For example, have all RAW files have a Yellow border, and all JPEGS have a green border.

Even better would be to make a general code change that would allow the user to map any desired variable to the existing color classes. Lots of useful things could be done if this were possible. For example, all photos with ISO = 3200 might show up red if desired, or everything with a particular lens blue, etc. I believe this flexibility would add to the value of the product.

It would also be nice to have a new variable for "has_been_edited" which would be true/false, which would also map nicely to a color class.

Rich

[Hayo Baan]

I would love to have the ability to have color codes or some other distinguishing feature be automatically applied to photos on a contact sheet to clearly identify different file types at a glance. For example, have all RAW files have a Yellow border, and all JPEGS have a green border.

While I can see a reason for you wanting this, it is not a straightforward thing to ask for. First of all there are very many file formats, how big do you need the colour scheme to be, and what colour to apply to what file type, etc. I guess this could be made configurable, but that will be quite a lot of work I guess.

In the meantime you can of course sort by file type to ease identifying the type of file.

Even better would be to make a general code change that would allow the user to map any desired variable to the existing color classes. Lots of useful things could be done if this were possible. For example, all photos with ISO = 3200 might show up red if desired, or everything with a particular lens blue, etc. I believe this flexibility would add to the value of the product.

Phew, this is a feature that sounds great on paper, but how is this going to work in practice?

Perhaps a way this could be implemented is to allow the user to set the colour class and rating in the iptc stationary via an entry box. The content of the entry box should then result in a value between 0 and 5 for the rating and 0 and 8 for the colour class. This way you could use code replacements to get the results you want. E.g., \LT{lt}\ to set the colour class to match the lens used. A code replacement for the lens should then of course exist, resulting in a number between 0 and 8.

Sorry, but I would not see this a a real important feature though and think Kirk et al currently have more important things on their mind (like the catalogue functionality).

It would also be nice to have a new variable for "has_been_edited" which would be true/false, which would also map nicely to a color class.

How is PM going to determine if a file was edited for sure?

Anyway, you can achieve this (in a way) by using the variable {software}, this will show you what software (or the camera) last touched a file.

Cheers,

[rjp]

I believe one of the strongest points of PM is it's use of variables. I agree that this might not apply to a wider audience, but as an engineer myself I find it very satisfying. What I like is the ability to customize my PM experience using these variables. I think it would be a very natural extension of this already excellent feature to be able to actually *do* things based on these variables in a future release. Perhaps I should say do more things since clearly some things can already be done. For example, based on variables of my choosing I can sort images, I can name files, and I can modify the information displayed below each image on the contact sheet. This is great! I would like to see more and more customizable features like these based on variables, one of these would be color tagging.

I agree this is not as important as the database feature everyone is waiting for, but I also think it would be a relatively easy feature to implement with very little code change, so the bang-for-the-buck ratio would be high. The reason is because the variables framework is already there and the color class framework is already there. It would seem to be a rather minor enhancement to be able to connect these together. Clearly the color class is stored somewhere at some location in the image file, so instead of having color equal the value stored here you would make color equal to the value stored at some other location (i.e., one of the variables or a function thereof). The mapping of colors to variables would be setup by the user under the preferences menu. I'm sure the PM software engineers already know this. What it really comes down to is what features are worth spending development time on, and If I'm the only one who could envision using such a feature, I understand there is no good business case for developing it.

For my part, I just wanted to present the idea for consideration, and hopefully a little discussion. I don't believe any other photo app do this sort of thing at this point. PM could be first.

[Hayo Baan]

RJP,

I guess we're on the same level after all then; I too love the control and possibilities that the {variables} offer you! Certainly one of the strong points of the application!

Anyway, what did you think about my idea regarding a possible implementation for this all using e.g., code replacements to set the colour code/rating? This imo. could be very powerful and flexible as well as relatively easy to implement (as far as I can tell though; using my designers/programming experience as a guide here)

Cheers,

[rjp]

RJP,

I guess we're on the same level after all then; I too love the control and possibilities that the {variables} offer you! Certainly one of the strong points of the application!

Anyway, what did you think about my idea regarding a possible implementation for this all using e.g., code replacements to set the colour code/rating? This imo. could be very powerful and flexible as well as relatively easy to implement (as far as I can tell though; using my designers/programming experience as a guide here)

Cheers,

I wanted to respond to your idea, but I have never used the code replacement feature yet, so I did not fully understand what you were suggesting. What I would like to do is read it over more closely this weekend and then get back to you. If you would not mind perhaps you could elaborate a bit more on how your approach would work. I am very interested to understand your idea.

Suppose we started with a simple example of making all RAW files appear yellow. I believe there are at least two variables that can be used to determine if a file is RAW. I don't have PM here at this PC, so I can't say for sure, but I believe they are {type} and {quality}.  How would we implement the equivalent of the following with your idea? Hope you don't mind if I use C code to express this question.

if (quality ==  RAW) color_class = YELLOW;

[Hayo Baan]

I wanted to respond to your idea, but I have never used the code replacement feature yet, so I did not fully understand what you were suggesting. What I would like to do is read it over more closely this weekend and then get back to you. If you would not mind perhaps you could elaborate a bit more on how your approach would work. I am very interested to understand your idea.

Suppose we started with a simple example of making all RAW files appear yellow. I believe there are at least two variables that can be used to determine if a file is RAW. I don't have PM here at this PC, so I can't say for sure, but I believe they are {type} and {quality}.  How would we implement the equivalent of the following with your idea? Hope you don't mind if I use C code to express this question.

if (quality ==  RAW) color_class = YELLOW;

Excellent, I like programmer logic

Anyway, with my suggestion there would be entry fields in the IPTC and IPTC Stationary dialogues with which you can set the Colour Class and Rating. These fields would need to be filled with a numeric value, matching the colour class and rating you want (I suggest that any value outside the allowed ranges would result in the value 0, i.e., not set).

Assuming that colour class Yellow has the numerical value 3 at your end (as is the default), we would need to set up a code replacement that translates the image type to the value 3 in case of a RAW file. The quality variable is indeed a good candidate for this; as far as I can tell now, this variable contains "RAW" whenever it is a RAW file (type is usable too, but then we would need separate entries for each type of raw file, e.g., NNEF, CCR2, etc.).

The code replacement in this case is very straightforward:
Raw    3

On the IPTC (Stationary) Pad, you would then just need to set the field Colour Class to \{quality}\ to get the result you wanted. Simple eh?

Cheers,

[rjp]

I wanted to respond to your idea, but I have never used the code replacement feature yet, so I did not fully understand what you were suggesting. What I would like to do is read it over more closely this weekend and then get back to you. If you would not mind perhaps you could elaborate a bit more on how your approach would work. I am very interested to understand your idea.

Suppose we started with a simple example of making all RAW files appear yellow. I believe there are at least two variables that can be used to determine if a file is RAW. I don't have PM here at this PC, so I can't say for sure, but I believe they are {type} and {quality}.  How would we implement the equivalent of the following with your idea? Hope you don't mind if I use C code to express this question.

if (quality ==  RAW) color_class = YELLOW;

Excellent, I like programmer logic

Anyway, with my suggestion there would be entry fields in the IPTC and IPTC Stationary dialogues with which you can set the Colour Class and Rating. These fields would need to be filled with a numeric value, matching the colour class and rating you want (I suggest that any value outside the allowed ranges would result in the value 0, i.e., not set).

Assuming that colour class Yellow has the numerical value 3 at your end (as is the default), we would need to set up a code replacement that translates the image type to the value 3 in case of a RAW file. The quality variable is indeed a good candidate for this; as far as I can tell now, this variable contains "RAW" whenever it is a RAW file (type is usable too, but then we would need separate entries for each type of raw file, e.g., NNEF, CCR2, etc.).

The code replacement in this case is very straightforward:
Raw    3

On the IPTC (Stationary) Pad, you would then just need to set the field Colour Class to \{quality}\ to get the result you wanted. Simple eh?

Cheers,

Ok. I get it now. Yes, if PM introduced a new field for "Color Class" in the IPTC pad and we could set this field to a variable this would do the trick. Assuming, as you said, that code replacement could be used to map the text values to numbers, like RAW to 3 in your example. Another possibility would be for PM to allow functions of variables to be used rather than just variables alone. For example, a primitive function like a test for equality such as {quality == "RAW"} would equate to 0 if false and 1 if true.

I also noticed that there is already the ability to map the urgency field to a color class. At present the urgency field can only be set to a number from a pull-down menu. If this could be changed to allow urgency to be set to another variable we could then set colors based on variables. This is practically already in place! Just need to make allow the use of variables in the urgency field (and not make the field go away when choosing to map it to color class).