CAP 271 - Computer Animation Portfolio Project

Chapters 5 - 8

Objectives:

The text continues with more background about gathering your work together, organizing it, and preparing it for inclusion in your portfolio. We will skim over this material as well, keeping it for future reference. Objectives important to this lesson:

  1. Retaining your work
  2. Organizing files
  3. Digitizing your work
  4. Cleaning up files
  5. Repurposing and optimizing
Concepts:

The text begins chapter 5 with some ideas about keeping your work. If you have not been doing this all along, start now. Our goal is to assemble a portfolio of your work, which means you must have it to do anything with it. Basic thoughts about your work:

  • Always keep a copy, preferably in its modifiable form. This means that if you submit a PDF version to a potential employer, keep a copy of that, but keep the original as well to modify it for another submission, or to convert it to another format.
  • Keep process material. As noted in a previous chapter, a potential employer may want to see your workflow, or you may want to showcase the development of a piece.
  • If you are working for someone, ask to keep copies of your work. This is not always allowed, as some employers (e.g. Disney) retain copyright for all material produced for them. It does not hurt to ask, to avoid problems later.
  • If you are producing artwork by other than electronic means (e.g. pencil, ink, oil) photograph or scan it to make an electronic copy. The point is to have it, as well as to be able to use it in your portfolio.

Assignment 2: Retaining your work

  1. We have two flatbed scanners in the classroom. Use them to scan and save copies of any hand drawn work you have not already put into electronic format.
  2. This is an ongoing assignment. As you produce more material, make it a habit to save electronic versions of your work.

The text moves on to tell you to organize your work. The author sympathizes that this may not be easy for "creatives". (To the author, "creative" is a noun, meaning a creative (adjective) person.) If this is the case, grit your teeth and do it anyway.

On page 87 (second edition, page 99), the author begins a discussion of five organizational tools/skills which should be used with your electronic files:

  • group - Place things that belong to a project in a folder for that project
  • name - Give your files and folders sensible names. Names should be unique, descriptive, and brief. Also, if you are going to post files on the web, be aware that they can be downloaded by people with a different operating system. Don't make names that violate operating system rules. If you don't use someone else's operating system, how are you supposed to know their rules? Google it, children (yes, that's a verb now, as well as a noun). Here is a link to a nice page about file and folder names.
  • show - This means to use a product to browse your electronic art. Windows will show thumbnails, and so will most art programs.
  • weed - Delete files that you don't need any longer. (Are you sure?)
  • backup - All hard drives die. All disks and portable media will fail or will be lost. The first time it happens to you, you will believe it in your heart. Until then, believe it in your head, and keep more than one copy of everything in more than one place. The author does not seem to believe this. Perhaps she has never lost a file.

First edition examples:

As she does in many chapters, the author gives us some examples. On page 94, she displays pages from the web site of Gabe Rubin, from about five years ago (it is now 2009). Her comments are worth looking over, but some of the examples in the text are horrible. The image on page 94 is an example of how NOT to make a web page. The color chosen for the text on that screen is far too close to the color of the background, making it painful to read. Thankfully, Mr. Rubin has changed his site over the years. Look at it now, and see how much easier it is to read and navigate, how much more pleasant it is to see.

Second edition examples:

In the second edition, the author presents interesting web material from John Locke, an architect whose work may or may not be something that sings out to you. In this exploration of his online material, look at what he has provided and how he has provided it. Look at his material on the site linked above, then follow the link on that page to his postings on Issuu.com. When you explore that site, be careful: it crashed my browser, and it may crash yours.

Chapter 6 describes digitizing traditional work. Take this as a clue: it is important enough to do that the author devoted a chapter to it. The topics in this chapter are arranged by the type of work that you need to turn into a digital file. Since half a decade has passed since the book's publication, perhaps less of your art is non-digital now than it would have been then. Use the chapter for reference as needed.

As a chapter summary, refer to the sidebar on page 103 (second edition, page 115):

  • Use flatbed scanners for flat, low contrast images, like pencil and charcoal drawings
  • If you are photographing your work on film, or your work is photographic, have film processed directly to electronic image. If you have not been a photographer for over 15 years, you are probably using a digital camera already.
  • Consider a film scanner, if you can find one, for digitizing flat work that has lots of tones in it.

