Just to expand in this a little: It appears that the KYNO beta is writing incorrect duration numbers (3901?) for stills in the xml file (should be zero). If I hand edit the duration numbers, then the file loads stills correctly into Resolve.
Also, Resolve can handle numerically sequential still images as either individual photos, or as an image sequence to be treated like video. The KYNO interface will presumably need a "switch" so that the user can dictate whether or not the still images being sent to Resolve are to be treated as a sequence or as individual photos.
Hope this makes sense. THANKS!
thank you very much. That's very helpful input. The non-zero duration is consistent with what e.g. Premiere does when exporting FCP7XML and I am guessing Final Cut 7. I tested the following in Resolve with a PNG file:
- Import an XML exported with Kyno
- Import an XML exported with Kyno after manually setting duration to 0
- Import the file into Premiere, export it to XML and then import that into Resolve
All showed the same result. The file is detected as type STILL with 1 frame duration and couldn't see any difference in their behaviour either. Could you elaborate on the differences you see?
Regarding the sequences, do you have an example of an FCP7 XML file that successfully imports into Resolve as an image sequence?
Welcome!
Note that I am on Windows 10, so behavior may be different from what you see on a Mac.
I re-tested using 6 sequentially numbered stills:
If I send from Kyno, the still names look right, but the duration is wrong (3901 frames) and the type is video (wrong).
If I open a timeline xml sent from Vegas, the duration is correct (1 frame) and the type is Still (correct.)
I have never imported an image sequence into Resolve via XML, and was unable to get this to work from Vegas - I will try again later.
I can send you a complete folder with Kyno config, stills and Vegas XML and log if you want - just let me know how.
Regards, Mark.
Actually, on second look, the imported file names from Kyno are wrong (e.g. ...0570-...4470)
Sorry for confusion... Old eyes. :)
Here is an XML generated by Kyno (metadata export, FCP7 XML) showing the strange 3901 duration.
No success getting a XML of an image sequence from Vegas to Resolve, so I just tried exporting and then re-importing a Fcp7 xml of an image sequence from Resolve. That worked ( as expected) and may help you to discover what the issue is.
Good luck! Looking forward to the next beta :)
Great thanks, we'll look into it!
OK, but that's an NLE-level sequence in the XML which is a bit of a different beast. We will do some thinking but this is not likely to make it into 1.8 as it is a bit more complicated and will likely require more than a checkbox in the "Send to" dialog.
Thanks again
From my point of view support image sequences is not needed as I use them rarely and Kyno doesn't read them normally when browsing anyway (I only uploaded an XML for that use-case because you asked.)
IMO, support for sending stills, however, is very important as it's quite common and also part of Kyno's browsing support.
Just to add my 2c .... this "bug" has been biting for quite a while now, and is still breaking my workflow whenever I try to batch / bulk import still images into Davinci Resolve.
I appreciate that Kyno is now effectively dead, although I keep reading reports that it is being "actively supported" ... however this bug being prevalent for 3 years would kind of indicate that the reports of Kyno's demise have not been exaggerated :(
It should be a relatively simple fix where images are not part of an image sequence ... and I'm not entirely sure where the magic number 3901 is coming from ... but changing this to 0/1 would certainly resolve the immediate problem as far as I can see, and would surely be an easy patch for a 1.8.6 ? (wishful thinking I know)
Randy Burleson