![]() LargeImageViewer (LIV from now on) is a set of tools that let you publish very large images to the web and view them while panning and zooming between thumbnail size and full resolution, i.e. So I used a background image of equal size and composite the photo in the middle for both runs to generate the data above.Large Image Viewer Overview and Motivation I thought it might have something to do with when you're using the minimum size you have less data to scale which would improve speeds. Using the original photo size it averaged 1.2198 seconds/frame. The run using the minimum size trick and always upscaling averaged 0.4144 seconds/frame. I ran 30 simulated frames on the same photo using real movements generated from our system. On my Ubuntu dev machine I broke out some old code I was using to speed test sections of our code using perls' HiRes::Time. perhaps there is a bug in the PerlMagick implementation and not in the core code. Conceptually simpler that SRT and faster, but the arithmetic is messier. I'll also mention "-distort perspective". But I'm usually working with video frames rather than making a video from stills, so your trick of zooming to the maximum, then then scaling up for each frame, wouldn't help me. Snibgo wrote:I hadn't noticed a speed difference between 0.94 and 1.06 scaling, and a quick test (v6.8.8-0 on Windows 8.1) suggests there is none. or you could always download a 30 day trial of After Effects and knock it out. ![]() I've been working on this exact process for a little over a year and hope some of my pain points will save you some headache! The output looks fine for scaling less than about 30% increase. To get around this we resize the input image to the smallest size it will be throughout the zoom, and then always scale up. I've seen anthony explain it somewhere, I think it has something to do with the way SRT supersamples. We process in 720p and doing a frame where the picture is scaled using SRT to 0.94 or some small increment takes about 3-5X as long as going up an equal amount, such as to 1.06. You could also accomplish this with cropping, but you've got to nail your math down perfectly - for me it's easier to just composite with gravity and cookie-cut.Īlso, at least under Ubuntu with 6.8.7-9 Q8 scaling down in minute increments takes many times as long as going up - especially for larger pictures. Do SRT to handle sub-pixel scaling AND translation, then cookie cutter it via composite onto the output size. You want to use a blank canvas your output size as a kind of cookie cutter. The solution here is to use a set background and let SRT handle it all. Subpixel movement is tough to get right without using something really powerful like After Effects. If you're using Sony Vegas or Premiere or any NLE for the final output you're going to see it pop up. This exact problem will also surface in minute translations as well. Once composited onto output you can imagine these jumps where the edges stair step instead of smoothly zooming. You can already start to see the problem, you've got multiple frames of the same size because the true size is being forced to the lowest denominator of size, an even pixel. And one more step would be +distort SRT "1.065,0", output 34x56. If you were doing a zoom and stepped to +distort SRT "1.060,0" the output would be 34x56. 2 pixels are added by SRT so your true size is 32x52, when you're idealized size (by multiplying with a calculator) is 31.65x52.75. Then you go an composite these all in your timeline and you get what I refer to as jitter - the edge pixels hop around because of the rounding.Ī great way to see this is take a 30x50 photo, and do +distort SRT "1.055,0". The power of SRT is what if you wanted to zoom at 2.4 pixels per frame (or any non trivial number) - using simple +distort you'd get one frame where the pixels are shaved off. For instance if you wanted to go from a height of 10 pixels to a height of 20 pixels across 10 frames (a simple zoom) you'd be good to go since you're always moving in whole pixels (2) such that you can add a pixel on top and bottom and output. ![]() Snibgo is absolutely right SRT is the way to go because it allows what I'm going to call sub-pixel movements. I do this every day! The basics are well covered from other replies (snibgo is a ninja!) but here are some caveats I've ran into in the past
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |