Open Clip Shot Publish Problem

Flame Flame Questions
1

Hello everyone,
we have a strange problem with the Open Clip EXR shot publish workflow.

workflow is as followed:

  • in shot sequence create batch groups
  • in batch, comping and than render via write node with open clips enabled and “add to workspace”
  • swap (replace media) the rendered open clips from the library into the created batch group in V2 in the shot sequence
  • now, when we want to publish the shots in the shot sequence with “Link Media”
    flame is generating new EXR sequences instead of linking them.
  • when we replace the rendered EXR sequence instead of the open clip, then flame is publishing the EXR sequences correct…takes only some seconds instead of minutes and the EXR files 100% identical.

perhaps someone has an idea…
thanks

2

Im going to admit that I dont understand Link Media. I use Link Media (Bit Depth) all the time to preserve the camera metadata from EXRs made in Resolve or Baselight when publishing shots. It definitely generates new EXRs, but it copies them or something… unsure what happens… instead of generating a completely new EXR without this previous metadata. I would have expected it to make symlinks but that doesnt seem to be what it does.

3
4

Ah ok… hardlinked. Read up about it. Well it fooled me. Looks like a new file to me without looking up inodes in the shell and whatever. Symlinks might have been more user friendly… but im sure there was a reason.

5

@knhn -

hard links use the same inodes and can have multiple pointers (filenames)
soft or symbolic link (alias/shortcut) points to a file

let’s create a few test files:

# Make 3 folders
mkdir folder_A folder_B folder_C

# List the contents of the present working directory
ls

# Create a new file in one of the folders
touch folder_A/file_A

# Put some data into the newly created file
echo "some_data" >> folder_A/file_A

# Read the contents of the file
more folder_A/file_A

# List the inodes of the file
ls -i folder_A/file_A

# Create a soft link to the file in a different folder
ln -s $(realpath --relative-to="folder_B" "folder_A/file_A") "folder_B/file_B"

# Read the contents of the soft link
more folder_B/file_B

# List the inodes of the file (should be different to file_A)
ls -i folder_B/file_B

# Create a hard link to the file in a different folder
ln "folder_A/file_A" "folder_C/file_C"

# Read the contents of the hard link
more folder_C/file_C

# List the inodes of the file (should be the same as file_A)
ls -i folder_C/file_C

# Delete file_A
rm -v folder_A/file_A

# Read the contents of the soft link
more folder_B/file_B

# Read the contents of the hard link
more folder_C/file_C

This shows you (in very simplified terms) how you can start to get to grips with soft or hard links.

When exporting from flame, every characteristic about the export must remain the same as the input, you cannot disturb any of the source data - flame just acts as a friction free conduit - as if you were soft-importing and just exporting a pointer for each file.

For hard links the files must reside on the same disk.
For symbolic (soft) links the files can be on the same disk or on a different disk.

If you delete all hard links then your data is gone, but if there is at least one pointer remaining then your data is still intact.

If you delete symbolic links, the source might still be available.
If you delete the source for symbolic links then they become stale pointers.

2 Likes