Forum Replies Created

Page 99 of 136
  • Tom Matthies

    October 23, 2006 at 3:52 pm in reply to: Kona 3

    I’m running a Kona 3 and an Aja Io on the same computer with no problems. I run an Aja La on another system with good results as well.
    Tom

  • Tom Matthies

    October 19, 2006 at 11:44 pm in reply to: 5.1.2 Canvas/Viewer changes when playing HD clip…

    For what it’s worth, the same thing happens on my system when working in 1080-10 bit uncompressed. The levels in the canvas change depending on whether the clip is playing or stilled. The output thru the Kona 3 stays constant. I agree, it is VERY annoying.
    Since no one seems to have an answer, I’ve just learned to live with it.
    Tom

  • Tom Matthies

    October 19, 2006 at 12:47 am in reply to: OT: Has anyone been using the Tascam FW-1082?

    I’m running an Aja Io La on this particular machine. It’s running of of the G5’s internal firewire bus. I also have an FW800, three port card with an open port. I would imagine that this mixer should run off of the FW800 port but would it then slow the bus down to FW400 speeds? Would it work to run the Tascam board off of this card without problems?
    Tom

  • Tom Matthies

    October 18, 2006 at 1:43 am in reply to: flicker/movement in still images

    Hmmm. Now there’s an interesting idea…
    Tom

  • Tom Matthies

    October 17, 2006 at 2:47 am in reply to: flicker/movement in still images

    Once the graphic is into FCP it doesn’t make that much difference as long as it is big enough for your needs and yet not too large to actually degrade your finished product with all kinds of artifacts from the excess resolution. Must graphics come from outside FCP. Out in that world, the DPI resolution does ndeed matter. It’s an important consideration when you product your graphics and especially important if someone else is doing them for you.
    And also, please remind those print people; no CMYK if you please. 🙂
    tom

  • Tom Matthies

    October 16, 2006 at 9:29 pm in reply to: flicker/movement in still images

    I disagree. DPI DOES matter. If you re-read the orginal post, there was a problem with severe interfield flicker as a result of TOO much detail and the software doing it’s best to try to interpolate the graphic for use in the video world. Even though a graphic at 720×480 will fill the screen the same as a graphic at 7200×4800, when you go into the motion tab you will find that the actual scale of the larger graphic is a much smaller value; much less than 100%. All this extra information is basically thrown out when the graphic is displayed at the normal 720×480 size on the screen. The software is then given the task of re-interpolating each and every pixel of the original graphic and the regenerating a new, suitable version for display. You have undoubtedly noticed this when working with larger graphic files. Things just tend to slow down and the display takes longer to update.
    A graphic at 720×480 and 72dpi is not the same as a graphic at 720×480 300dpi. The later is MUCH larger in terms on information that the programs has to then plow through. Many commom digital still cameras like the Nikon D70s is usually use for stills will yield a Jpeg file that is around 3000×2000 pixels at 300 dpi. While you can use this file in FCP, it will seriously slow down your system while you manipulate these images. Plus the added detail will likely result in a bad case of interfield flickering. The newer G5 based systems dont have as much trouble as older systems, but there is still a noticable difference in the speed at which it will handle these larger graphics. When I use any stills from my camera I normally reduce them down to a bit more managable size. If they will be used only full frame with no pan ‘n scan needed I simply take the original 3000×2000 300dpi file into Photoshop and reduce the dpi to 72. This will give me a file size for FCP that is almost exactly the same as the screen size for video. If I need to do mild pan ‘n scan, I will simply reduce the dpi to 144, exactly double the screen size. This gives me plenty of real estate to move the still around the screen. The DPI of a graphic does affect it’s useability in FCP. Drag that still into FCP that is 2000×3000 at 300dpi and go to the motion tab and reset the scale to 100% and see what happens. You will get the idea.
    The flicker experienced above can be the result of too much detail. A poster suggested adding a bit of blur in Photoshop. The same can be accomplished in FCP by adding a touch of Gaussian blur right from the filters folder. A small amount goes a long way, but it generally does help. Or add a bit if vertical only blur in Photoshop to help preserve your horizontal detail. There is definately such a thing as too much detail…when it comes to video.
    tom

  • Tom Matthies

    October 16, 2006 at 12:23 am in reply to: flicker/movement in still images

    Reduce those still down to a more useable size. I’m betting that this is your problem. Unless you are doing extensive pan’n scan type moves those stills are much bigger than you need. Go into Photoshop (if you have it) and resize them to something more in the neighborhood of 1440 pixels (horizontal) at 72dpi. This will give you an image that is still large enough to do movement on, but not so large as ti introduce such severe interfield flicker. I’ll bet it will kill most if not all of your flicker problem. I am of course assuming that you are using a standard size for your screen dimensions (720×480?) and not planning on showing these images on something the size of a billboard!
    Tom

  • Tom Matthies

    October 12, 2006 at 2:45 pm in reply to: kona vs Black Magic (HDCam FCP workflow)

    I used the Kona3 card to do just what you proposed in the above post. It will downconvert on the fly as you bring the footage into FCP. I used a Sony HDW-F500 to bring in the footage for the offline and the online as well. It worked fine with only a couple of issues, in particular the sync reference for playing back at 23.98 fps. There is a setup in the deck itself to switch the reference to internal for playback. Set the Kona3 reference to freerun while capturing and it will work without problems. If you are going to offline at 23.98 and online at 29.97 keep in mind the timecode weirdness that may result from the different frame rates.

    As for conforming on a Nitrus system, use Automatic Duck for the transfer and it should work. Personal preferences aside (I usually use Final Cut, but we also run a pair of Avid Symphonys here) the idea of conforming on a Nitrus is not all that dumb. Even though pixel for pixel the quality should be comparable, the Nitrus does offer a number if advantages. It’s color corrector is far superior to FCP’s color correction. Unless you buy a plugin such as Final Touch for FCP, the Nitrus CC is one of the best in the business. Color grading on the Nitrus would be a good reason all by itself. Use the right tool for the job.

    And that, folks, is one of the few times you will EVER hear me praising an Avid system. Mark you calendars! Today was the day. 🙂
    tom

  • Tom Matthies

    October 11, 2006 at 3:02 pm in reply to: Loss of Timeline Movement feedback in FCP 5.1.2

    Working OK here as well.
    Quad G5 (Intel) FCP5.1.2
    Zoomed all the way in to the max possible and still worked fine
    .
    Tom

  • Tom Matthies

    October 10, 2006 at 2:22 pm in reply to: Different audio sync with different users?

    I found the problem.
    The video output was set to the wrong setting in the A/V pulldown. And the audio output was set to “default” rather than Io putput. Set these to correct settings and all is well with playback
    Thanks,
    Tom

Page 99 of 136

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy