Search

Happy St Patrick's day!

At long last, ACME supports uniquely customized animations by providing the choice of arbitrary sub block timings. What the heck does that mean, you ask? Well, all of our animations have default timings for each sub animation 'block'. 'Blocking' is a timing standard of the animation industry. Typical ACME animations have 4 blocks: 'QR code-to-image', 'image hold', 'image-to-QR code', and 'QR code hold'. As of today, anyone can customize the time for any block, making them as long or short as they wish. Do you want the first animation to be nice and slow… and the second to be quick? No problem, just let our API know, and we’ll crank that animation out for you in a few minutes. See our documentation on the blocks argument here: https://acme.readthedocs.io/en/latest/new.html#blocks But wait, there's more! ACME's API also supports a 'length' argument, which is applied to the sum total of sub block times. https://acme.readthedocs.io/en/latest/new.html#length So, if you want to define the sub block times in terms of simple ratios to each other, and then set the time of the entire animation a precise length, it's very easy to do so. For example, let's say you want a the 'image-to-QR code' portion of your animation to be 4 times as long as all other block times, and have the entire animation last 3.75 seconds. For you programmers out there, here's the API call you would make to trigger the generation of that animation:


https://api.acme.codes/new?length=3.75&blocks=0-1,1-2,2-3,3-7&anim=Exchange Are you not a programmer, but you still want a custom timed QR code animation? No problem, contact us and we'll be happy to setup you up with an account on our Animation Engine page, or we can make a custom animation for you.



ACME’s lawyer has informed us that our U.S. Patent has been officially granted: US Patent No. US 10,083,535 B2. Everyone is on notice that this decidedly out-of-the-box idea was ours first. Want a highly customized animation of the tiles of a scannable code provided as a service over the internet? We got you covered.


https://patents.google.com/patent/US10083535B2




2 views0 comments
  • Peter

What should I name ACME’s first API Release from Sweden? Why ‘Abba One’ of course. ACME supports its Co-Founders and engineers to work from anywhere in the world that supports enough internet bandwidth to get their work done. It's a dream come true for us wandering souls of software engineering. Here I am sailing on the Baltic Sea a few hours before finishing this 'Abba One' release:



Api.acme.codes now supports arbitrary frame rates for any animation. Our default frame rate is 30 frames per second, or 'fps'. Since ACME's primary deliverable is an mp4 file of a detailed animation of your QR code and all of its code tiles, we consider this frame rate to be the best for a sense of quality for your scanning audience. This is especially true when the animation includes your images, logos, or product messages. Since digital displays on computer systems can handle playing back almost any frame rate - unlike traditional mediums which tend to have fixed frame rates - ACME now offers any frame rate that best provides for the unique needs of each of our customers. Here's a list of different frame rates and the customers that might prefer them:


  • 30 fps (default): The majority of ACME customers (so far). Almost all display systems can easily display an mp4 file of almost any resolution at 30 fps. This frame rate provides a significant sense of quality for the 'smoothness' it provides.

  • 25/50 fps: For our friends in Europe displaying animated codes on television, this frame rate can be the best for translating and encoding onto mp4s animations targeted for broadcasting.

  • 24 fps: This feature film standard is a nice baseline for acceptable animation smoothness, but allows for deliverable mp4 files of a smaller size, which in some instances can be a higher priority.

  • 15 fps: Rarely used for mp4s, but frequently used by our clients requiring animated gifs. Gif files are great for clients needing the absolute broadest display support; gifs are playable on almost any computer regardless of the hardware and software decoding systems that may be present on them. The cost of this broad support however is a much less efficient file size encoding, so gif files can be very very large. One way to combat the large file sizes of gifs is to limit the fps to be as low as possible.


3 views0 comments