This may seem trivial, but bear with me. A radical suggestion to improve workflow
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.
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.
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.)
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… »
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.
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”.
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 “” Done(exported) and locked and 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.
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
Let me close the request to release your votes.