Chapter 7, in the first edition, discusses cleaning up files. In the second edition, this material has been moved to chapter 6. The topic is about editing digital art to make it more acceptable, usable, and presentable. The advice offered in this chapter is good general advice, but the specifics of how to edit a file will vary greatly from one application to another, and from one version of an application to another.

General advice:

  • Work with a file in the native format of the application you are using. This means that if you scan an image as a tif, you should open that file in your art program and save it as the native format of that program before working on the file. This gives you a fallback option, in that you never modify your original art, and can start over if you must.
  • Never modify a jpeg file? If you use the procedure above, you won't. However, you should understand why: a jpg (or jpeg) gets more blurred every time it is saved again by an art program. You can copy one from one place to another without data loss, but if you open it in an editor and save it, you make it worse. The author is correct: a compressed format like a jpg is for final versions, not for interim versions.
  • When saving a file for use, consider what kind of file fits the user. TIF (Tagged Image File Format) is a good universal file type for art, but the files are huge. EPS (Encapsulated PostScript) is a printer language that most publishers can use. AVI is a common file type for Windows videos, and MOV is a good file type for video, but only if the user has QuickTime installed. For still images that need to appear on a web page, GIF, JPG, and PNG are the main options.

Use this chapter as a general guide to making corrections to your images, but remember that you will have to get specific information about using your art program from the help file, the vendor's web site, or advice on the Internet.

Chapter 8 (second edition, chapter 7) takes on repurposing and optimizing. This is a continuation of the file processing suggestions from the previous chapter. Essentially, optimizing means making your files are as small and clear as possible, while maintaining an acceptable screen-size, and acceptable color. Any one of the problems discussed can cause the viewer to turn away.

  • Color problems should be obvious, but if they are not, look at some examples of what not to do on Vince Flanders' web site. Sometime, the person who makes a color mistake intended more contrast than we see on the page. Monitors and TV sets are notorious for showing colors differently than intended. (NTSC: Never The Same Color?) High definition signals can be less prone to this problem, but you never know how the viewer has tuned his/her screen.
  • Screen size can be an issue if the viewer can't see as much of the work at once as you intend. Does everyone have a widescreen monitor now? As I write this, they are pretty common but far from universal. I continue to use 4:3 screens on a regular basis, and I continue to be irritated by people who make images that will not resize to fit on them.
  • Small files are desirable over large files. Downloading is an issue, and so is page loading on the web. Emailing, as discussed earlier, also makes file attachment limits. Just because you can send a big file does not mean they can receive it.
  • Clarity of an image is self-explanatory. We have discussed jpg files getting worse with each new save. Any file translated to a new format may suffer from data loss and clarity problems.

In general, saving a file as a gif, a jpg, or a png is a pretty safe choice, but you have to actually do it to see what you get.

  • Gifs are usually smaller, but not always.
  • Jpg files can have millions of colors, while gifs are limited to 256 different tones.
  • A jpg or a gif can use a reduced number of colors. See the discussion on page 147 (second edition, still page 147). Reducing the colors used in an image reduces the file size, and reduces the download time.
  • A png file has the added advantage of an alpha channel, providing crisper transparency than a transparent gif.

Optimizing video is a trial and error exercise as well. You may find that the best codec for file size is not the best one for distribution, especially if your viewer is on a managed workstation that does not allow the user to install new codecs. How do you get more codecs? We have found in the lab that installing QuickTime can give you some, and installing iTunes can give you more. It surprised me that doing this allowed me to write in more file formats (in 3DS Max and in After Effects, for example) instead of just being able to read those formats.

It is common for a video that will be shown on the web to be rendered as a Flash video. Some version of the Adobe Flash player is installed on most browsers, although, trying to play such a video made with a newer version than the player already installed will cause the computer to pause and offer to upgrade the player. This leads to the user having to tie up their time installing new software if your movie needs it, or moving on and skipping your movie. An advisory by your links to Flash videos, stating the player version required, may avoid bad feelings. This is especially important when you consider that some viewing platforms do not support Flash at all (e.g. iPad).

As I write this, there is much discussion about switching to an HTML 5 format, which Adobe is beginning to support as well. Time changes which tools you use and how you use them.

Whichever video format you choose, look over the advice on page 153 (same page again, weird) about setting the window size and frame rate for the video. Smaller settings for either will render smaller files. (See above.)