Post 479 - Report from an Austere and Adamant Animator - ASIFA Central Retreat Newsletter - 2022

"In a Fog, Not in the Cloud"

    It’s not being a Luddite that prevents my use of the latest and greatest technology - it’s the pernicious policies invading software that no longer permit you to own a copy of a license, but rather, perpetually rent one, thereby never really having free access to your own work.  Instead, you are always relying on an ongoing fee (certainly this is the business model of certain operating system vendors who crave to poke a finger into any intellectual property deed that crosses its cloud).
    As a result, I still use Flash, Photoshop, and Sony Vegas, but only in the forms that rest upon a hard drive that hums in front of me.  Living in a fairly remote region where the internet can be woven a bit loosely, there is an additional advantage to not relying on an amorphous storage space to suddenly become inaccessible.  
    The downside is, of course, that latest and greatest “advances” aren’t always available.  The upside is I get to wonder if they’re even necessary, or if work-arounds can obtain the same results.  I should use the word “hacks” to keep current.
    So I have discovered a hack with 4K creation and rendering.
    Flash, now known as Adobe Animator, does not offer 4K in its final iteration to own, CS5.  It maxes out at a work screen resolution of 2800 x 1575, making it about 75% of a 4K.  Let’s call it a 3K (I have noticed that this version of Flash has an “Animator” menu which is very much like their current software iteration). But it can do 2800 x 1575!
    It can also render out nearly any size gif, jpg, or png sequence of files, including 3840 x 2160.  That means I can draw in “3K” and render out as 4K (3840 x 2160) (Export > export movie > jpg sequence).
    This “3K” series of images can be brought into the Photoshop CS6 (again, the last one available for outright purchase) and then adjusted for any unwanted artifacts, and saved out at 3840 x 2160 again.
    However, I have also found that my Sony Vegas 15 video software (later versions exist, but after #16 they are utterly dreadful) will import my faux 4K from Flash just fine and export at 4K resolution, and all looks well.  I use the Sony video edit product because it offers the functions of After Effects that I actually use without causing the office lights to dim.
    My final observation has been that whenever I use these three software products - Flash, Photoshop, Vegas - my hard drive just starts spinning and the internet bandwidth begins playing.  In some cases, especially with the Flash program, it seems that it is reaching out to Adobe and things quickly jam, and occasionally crash.
    Solution?  I disconnect a WiFi dongle on my “grandpa box” desktop computer when I start or continue a project and, gee whiz, things seem to work out just fine.  
    This is a work-around - sorry, hack - to be sure, and ultimately I’ll have to succumb to some online experience, but it buys me time while I explore some other open source substitutes for Flash (Krita shows some current promise) for 2D.   I’d rather use my time to complete a few ongoing projects rather than stop everything to learn which compromises to my workflow I have to accept for the sake of newness (and don’t even get me going on cars without key locks).

To summarize:
 (mainly for my benefit, on a 3x5 card near the keyboard)
4K “Hack”

1. Disconnect WiFi (it’s a distraction when drawing, anyway)
2. Draw in Flash CS5 with a workspace of 2800 x 1575
3. Export image files in batches of 100 (each one is about 1000kb) - prevents software/hardware overloads
4. Use with File > Export > Export Movie > jpg sequence (or png sequence or gif sequence)
5. Set export size of image files to 3840 x 2160 when prompted
6. Import to Photoshop or video editor (set Preferences > Edit > import 0.08 seconds for 2fps in Sony Vegas)
7. And party on!

And save ALL DRAWINGS in a safe place, multiple hard drives, archive.org, or printed out and put in a basement shoebox!!!

This bit of a tirade is not presented to slam any particular product, but, rather, the business model that obstructs aspiring animators - they need to have better access to resources that won’t present yet another hurdle to their lifelong career.  Painters don’t have to rent their canvases or acrylics, after all.

Waiting at the Church - a video for a 1906 Edison Cylinder - Now! With ADDED WORKFLOW NOTES!

THE TEDIOUS PROCESS EXPLAINED

- after a half-dozen updates - 

(you'll probably get sick of "Waiting at the Church" by the time you're done here, too)

This was going to be a "quick project" involving a series of 3x5 cards with the lyrics broken down line by line, then flipped and photographed in real-time while the song played.

Of course, they didn't flip properly.

Of course, they all stuck together when trying to pull the cards along, one after another.

SO

The 3x5 cards, which somehow ended up being 655 x 480 pixels, were photographed and placed into the Sony Vegas 15 system, stretched to match the specific lines in the song.

Those results were unsatisfactory.

SO

The cards were processed out as a series of jpgs, again ending up at 655 x 480 pixels, and re-introduced into the Flash CS5 environment, aligned with the 1906 soundtrack, "broken apart" within the Flash software to adjust them to the workspace as a "sing along," and then tied in with a series of b/w public-domain gifs and jpgs (from a low-res 36,000 item library, but considered all "hoo ha!" in 1996), which were then "colorized" with a layer in Flash (colors at a 50% alpha level).

AND

Once things were ok in the Flash environment at 24fps, the entire 2900 frames were exported as jpgs again, reintroduced to Sony Vegas again (with 0.04 seconds per frame equating to 24fps in the edit preferences for imported material).  The soundtrack was slid into place, image and sound worked well, and then back to exporting everything in a 640 x 480 size.  This explains some of the cropping at the beginning title.

This took a day.  

The soundtrack had already been "produced" from the archival cylinder collection here, with some surface noise and amplification adjustments made to the original (and just a touch of echo), along with stretching it to 2 minutes from the original recording speed of 1 minute, 50 seconds (I compared my original transfer with that from the UCSB cylinder archive, which ran exactly 2 minutes, but was very noisy and obviously frequently played, before making the adjustment in Audacity for the speed).

The first draft, with images assembled:

2020 Animating Apothecary

Once having sent that to a local showing with a deadline of June 3, I returned to the original piece again and spent a couple of hours building a "bouncing ball" heart layer to the process.  It still required exporting the Flash frames as jpgs, but it was streamlined by using "motion tweening" to move the ball from one image layer to the next.  Overall, it was beneficial in creating a smoother transition between frames.  The heart was made as a "graphic symbol" and keyframing was applied with an F6 function to the entire layer of frames with the heart.
It took about two hours to create the layer, move the heart around, use it as a bridge for the final appearance of the unfortunate letter, and then render the frames out from Flash, in to Sony  Vegas, and then out again with the same 640 x 480 size.

Here's the version WITH a bouncing ball!  Everybody SING!!!!

2020 Animating Apothecary

It was ok, but the resolution was pretty poor for anything other than internet use.
SO
Searching through the Battle Creek historic image archives, I came upon a low resolution of the Garden Theatre interior from 1910.
I rather like the vaulted ceiling:

It needed to be boosted to a 1920 x 1080 size, but that increased the jagginess of the image, along with making the color of the theatre interior challenging for use as a matte-like overlay image for the two-minute piece.
SO
Back to Photoshop, making a 1920 x 1080 size, turn it to black and white, then using a blur-iris function to smear the image, and then export it again, thusly:

Brought everything back into Sony Vegas, gave the theatre interior its own layer, used their chroma-key function to make the enhanced white screen more transparent, and then ran the animation beneath it.
Also, at this time, I decided to assign it a "Sfumato" number of 1.75, since this whole project was something outlined back in 2002, at which point Sfumato #1 had already been completed (1999), Sfumato #2 was "a work in progress" (still is), and Sfumato #1.5 (Avian Flu) had appeared in its first form in 2006.
Obviously, I let other things get in the way over the years....
Finally, I came across a 16mm projector sound effect for the first few seconds, and here is a version of that completed edit, at a resolution that Blogger can tolerate, for review:

2020 Animating Apothecary

Working late at the office.

Working on a camera setup...and...

 

...then the lights went out...

I think it was a bad circuit breaker...

Experimental Video Snippets - Posting #100

Using a Panasonic Lumix video function with Sony Vegas and some ancient cylinder recordings....
Hypno Kitty:

And then some Solar Powered Plastique Animaux:

And, finally, some local Winteriness here in Nippishnessville, Michigan (and not a groundhog in sight):

The FDA Steps Up to Control Narcotic Deaths -- well....

Annual deaths associated with acetaminophen toxicity run about 450 per year.  In 2007, over 11,500 died from hydrocodone toxicity.  Vicodin, Norco, and Lorcet are all combinations of hydrocodone and acetaminophen and are not only heavily abused, but are also implicated in greater numbers of 'accidental deaths' (meaning, abusers who don't make the statistic are accidentally living) each year.
The FDA's response - restrict the amount of acetaminophen in each tablet!
The corporate response?  Abbott, now owners of the Vicodin 'brand' stepped up and made a change in their formulation - no more than 300mg of acetaminophen per tablet (they had allowed up to 750mg per tablet before).  This makes a 'new drug' according to the FDA (a tactic employed by the makers of Tussionex cough syrup for years), and makes previously available 'generics' for 'brand name' Vicodin no longer 'equivalent.'
So a generic company stepped up, got the first approval for a 'generic' and lo - another example of the FDA helping contribute to the rising expense of health care!

The wholesale price of $148.27 is for 100 tablets of this 'generic' for the 'reformulated' Vicodin ES.  Pharmacies could buy a LOT of the old generic, hydrocodone 7.5mg/acetaminophen 750mg for the same price.

Wastewater Treatment Project ca 2009

The challenge here was getting information about the final required render.  Three years out and I'm not sure if it has gotten much theatrical play!  Oh budgets!

Musings on Pharmacy Operating Systems

Having been circulating among pharmacies over the past dozen years, I have come upon several varieties of pharmacy-based operating systems, most of which have been designed by engineers and programmers without the slightest inkling of the primary operations of a pharmacy.
Invariably, these systems are chosen by department managers looking only at the bottom line cost, and rarely, if ever, with consideration for those who have to actually make use of the product.  The old canard "oh, there's always a learning curve," is usually invoked, when for the users, it's more of a "learning cliff."  And patients, trained for instant gratification and regarding a pharmacy as just a variation on McDonald's, don't give a rat's patootie that workers are gnawing their arms off during a conversion to an 'improved' system.
The software marketers create handsome websites extoling all of the functions of their systems, but - and I find this very interesting - never really show what their system looks like in practice.
Two systems in particular - one called 'Prodigy' (no relation to the old pre-internet online service) and the other called 'RX30' - are classic examples of this mindset.

Prodigy is an odd collection of jumbled screens, originally designed for nursing home 'cycle fills' (a process that quickly becomes a billing nightmare), unmatched fonts, complicated by a nonlinear work flow that has the user moving back and forth in the process of filling a prescription.  Its choice is usually by those who want a centralized access for billing, from several off-sites, for which it seems well suited.  However, for a user, it serves only to add about 50% to the processing time of a prescription, just in the back and forth of the workscreens.  A mouse is required, something that really ruins any workflow.  Operating two terminals, two trained and experienced employees, going breakneck, can process a max of 140 prescriptions in 9 hours (that's just processing, not filling, by the way).

RX30 suffers from similar drawbacks.  The screens are inconsistent in their layout, with function keys being especially challenging, as each one opens a set of menu options which then change depending on the screen.  Changing a spelling error in the prescription label, for example, means F1 > Workflow (the tenth selection in the menu options)  > Edit/label > F2 > toggle or mouse to instruction field > make change > F4 set (not just 'enter' - you have to 'set' the change with a function key)  > F5 reprint (or is it the other way around? Again, process over outcome).  For any clinical tracking, it has a 'comment field' that can be altered or deleted at will or whim (so useful progress notes will have to be kept separately in a word processor document set up on your own).   Getting a reprint on a label is another 4-5 step process. The pharmacy being introduced to this system usually does about 200 Rxs per day.  The backlog of unprocessed Rxs by 11am was about 50.  The POS process with the system is additional software, with a completely different set of menu screens, with lots of mousing and touch screens (and don't we just love the 24 hour virus life cycle on a touch screen device in a healthcare setting), and nearly a doubling of clicking processes.  It is obvious that RX30 just bought an existing setup for their POS - there is no integrated workflow with the pharmacy operating system.

It is apparent that these packages, while not inherently evil and possessed of some level of functionality, are at best poor examples of creating a useful or efficient workflow.  Neither of them have been developed by programmers who seem to 'get' the purpose of a retail pharmacy setting - to fill new prescriptions and refill existing ones.   There is far too much time wasted in twiddling and fiddling, almost as if they were developed by teams trained in algorithms of computer games rather than the stark, dull, workaday need to grind out prescriptions quickly and efficiently.  A stark example is that neither filling nor refilling a prescription are among the top choices of their opening menus.

And, it is interesting that it takes a team of trainers several days to 'educate' pharmacists (with 6 years of college) and their certified technicians (again, they are the ones who have to do this all efficiently) on how their systems operate.  That is a huge flag right there.  Systems can follow an intuitive design and flow.  Neither of these do.

When we hear 'oh it's only a few seconds extra time' for each prescription, these programmers need to understand that a few seconds, multiplied by 200, is a considerable amount of time during an already hectic workday.  They get paid by the hour - we get paid by the prescription.