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:
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
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
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