(04-27-2021, 12:00 PM)rich2005 Wrote: Depends what you want to do. All the script does is save a moving window as a series of images. It is quick, 180 images in a couple of seconds. Not going to be that quick wrapping an image around with the offset filter.
As an animation and thinking of your other post some comparisons.
You're absolutely right. And I wish that I had your skill and confidence in working with command-line programs. But from where I stand, the learning curve looks mighty steep. (maybe some day I'll be near enough to where you are, sufficient that I'll feel comfortable getting something like that working. )
What I'm kinda working towards now is depicted in the following diagram, where the original image is the cross hatched area, expanding the canvas to include the blank background area to it's left, that will ultimately be the viewing area for the animation.
Selection made to include only the blank background area, and then using the offset filter to shove the image through the viewing area "X pixels" per iteration. Doing a copy and export for each.
![[Image: TLuePWP.png]](https://i.imgur.com/TLuePWP.png)
Please excuse my poor representation of the marching ants.
Is there an easy way to make the exported copies all layers in a separate new image? That would be a real time saver.
(04-27-2021, 12:00 PM)rich2005 Wrote: As a gif animation, 14.3 MB Not much optimisation with this type of image.
A webp using Gimp, 4.2 MB and lossy compression and took 1'30"
I was noticing the other night how long lossy compression for WebP was taking.
I had a 320x240 animated GIF that was 400 frames long.....23.5 MB
Converting to non lossy WebP reduced the file size to 19 MB
Converting to lossy WebP with a 90% quality factor, reduced the file size to 8.9 MB, but took forever to complete. So long in fact that I opened Gkrel to observe the CPU loading. I've got a twin core Machine with hyperthreading, which appears as 4 cores to most bench marking software. And, as the lossy compression was running, I observed that the task routing was not evenly shared among the CPUs. at any given time one of the 4 would be peaked, while the other 3 were coasting. and while the "peak" was moved around from core to core, at any given time the other 3 would be virtually dormant. Doesn't seem like an ideal implementation of multi-tasking .
Not sure if this was a Gimp thing, a Linux thing, an Intel firmware thing, or a Gkrel thing, but you'd suspect that more even loading might speed things up a bit?