Support for import of SVG image sequences.

[Melvin K]

I'm looking for an efficient way to get an SVG image sequence into OpenToonz as a single vector level. I am exporting the SVG files from Cacani. It does not seem possible to import the images as a sequence, but it is possible to import and merge the files into a single level. The process is, however, very time consuming, especially for longer animations. I have outlined the process below.

1. Create new Toonz vector level with number of frames in imported animation.
2. Import SVG image sequence. Each drawing is imported into it's own cel.
3. Shift each SVG image over to to it's position in the sequence (each level has to remain in it's own cel for a multi-level merge to work.)
4. Select all levels and use the 'Merge Levels' command.
5. Shift the resulting level so it's centered on the canvas (SVG images' top left corner is centered at import.)
6. Ungroup the contents of each frame one-by-one (the groups created by the merge are OK but Cacani imports end up with each stroke grouped individually which cannot be colored.)

I can write a script to arrange the imported SVG sequence but everything else has to be done manually. The option to convert an sequence of SVG images into a single vector level would be greatly appreciated.

[Jane Eyre]

What naming system are you using for your svg? If you rename them to something like name_001.svg or name.01.svg, they should load as a sequence.

[Melvin K]

*.0001.svg

They don't show up as a sequence in the OpenToonz browser and it throws an error if you try to import a sequence like that.

I've been converting everything to Toonz Raster levels up until now--raster image sequences show up and convert correctly using that naming scheme. Maybe there's something wrong with my configuration.

EDIT: The error is "FILEPATH\a.0001.pli: Error file doesn't exist" when trying load a properly named svg sequence into OpenToonz. I'm using windows, latest nightly build.

[Jane Eyre]

Interesting. I’m also seeing this with MacOS. I would think this is a bug/oversight.

[ManongJohn]

Definitely a bug. Especially that error with the .pli file.

Please enter a bug report on Github.

Thanks

[Rodney]

I'm curious what other programs deal well with animated SVG or sequences of SVG.

I see those two SVG related animation approaches as different and suspect the more useful for us with OpenToonz will be the sequences as the animated coding isn't something we might expect to see in OT any time soon and would be better served via external programs and divining into the code of the SVG itself.

[Melvin K]

SVG is an open format so it's excellent as go-between when transferring work between tools. Most vector graphics tools can import/export SVG--though I can't, at this moment, think of any other tool that exports an SVG sequence besides Cacani--making my use here fairly unique. :|

Exporting SVG based animations for the web doesn't at all jive with OpenToonz--there are plenty of tools out there for the job, though.

[Melvin K]

Bug report submitted. I'm still not convinced that OpenToonz is currently supposed-to-be-able-to import SVG images as a sequence given that it doesn't display them as a sequence in the file browser. It would be great to have some clarification here.

[ManongJohn]

I verified in 1.3.1 sequences SVG files are recognized and loaded as a sequence. It unfortunately does crash after a few seconds after it loads into the xsheet.

[Rodney]

Almost the entirety of SVG processing in OpenToonz constitutes new features although there are a few areas which could be classified as bugs.

For instance, the fact that SVG images ingest into OpenToonz at a common offset every time.

At one point I knew what this bad offset was and could just quickly type it in to get the image back into the right place

I think I reported that error to github but it's likely buried in another SVG report.  

At a guess I'd say the offset is  -200mm and 200mm respectively.

So, there are three 'bugs' with SVG that might be considered 'known':

1) Initial offset is incorrect (corrected by adjusting the offset)

2) Line thickness is misinterpreted (quick fix is to immediately set the line first to zero then back to the intended thickness... although this results in lines of same thickness and thus will not include any taperings)

3) Sequential SVGs are incorrectly identified as PLI format upon ingest

Otherwise SVG images work pretty well in OpenToonz.

[Melvin K]

Thank you for the clarification ManongJohn. I don't expect this to be fixed right away, but the prompt responses from the community here are appreciated.

 

Sequential SVGs are incorrectly identified as PLI format upon ingest

I noticed that SVGs were displayed as a Toonz Vector Level in the info dialog and wondered if that was related to them not being recognized as a sequence--since pli's aren't structured that way.

[ManongJohn]

Sequential SVGs are not being incorrectly identified as PLI.

The system tries to make a PLI (palette) file for the SVG and it isn't creating it correctly for some reason so when it tries to find it, it fails, hence the error.

In 1.3.1, the pli file is created for the sequenced SVG. The crash is a mystery and likely still an issue with 1.2.1 if it read the sequenced SVG correctly.

My guess is the recognition of sequenced SVG was broken in one of the relatively recent PRs addressing sequenced files that was merged after 1.2.0 came out.

[Rodney]

@manongjohn

1.3.1 doesn't compute so we'll assume you refer to the 1.2.1 release until you say otherwise.

[ManongJohn]

Oops. Actually meant 1.1.3.

[Rodney]

Ah!  1.1.3 makes very good sense.

If it was working back then it should be much easier to get things back to where they need to be.

Thanks for the clarification.