Full set of traffic lights

This may seem trivial, but bear with me. A radical suggestion to improve workflow :slight_smile:

Add an amber light to the existing red and green for selection. This would enable a faster workflow for:
red = delete
amber = archive (keep but do nothing with. For moving to a separate archive folder)
green = edit (later)

Now I have green and non-selected (i.e. not to be edited) files that I can apply the full set of star ratings e.g. how much I like them.

These three traffic lights existed on OpticsPro and they were suppressed (version 9 or 10 ?) to facilitate the interface.
Pascal

Oh dear. I think with more RAW processing these days, we need workflow steps. Iā€™d like them back please!

This would be quite useful. I would make use of it if available.

Need to vote for it :slight_smile:

Fun i have the same thought only a other kind of meaning of the colors.
Green, ready to export. (i would like a auto lock function coupled to the green button. So you need to create a /get a VC to edit further or change green to amber.)
Amber, yellow, in proces of processing, not ready yet.
Red, rejected but archive.
(i delete i images who are bad on the spot.)

:slightly_smiling_face:

Hi, too bad also that PL doesnā€™t recognize colors in xmp files. I use fastraw viewer to make quicker selection (PL is too slow for that)

Haha, la bonne blague ! Lā€™exemple mĆŖme de la fausse bonne idĆ©e. Jā€™ai toujours regrettĆ© cette disparition, pour ma part. Ā« It was a better time than nowā€¦ Ā»

VoilĆ  !

The red color blocks processing and most people use them for this purpose. So red is in progress and green is ready to export. If XMP color labels would overrule them, this would create huge headaches. So I am actually happy that color labels are PhotoLab dependent.

But it would be great to see support for XMP color labels edited (e.g. square colored flags) for extra workflow flexibility.

My opinion is that DxO should facilitate different workflows without dictating them.

E.g. support ratings, color labels and pick/reject flags. Also allow to export keywords to .XMP but make it optional to overwrite existing .XMP settings.

Hi Peter. The reason I donā€™t want to delete on the spot is that it slows the workflow down. I like the ā€˜are you sureā€™ check, but when Iā€™m zipping through my pics Iā€™d like it seamless. So quickly select red, amber, green then come back to deletes later.

To add to my own comment, Iā€™d like to select a RAG status and have the filmstrip automatically move to the next status. This makes for fast culling.

1 Like

There is a lot to be said for pick/reject not being associated with colour. Everywhere else Iā€™ve seen it, itā€™s a tick/cross type of thing with nothing for the middle (default) state. Other options could be a highlight of some kind such as a brighter/dimmer border and/or fading of rejects.

I only use pick/reject as a temporary state ā€“ for picking those I will process and publish, so I can filter out everything else. Once thatā€™s done, I turn off the picks ā€“ though in PL maybe not because I canā€™t filter by ā€œeditedā€ like I used to in Lightroom.

I used to use a colour label to mark, after the fact, images I had uploaded to Flickr, which was a subset of edited images.

Not sure I get what you are saying. Are you arguing that there should only be one state and not even two? With the current two options there is always a middle state, where neither is selected.

Hi Gary, I use other application and zipp, cull outside DxOPL
The oneā€™s i load in are mostly in focus, framing ok-isch, some part of a burst. object is hole and inframe.

Then i open DxOPL, (donā€™t bother yet to keyword and tag the rawfiles itā€™s no use until DxOPL can export the tags from rawfile source.)
go from left to right and when i hit ā€œredā€ it disapears from the filmstrip.
because we donā€™t have "amber"or ā€œyellowā€ i use the star-rating as development state before export ready.

  • halfway not ready (rawfile)
    ** halfway tiff file of VC or just a VC
    *** fool around to see if i can get a new look
    **** and ***** never needed it. (sometimes i go ***** for ā€œthis one is quite niceā€)

Well i hope the labels are free to use how ever we like as we have now.
(i really like a ā€œlock functionā€ now i just copy paste the DOP-files in a subfolder inside the source folder as a form of backup.So when i meshed up i can go back and copy the backup back in.(hope dop is first on DB of hierarchy and not viceversa.)

A lock function would be nice if itā€™s enabled automatic when we Export to disk/web. So no change on dop and DB on that file unless i change it to ā€œunlockā€.
ikons
The v is labelled as ā€œDoneā€ and ! is labelled as ā€œprocessed but needs to be updatedā€.
One problem is if you by accident change a ā€œdoneā€ and go back by ā€œundoā€ the ! isnā€™t changed back to ā€œvā€ So you donā€™t know if you have a ā€œamberā€ state or a ā€œgreenā€ state any more unless you export again and overwrite the old file.

(a lock function as in ā€œ:white_check_mark:ā€ Done(exported) and locked and :heavy_check_mark: done and unlocked (exported,used for export to application) would be a nice feature in the future)
(the grey corner is a already there so only color and function adding no change in appearance and space for icons.)

DxO is developing there DAM functions so this kind of functions are most likely in there backlog to implement. Same as taggs and keyword passthrough. We have to be patient en support them with ideaā€™s.

When I say ā€œnothingā€ for the middle state, I mean it needs no display indication (as currently). Iā€™m also saying the use of colour can be confusing when there are also colour labels. PhotoLab does not have colour labels so it is arguably of less importance, but people are talking about other softwareā€™s use of them and how PL might interpret them from metadata.

Most other software Iā€™ve used has up to three systems of marking images.

  • Pick/reject uses either highlight/dim and/or āœ“ and āœ˜ (and absence of either for the middle state) or similar and infers best, worst, and neither/donā€™t-know.
  • Rating is a star-based system and implies a continuum ā€“ 3 stars is better than 2 stars or 1 star but not as good as 4 or 5 stars.
  • (Colour) labels are arbitrary discrete categories and in some cases you can assign multiple (such as native macOS).

So PL using colour for pick/reject is unusual (in my experience) and potentially confusing when it comes to interaction with other software, either with import/export of metadata or even people switching between applications.

Like the current photo in the library is highlighted with a paler frame, so ā€˜pickedā€™ images could be highlighted, though differently. Perhaps a thicker white border on the image. ā€˜Rejectedā€™ images could be dimmed. This makes this simplest of markings very obvious at a glance (compared with small coloured dots) and breaks any association people may make with colour labels in other software.

Hereā€™s a quick mockup of what I mean by highlight/dim ā€” I have picked three and rejected four. Though I think the highlight might also need a brighter frame (the grey surround on which the name and icons appear) and then the selected image a brighter frame still.

Rejected images might do well to have a dark border or something to distinguish from underexposed images.

Hello guys,

Iā€™ve brought good news for you - we have already created a story on color tagging, so I hope this is exactly what you need :wink:

Let me close the request to release your votes.

Regards,
Svetlana G.

3 Likes