Lin Evans

Hi Alain, The third keypoint on your first slide goes beyond the 4.00 second end point, so the action or animation (opacity in this case) continues into the following start point in real time for the timeline on the second slide. The 1500 ms transition time to slide two begins at 4.00 seconds. If you want to stop the appearance of slide one at the beginning of slide two as it is now programmed, then you can easily do that by setting an additional keypoint at about 4095 in slide one with the opacity set to zero. Opacity changes are by default linear and continue in time from whatever level they begin at to 100% or to zero (depending on direction) unless there is an intervening keypoint set to either "hold" opacity at some desired level. So setting a keypoint with opacity zet to zero at a short distance after 4.00 will "stop" any intrusion into slide #2. There will be some inconsistency as you have this sample set up because without choosing a transition effect (it's random as set) which one happens will be variable. Earlier on in the development phase of PTE, there was only linear pan, zoom and rotate. To avoid an abrupt "jerk" at the end of a zoom or pan, users would pull the ending keypoint beyond the alotted time on the timeline and into the following slide. They would then pull the start keypoint for the next slide backward into the ending timeline of slide one and thus get a very nice, smooth overlap. This is still a desired effect in many cases. So having the ability to "cross-fade" via the keypoints has been a desirable feature of PTE. Best regards, Lin

Hi Igor, Something for the future. Possibly a "fade-out" and a separate "fade-in" transitions. One thing which has been problematic is matching precisely the end of a slide which is zooming in with the start of the next slide to continue the zoom in a seamless fashion. Perhaps if there were separate "fade-out" and "fade-in" transitions it would be easier to match these to make a seamless transition rather than the fade out/fade in. That is so that the timings could be different rather than the same for the beginning and end of a slide. If it were possible to end a fade out on slide "A" while slide "B" was beginning a "fade in" then when each are set to linear and with the same slide timings and zoom ratios and identical points and sizes on the timeline where one begins the fade out and the other the fade in then if the timings for the fades were identical the change from slide "A" to slide "B" would be virtually indistinguishable provided that the images were carefully matched for color, saturation, sharpness, contrast, levels, etc. Best regards, Lin

Hi Al, I think you can avoid adjusting your sildes individually. Just "select" them all in the slides list and whichever attribute you assign should be assigned to all unless I'm misunderstanding what you are discussing. \ On second look I see what you mean. You want to set the original size for all the images, but if you do it via the Project Options then you would have to change it individually for each other slide not in the "video" sequence. On the other hand, that might be quicker than doing it for all the video sequence individually. No good solution..... Best regards, Lin

One of the issues which has become apparent when playing with the infinite zoom concept is how to match ending zoom points with beginning zoom points on following slides. That has pretty well been worked out essentially by temporarily adding the next desired slide to the existing slide as an object, setting each opacity to less than 100% and manually/visually matching at ending keypoint for first slide. Then either copy numbers to insert in following slide or copy slide object, delete following slide and paste copied slide. That works well for the match and with perspective zoom, careful color match, display time match, etc., an excellent continuous zoom can be accomplished. But another problem presents itself and that is how to correctly determine the proper focal length increments for the original captures so as to: 1. Prevent pixelation by too deep zoom 2. Have sufficient overlap so as to allow a match without a black border on the zoomed out image There are probably more scientific and better ways to accomplish this, but my head is beginning to hurt from trying to decipher the variables so this is how I approach it. I take one of my original image which has not been altered and bring it into PTE. I've discovered that with my dSLR's which have a different aspect ratio than a 4:3 computer monitor I need a zoom of 112 to just fill the screen vertically without a black border. That's my starting point. Next I open the same image in Irfanview (to see it at 100% size without any resample) and use both Irfanview and PTE in the windowed mode. I increase the zoom on the PTE file until a measured object in the image just matches the measurement in Irfanview of the 100% image. In my case it turns out that the zoom is exactly 258. This figure will be different for different cameras depending on the pixel dimensions of your original file. In many, if not most cases, this will be a larger number. I'm using a dSLR which produces a 4.46 megapixel file with a 14 megapixel sensor, so my numbers don't reflect the norms. The point is, that I can then use this figure (258) in my case as a percentage of increment for focal lengths necessary to match maximum zoom in on frame "A" to matching maximum zoom out on frame "B". So if I take an image at 100mm then I can safely jump to 258mm for the second image then to as much as 666mm on the third frame, etc. I can always go "less" in terms of increments, but if I go more then I must either exceed 100% unpixelated zoom on my first image or have a black border on the matching image from the next slide. This is just a quick "non-mathematical" method of determining which increments you can use with your own cameras. Use a 100% sized image to measure some feature, match that feature in zoom with PTE and observe the zoom number. Use this number as a percentage of focal length safe to increment for your sequence. So if your own number turns out to be 432 then that's 4.32 times the lower focal length as a "step" or "increment" for the next frame. If your number is 347 then 3.47 times the lower focal length, etc. Lin

