Tracksperanto is heavily tested. Please use the Github checkout to also receive some 17+ megabytes of test files that the test suite can chew on. Contributions or patches without tests will be rejected at sight.
Tracksperanto is currently being developed on Ruby 2.0.0 but we maintain compatibility down to 1.8.7. What you will need is everything mentioned in the Gemfile plus Bundler. Development should be done agains the git checkout because the gem does not contain the test files (various example files in different formats that are used for verifying all the import and export modules).
The test corpus on Tracksperanto is HUGE at the moment, and it makes no sense to ship it with the gem.
So, to get started:
- Make sure you have Ruby and Bundler (
sudo gem install bundlerif unsure)
- Checkout the repo at http://github.com/guerilla-di/tracksperanto
bundle exec raketo run the tests
- Do your thing, in a separate branch
- File a pull request or send a patch to me at julik dot nl
Internal tracker representation
The trackers are represented by Tracker objects, which walk and quack like Arrays of frames. The Tracker objects
contain Keyframe objects, and those in turn contain coordinates. The coordinates are stored in absolute pixels, relative to
the zero coordinate in the lower left corner. The Tracker objects wacth after you so that you don't put multiple Keyframes on
the same frame number, keep Keyframes sorted and so on - in short, they are a nice container. They are also what is
when you import.
Tracksperanto uses the bottom left coordinate system, with positive values going up and right. Pixel registration is on the lower left corner of the pixel. Thus the absolute left/bottom of the image has coordinates 0,0 (at the lower left corner of the leftmost bottommost pixel) and 0.5x0.5 in the middle of that pixel.
When importing data, each import module will conform the coordinate system to these conventions. Each export module will convert from this system to whichever is required by the consumer of the file being exported.
Importing your own formats
To write an import module refer to
Tracksperanto::Import::Base docs. Your importer will be configured with width and height
of the comp that it is importing, and will get an IO object with the file that you are processing. You should then
yield the parsed
trackers packed into
Tracker objects within the
each method (tracker objects should be Tracksperanto::Tracker objects or compatibles)
Since the importer objects also mix-in
Enumerable you can quickly import into an
Array and so on.
Exporting your own formats
You can easily write an exporter. Refer to the
Tracksperanto::Export::Base docs. Note that your exporter should be able to chew alot of data
(hundreds of trackers with thousands of keyframes with exported files growing up to 5-10 megs in size are not uncommon!). This means that
the exporter should work with streams (smaller parts of the file being exported will be held in memory at a time).
Export modules are decoupled from the internal
Tracker representation - all the export module ever sees are raw strings,
Ading your own processing steps
You probably want to write a
Tool (consult the Tracksperanto::Tool::Base docs) if you need some processing applied to the tracks
or their data. A
Tool is just like an export module, except that instead it sits between the exporter and the exporting routine. Tools wrap export
modules or each other, so you can stack different tool modules together (like "scale first, then move").
Writing your own processing pipelines from start to finish
You probably want to write a descendant of Tracksperanto::Pipeline::Base. This is a class that manages a conversion from start to finish, including detecting the input format, allocating output files and building a chain of Tools to process the export. If you want to make a GUI for Tracksperanto you will likely need to write your own Pipeline class or reimplement parts of it.
Reporting status from long-running operations
Almost every module in Tracksperanto has a method called report_progress. This method is used to notify an external callback of what you are doing, and helps keep the software user-friendly. A well-behaved Tracksperanto module should manage it's progress reports properly.
require "rubygems" require "tracksperanto�" include Tracksperanto # Create the importer object, for example for a Shake script. # get_importer will give you the good class even you get the capitalization # wrong! some_importer = Tracksperanto.get_importer("shakescript").new # This importer needs to know width and height some_importer.width = 1024 some_importer.height = 576 some_importer.io = File.open("source_file.shk") # The importer responds to each() so if your file is not too big you can just load all the trackers # as an array. trackers = some_importer.to_a # Create the exporter and pass the output file to it destination_file = File.open("exported_file.other", "wb") some_exporter = Tracksperanto.get_exporter("flamestabilizer").new(destination_file) # Now add some tools, for example a Scale scaler = Tool::Scaler.new(some_exporter, :x_factor => 2) # ... and a slip. Tools wrap exporters and other tools, so you can chain them # ad nauseam slipper = Tool::Slipper.new(scaler, :offset => 2) # Now when we send export commands to the Slipper it will play them through # to the Scaler and the Scaler in turn will send commands to the exporter. # As you can see when you run export commands you do not have to use the Tracker # objects, you just have to stream the right arguments in the right sequence slipper.start_export(1024, 576) trackers.each do | t | slipper.start_tracker_segment(t.name) t.each do | keyframe | slipper.export_point(keyframe.frame, keyframe.abs_x, keyframe.abs_y, keyframe.residual) end slipper.end_tracker_segment end slipper.end_export # And we are done!