Colours Renaming

Is there a way of changing the names of the colors in the desktop? It would be very helpful if several people work on the same libraries/timelines.

1 Like

You currently can’t rename label colors. You can, however, upvote this guy here:

label what color codes mean

4 Likes

I’ve never been at a facility big enough to warrant using Shotgrid. So I wish flame had more in the way of collaboration between a few artists and a producer.

I’m constantly coloring things to remind myself what’s been approved, rejected, etc. But there’s no way to tell others what those colors mean unless I just write it down on paper.

1 Like

I agree.

I was gunning for a little checklist node (bonus if it worked with shotgrid) where I could put all the tasks and notes into a batch.

Not the most wold shattering feature, I know. And I know you can use the notes to kind go do this, but I’d love a checklist.

As it stands I use Apple’s Notes app and make my note checklist float over all windows.

Being able to alter and name the color set would be very useful.

1 Like

This is actually something I am looking into right now and I have a question for you. How would you like to deal with this use case:

User 1 created these label:

Green = completed
Orange = To Do
Red = Rejected by supervisor

This user pass this project along to another user (let’s imagine a freelancer added to finish the project or an archive opened a year later). That user has the following labels:

Green = completed
Orange = Rejected by supervisor
Red = To Do

How would you “merge” labels when they are not set to the same thing?

Possible solutions could be:
1- Users will have to coordinate
2- Labels could be project-based
3- Present a warning when the labels are not the same.
4- Save the label in the segment metadata and automatically adjust the colours.

Any preference? Another idea?

3 Likes

:thinking:

Ah man this is tricky. So much easier just to vote on the feature request and hope that @fredwarren can sort it out.

I was going to say project based (2) but then we are often sharing jobs across the Tasman and not everyone starts their project by loading someone elses project archive.

It would probably end up being another idea or closer to (4) so that when I save a timeline with colour coded labels on clips. If User 2 restores my timeline they get my colours and my labels but they might not match theirs but thats is ok because the label tells them what my code is :thinking:

Yeah. This is harder than I thought

3 Likes

I think project based is smart as it allows a user to have different labels per project but that doesn’t solve the conflicts (like @PlaceYourBetts mentioned). I think I’m echoing their thoughts, in that it would be project based but when copied to another project it’s segment based.

Definitely harder than it sounded at first.

1 Like

My first thought is… you have a facility wide SOP and everyone follows it. Yea right!

I think it should be project based. When the project is handed over, the second artist should continue with the established settings of the project. The actual color isn’t as important to me as long as the status is consistent.

As a solo flame artist I thought I would want to be able to make any combination of RGB along with any label I wanted. But seeing Fred’s question now I think the software might need ‘hard coded’ labels like approved, rejected, work-in-progress, etc. You might run in to someone naming a status “Work In Progress” and someone else calling it “In Progress”. What do you do then with those kind of variations?

I currently use:

  • work-in-progress
  • killed (rejected or abandoned)
  • color grade done (effects not done)
  • effects done
  • approved
  • shipped (not yet archived)
  • archived

One more thought - on a big project we might assign shots to flame artists and each artist has a color. They can quickly grab from a shared library all the shots that match their assigned color. I assume that could be project based as well?

1 Like

I think option 4, but in most cases option 1 will be sufficient.

And I’d take any version of this versus waiting for a perfect one, whatever that might be.

2 Likes

Project based

Project based

@fredwarren Totally prefer something like option 4 but would definitely take something like option 2.

We’ve been using colors to delineate each User’s Desktops or BatchGroups and not status for years. Each user picks a color and the shots inherit their color. So status colors might never get used at all. Unless the username (or nickname) can be assigned a color…

When we do longform, the status is determined by the layer in the episode timeline. That status is linked to an external shot tracker and segment movement up and down the timeline layers updates the tracker. The shots work their way up the layers from QTRef to DI Approved (eternally grateful for track names).

When we do shortform, the status is determined by a pool of available shots and the presence of segment markers containing directions and notes. Nothing in the pool, nothing with markers = ready to sweatbox.

If we’re on this topic, I would throw this out there: it’s REALLY helpful to have two status states for every shot. It’s because there can be cycles within cycles - each stakeholder can have their own set. I.e.: internal approval (steps a, b, c, etc. for that), CD approval (steps A, B, C for that) and Client approval (steps 1, 2, 3 for that).

But this is not the same thing whatsoever as @andy_dill 's idea about a checklist. The checklist idea is HUGE. And however things get reviewed before moving along to the next step, having checklists to make sure everything is addressed is an excellent way to work. If that gets done in a node, or on Shotgrid, or in Notes (I also use this), or in Slack, or email, or Texts, or from FrameIO to Markers… you get the point - having data flow from outside Flame to inside is really helpful.

2 Likes

I’d offer a slightly different idea but still being project based. If we could just load a preset at project creation like we do for color policy that probably makes the most sense. Set up a label policy, save it as a preset on the network and load at project creation. I would offer love if the label selection gets written into openclips and part of the policy being what color to set new renders to.

2 Likes

(2) Project based
And I love @cnoellert’s idea of a a central labels policy, similar to colour policy.

Hard-coding colours to specific labels isn’t great because there’s such a wide variety of workflows and use cases across different Flame users. eg Lots of users would want a label specifying graded/ungraded… but for the last few years 90% of our Flame work has been pre-grade, so those would be wasted labels for us.

Great to be able to offer opinions while you’re actually working on this @fredwarren!

I also love the idea of a preset label policy being created at project creation.

Agree with not wanting a hard-coded solution, my use case is currently different than most of the above in that I send shots to other artists (nuke) and label them accordingly along with my own colors indicating where I am with a shot and whether or not it has any effects at all.

I have another question on that topic. Would you expect the ability to have separate “labels policy” for media panel entries, markers, and timeline segments or they should all share the same labels?

1 Like

I would say same labels

3 Likes

Same labels.

4 Likes

Same labels please!

3 Likes