Hi Steve, No, it doesn't mean that at all. You can still run decompiled video as indivirual frames to simulate a move. What it means is that because of the necessary support for many other facets important to version 5.0, the operation isn't quite as "efficient" as with 4.48. I've run many instances of decompiled video with version 5 betas and they work quite well. If you try to set the frame rate to an extremely quick (10-25 ms) sequence, frames will be dropped, but even if a few frames are dropped as evidenced in an activity "log" it's not usually noticeable at all in the actual presentation. Remember, we are often feeding much larger files to PTE in video mode than true DVD NTSC or PAL resolutions. You should actually "try" it to see how it works. Often you don't need a full 29.97 frames per second to get nice smooth video. Movies have done very well over the years with 24 frames per second. A lot depends on the individual video. Make no mistake, the video's won't be as "smooth" in 5.0 as they are in 4.48 because it's not possible to support the extremely fast frame rates such as 38 frames per second - there will be dropped frames if the rate is much faster than about 75 frames per second but you will have to try it for yourself. Also, it works much better if you turn off hardware acceleration - at least it does for me. Of course this presents other issues so perhaps best overall to create an executable of the AVI in 4.48 and call that file via the object handling in 5.0 if you want really smooth video of any decent size. Best regards, Lin

Hi Peter, This is the one I use: http://www.onestopsoft.com/ Click on the "video decompiler" link. It's not "free" but it's very inexpensive and works great.... Lin

You didn't really have a misunderstanding. Let me try to be more explicit. The amount of RAM used does indeed depend on the number of pixels. If you look at uncompressed tiff files, there is a direct proportional relationship between the number of pixels constituting the file and the size of the file in bytes. So cropping out the arch is by far the most important thing. With jpeg, the less "detail" in the image, the higher it will "compress" but as you correctly assume, the absolute file size determines the RAM requirements. For example, if you take two identical image captures of fairly detailed subject matter then apply noise reduction to one and not to the other, the jpg with noise reduction applied will have a smaller compressed file size than the one with the additional "detail" i.e., noise. But when they expand into memory, each will have identical RAM requirements. So making the area pure black around the cropped arch will only actually reduce the jpg compressed file size rather than actual load size. I was not clear at all when I posted that making the full sized image have a pure black would affect file size. What I meant is that the JPG file size would be smaller because pure black compressed easier than whatever latent detail may be in the non-pure black background. Making it pure black only facilitates the blend or "match" between the dark portion of the LCD or CRT and the image. Your original understanding is absolutely correct about the "true" file size after expansion into memory. Only the file size of the compressed jpg is different depending on the nature of the components of the image itself and only because of compressibility. Best regards, Lin

Hi Andrew, Looks great! I think that having essentially infinity focus (or at least identical DOF) is definitely key to getting this to work smoothly. That's why on my Kachina example the last three transitions were not detectable while the first five were obvious. By using Helicon Focus to create the large DOF macro and having no distracting visible DOF changes between the last three slides things work much better. That's a great example. Now if you could get a chance to use a Sigma 300-800m with a 2X teleconverter to go with that 400mm starter imagine how the additional focal length would add to the dynamics - LOL. Best regards, Lin

Hi Dave, Yes, it's an ongoing process. The Joint Photographic Experts Group committee meets a minimum of three times per year to discuss still image compression standards and establish protocol, etc. Just where they are at any given time is tough to say unless one is a member (I'm not) and stays current with what's happening. I'm not certain when the last iteration of "standards" were adopted, but perhaps Adobe wasn't following them at the time Photoshop 7 was introduced or even more likely there have been changes which would be reflected in the latest libraries such as used in PTE. Here's a link for more info: http://www.jpeg.org/jpeg/jpegls.html Best regards, Lin

