<br><br>On Monday, March 7, 2022, Andrea paz <<a href="mailto:gamberucci.andrea@gmail.com">gamberucci.andrea@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">>( Phyllis):<br>
> When I used the ffmpeg/tiff render format, it created the toc file but it was empty even then.<br>
> Also ran the CinGG version of 11/2016 and 2/2018; in both cases the toc file was either empty (the earlier ones) or just the first 4 lines.<br>
> So I think it never worked right and the workaround as Andrea tested it to create the toc file manually.<br>
<br>
Sorry to insist, but I think DPX support is very important.<br>
<br>
It would take more testing by other users. As I wrote in a previous<br>
message, some versions work for me, and even in Arch, DPX and PNG used<br>
to work for me (not anymore, now).<br>
<br>
@IgorBeg<br>
Please, can you test the rendering of a sequence of images (it only<br>
takes a few seconds), since you normally use Ubuntu 16?<br>
<br>
> I assume the ffmpeg command line creates it?  I have not had the chance to try that yet.  Does it?<br>
<br>
FFmpeg creates the images with a command (muxer) that implies %05d in<br>
the name and then, thanks to the image2 command (demuxer), it reads<br>
them (without the need to create a TOC file) and creates the video. It<br>
occurs to me that CinGG presets create the images via %05d and then,<br>
instead of being read by image2, the TOC file (not the video file!) is<br>
created and can be imported into CinGG (or other program). Perhaps a<br>
version of "imagelist.sh" is implemented? In short, the difference<br>
between ffmpeg and CinGG is the creation of the TOC file.<br>
<br>
I remember that my hypothesis about the problem is the management of<br>
absolute/relative paths, since the TOC is created and works: only the<br>
links are missing. </blockquote><div><br></div><div><br></div><div>I am not sure it was designed as cross-application support? I mean, cingg can  load both TOC types, so it works... </div><div><br></div><div>Are you concerned about more self-contained toc file for inter-application operability  or self-documentability reasons? </div><div><br></div><div>How other apps (like Natron?) handle this? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is it possible to trace a patch that has touched<br>
the paths? If not, I'll say again that it's better to delete these<br>
presets and the related entries in the manual altogether.<br>
<br>
[ffmpeg reference:<br>
<a href="https://www.ffmpeg.org/faq.html#How-do-I-encode-single-pictures-into-movies_003f" target="_blank">https://www.ffmpeg.org/faq.<wbr>html#How-do-I-encode-single-<wbr>pictures-into-movies_003f</a><br>
<a href="https://www.ffmpeg.org/ffmpeg-formats.html#image2-2" target="_blank">https://www.ffmpeg.org/ffmpeg-<wbr>formats.html#image2-2</a><br>
<a href="https://www.ffmpeg.org/ffmpeg-formats.html#image2-1" target="_blank">https://www.ffmpeg.org/ffmpeg-<wbr>formats.html#image2-1</a>]<br>
</blockquote>