Quote:
Originally Posted by Gavino
I've ditched SplitScreener from your example and used ZoomBoxer directly with my own test image.
|
My guess on why it isn't working is that you are using Avisynth 2.57. I'm currently using 2.58.
Changelog documents this "Relax YV12 resizer width restriction, now mod 2 was mod 4."
Quote:
Originally Posted by Gavino
It seems to work fine for the simple cases I tried. However, I have a few questions and comments.
What is the meaning of align=0 (the default value)? In the case align=0 and the ARs match (DisplayAR=FinalAR), x1 etc are undefined as there is no code to handle this combination.
|
If Align is not specified, then the float inputs of x1,y1,x2,y2 will be used. That is what Align=0 is for. I took out x1,y1,x2,y2 so i could test align by it's self. The final version will have what i call Mode 1: x1,y1,x2,y2 and Mode 2: Align.
Quote:
Originally Posted by Gavino
Are panX and panY in pixel units of the input clip or the output clip? It seems to be the former, but how are they meant to interact with zoom?
|
You are correct, panX/panY are in pixel units of the input clip. Pan could be used before zoom, or after zoom. For large values of zoom, I think it will make a difference. Now that i think about it, pan should go in before zoom, that way it is independent of zoom.
Quote:
Originally Posted by Gavino
I'm still confused about the intended meaning of zoomFactor - I think this is partly because there is already an implicit zoom happening if the input and output clips differ in size. Can you explain this further please?
|
zoomFactor is very useful when using align. If it wasn't for align, zoomFactor is quite useless. In the end ZB() will either take x1,y1,x2,y2 or Align. When only using Align, it would be impossible to zoom in/out to your desired level. Tac offered a better way of doing things, when compared to my
orginal idea on how to use Align.
Quote:
Originally Posted by Gavino
In any case (whatever the answer to the above), the code to recalculate x1 (etc) based on zoomFactor looks wrong to me
because x2 and y2 are calculated using the possibly already changed values of x1 and y1 (and where on earth does the value 2.4 come from?)
|
Thank you for pointing that x2 and y2 are calculated using the already changed values of x1 and y1. I didn't see it! The 2.4 was originally 2, but through trial and error, 2.4 gave better results then 2. 2 is half of 4, so that is where it comes from.
I'm looking on the web for code on how to do the zoom. Right now mine is linear, which is why it messes up when zooming in too much. I think it needs to be shaped like a
Logarithm, thus 100*.01=1, and it can never reach 0 when zooming out. I just need to figure out how to limit the zooming in so that the zoom point doesn't cross it's self. I'll post some new code in an hr or 2... but if you can point me to some code where zoom of 100% is unchanged and 200% is twice as much, ect... i would appreciate it.