Hi Dave, Since the original post didn't specify "how" the images were changed to B&W I only tried desaturate in Photoshop 7 which doesn't actually affect the RGB status. Choosing "mode" does affect RGB and that creates a file in PS7 not compatible with present jpg protocol standards. This is not surprising, but what is important is that it's an easy fix and also that it should be made a known caveat in case PTE users have Photoshop 7 as their image editor. Thanks for pointing out the issue. Best regards, Lin

Hi Al, Yes, that's why my original suggestion to make the black 000,000,000 to match the completely dark CRT or LCD without having the excess dimension. Best regards, Lin

Hi Al, It's relative, I suppose, but there will be a significant file size difference. Whether that difference is sufficient to help depends on the amount of overload. As an example, here is a photo of the moon, surrounded by a black sky - then a crop of the moon from the original. A pure "black" sky doesn't have much in the way of detail so compresses really well, but the actual dimensions of the expanded files in memory are still quite different. In the case of the arch, the savings wouldn't be as significant because the arch probably occupies about double the area of the moon in my sample, but in this case the moon surrounded by the black sky is 513K when virtually uncompressed with Photoshop level 12 while the cropped moon is 148 K. With that ratio I would assume that cropping the arch and removing all the extra black would result in at least a savings of half the file size. http://www.lin-evans.net/pte/moon.zip Best regards, Lin

Hi Gareth, One easy solution to greatly reduce the loading on the laptop video card would be to just crop out the arch into the minimal rectangle of black around it. This black would be identical to the "dark" LCD or CRT monitor so no need for the additional black and the "padding" on the sides. If you have a different shade of black, just change it in Photoshop or your choice of editor to 000,000,000 to match zero light on the monitor. Unless you are playing it with a different colored background on the PC, it should greatly reduce the size of the file so that you would be zooming into the larger image but saving a great deal of file size for the arch photo. Best regards, Lin

Hi Igor, I just repeated his process in Photoshop 7 without any problems. I suspect that the issue was with one of the files. My workflow was open a color image in photoshop 7, desaturate, adjust contrast and brightness on the desaturated image, save the desaturated image under a different filename, open filters, choose sketch, choose "photocopy" desaturate the photocopy which for whatever reason picked up color from the desaturated image, save the sketch. load sketch, desaturated then color image in PTE and apply fade to each. No problem. Perhaps he could load one file at a time and see if which one is a problem then possibly recreate the process using different file names. No problem with my Photoshop 7 and this. Lin

Hi Dave, I did mine with CS but I do have PS7 so I can try it and see if it makes a difference. Lin

Hi KG, There's something wrong with one of your files, it's not a bug. I just duplicated this procedure and it works perfectly. Try renaming the B&W file to bw (drop the ampersand) and loose the _ on the color_cropped.jpg and see if that helps. Here's a sample. http://www.lin-evans.net/pte/yotes.zip Best regards, Lin

Hi Al, Excellent tip! Just a clarification. The "text" must be a png or "rasterized to PNG" or you won't get the "mode" indication. That is if you just choose "add text" you can't see the "mode" choice when highlighting the child "text". Best regards, Lin

Project Options, Music Tab, uncheck "Repeat Music After Playing" then create executable once again. Lin

Hi Al, I should have looked first! LOL. I guess then there is no easy way around just manually adjusting each keypoint. I would guess that if he has used any non-linear animations that he would also have to switch them back to linear first, then make the keypoint changes and finally set the non-linar back by separating keypoints once again. Best regards, Lin

Hi Dave, My suggestion would be to first save the entire PTE under a different name so you have a duplicate to play with. Next download Al's spreadsheet and use that to make the necessary changes to the keypoints. Best regards, Lin

Hi Bob, The DVD has 4.7 gigabytes of space. The message you received sounds like you ran out of hard-disk room instead. Either your working hard disk space is extremely limited or perhaps something with space allotment. It's doubtful that you did anything "wrong'. Have you successfully burned DVD's in the past on this system? Best regards, Lin

Hi Paul, You can do it that way, or just type in the link in the text like this: http://www.lin-evans.net When I typed the above it was just "text" but the board recognizes it as a URL because of the http:// followed by the www.whatever. If you want an image to appear without the user clicking on the link, then you need some additional code. The easiest way is to click on the small icon in the line with the "bold" "italics" "underscore", etc., it's the little one between the email and insert link above. Then type the address in the block which pops up complete with the filename and extension. Best regards, Lin