[Aaron Pozzer]

sure, lets call it subpixel sampling. whatever the term, or the problem, the screenshots illustrate the issue, and since im pretty sure i found the solution ill consider it solved to my satisfaction. though, its always good to have the link incase anyone else comes looking for answers to the same problem. thanks walter.

[Aaron Pozzer]

even further testing tells me its the size of the image that matters. maybe this is some long known thing about AE that no one ever told me.

if i take 1 of my blurry screenshots (that was from a window with an odd size pixel dimension, (eg 1879×1229)) and paste it into a new doc in photoshop that is 1000×800 (arbitrary #s), save that and open it in AE, it looks fine. so why was it blurry in the original screenshot?

conversly, if i do the same thing but paste that seemingly blurry screenshot into a new PS doc that is 1001×801 (again, arbitrary, but +1 on both dimensions), save that and open it is AE, its looks blurry again.

so clearly the source, the original screenshot, is not the problem. its the dimensions of the image… the canvas size. if the original screenshot can look blurry in 1 version, and clear in the next and the only thing thats changed is 1 pixel in the DOCUMENT SIZE (the original source was NOT scaled), then its clearly how AE treats odd sized documents.

the lesson here is ALWAYS USED EVEN PIXEL DIMENSIONS IN AE!

[Aaron Pozzer]

i think i figured it out…

i must have gotten UNlucky and picked a window size with an odd # of pixels in either dimension when i did a screen shot of my viewport window that contained the render queue, and the concrete/grass jpg.

i did a screenshot of my timeline, NONmaximized (so just floating above the desktop), opened it back up in AE and it was sharp, so i thought it cant be a window size issue, but then thought maybe its an odd/even pixel count issue. i checked in PS and the window just happened to ve 1880×1230. so i scaled that timeline window down by 1 pixel both ways so it became 1879×1229, screenshot, open in AE, and it was blurry. ive made another screenshot to show the difference…

its clearly visible here. i also marked where the AE viewport was so its not confused with what WASNT part of the screenshots.

so… why does a window being 1 pixel odd make a difference? i have no idea, but it seems it does. im HOPING this is the answer and the cause. id still like someone to try and replicate this for me.

[Aaron Pozzer]

still testing…

even more strange, i took a screenshot of facebook in a firefox window. opened it in AE, blurry. maximized the firefox window so it was full screen, did another screenshot, opened that, and it looked fine.

i think tried a screenshot of my other screen in AE where i keep my timeline and layers. that window is always full screen. opened that back up, and it looked fine. compared to my originally posted image, my viewer and render queue are in a group of windows on my other screen and were not maximized to the full screen size, though pretty close. i dragged the edges of the window out as close as i could to match the screen size, did another screenshot, opened it back up, and it was fine. no blurry text.

this is even more confusing because what does the size of a window have to do with a screenshot OF that window. it should all just be 1:1 pixels saved as a jpg, and opened back up in AE, viewed 1:1 and look sharp. so why is that only happened when screenshots are taken of windows that are maximized?

id realy appreciate it if someone could replicate this issue for me… it only takes a second to do. then ill know if its me, or if its a windows thing, or an AE thing, or something!

[Aaron Pozzer]

hi walter, thanks for the reply, but the 50% is not the issue. take another look at the posted jpg. you’ll see the real render queue, at the bottom, then above, you will see the jpg screen shot of AE showing a render queue, and a jpg in the viewport (concrete and grass). the image in the viewport isnt the issue, so ignore the concrete/grass area.

look closely at the screen shot of the render queue, between the red line. look at the text (plainly obvious when you compare the 2 ‘active camera’ buttons). you will see above ‘blurry’ the text is not sharp, and above ‘crisp’ it is sharp. youll also see that this screen shot is at 100%, and since its impossible to view the render queue at anything less than how its displayed on the screen, its is by default a 1:1 comparison showing the loss of jpg detail. its clearly visible in the text.

now if this is just how AE displays things, ok, but i dont think thats the case.

i did a bit more fiddling around yesterday and found that usualy as long as the image is equal to, or bigger, than the comp its going into, its fine. smaller and you get this blurring. i have no idea why this would be as long as no scaling is happening. as long as the comp is on 100%, full, final quality, the jpg should appear the same weather viewed in AE, PS, or windows photoviewer, regardless of its dimensions (unscaled) and thats not currently the case… at least not with the screenshot of a screenshot posted.

sorry is this is overly confusing. i can probably create a better example that isnt an endless screenshot tunnel of AE viewports, haha.

[Aaron Pozzer]

i used ST2 once for an entire 13 episode project with no problems. didnt touch it for about a year and came back to it today and had the same off-center problem. thought it was a cs5 cs6 issue, but no.

i was able to solve the problem by adjusting the Point Of Interest on the camera, or the Anchor Point on the ST2 layer (in the actual transforms). i also had all my 3d layers parented to a central null, which ALSO screwed things up, and that had to be adjusted on the anchor point as well.

all i did realy was make sure the ST2 layer was visible (i usually keep it hidden so i dont see the solid layer box), then drag the anchor points around until things started to center. turned out the #s needed to be centered (in my case, 960.540.0), and i dont know how they got UNcentered.

anyway, just thought this was frustrating and since i didnt find an answer, i thought id share.

[Aaron Pozzer]

Sweet! Thanks paul! World/local woulda been my next question 😉

[Aaron Pozzer]

after a bit of fiddling, it seems that its the yRot on the camera that gives the slightly off results. when the camera is down, close to the map/ground, and rotated to be looking towards the horizon, the more oblique the angle, the more off the returned result.

im not sure if there is a proper way to correct for this in the script, but i did this…

C = thisComp.layer("TRGT: Goal");
v = C.toWorldVec([1,0,0]);
rot = radiansToDegrees(Math.atan2(v[1],v[0]))

rot -(thisComp.layer("TRGT: Goal").transform.yRotation/2)

(the camera is animated with sure target, so i changed the c from looking at the camera, to looking at the target. doesnt seem to make a differnce in the results, but just fyi).

i tried it without the /2, but that corrected by TOO much. so half seems to yeild better results, at least in this particular circumstance. its by no means a global fix, as it completely doesnt work on a different object earlier in the animation.

[Aaron Pozzer]

yes! thats the one! if i had to be super nit picky, the value the expression returns is a BIT off… only by a few degrees. im guessing this is probably just a result of the x and y rotation adding a bit of perspective or something that is not being accounted for in the expression. but its 100% better than having to do it by hand 🙂

thanks dan.

edit: ya i think thats the case because as the camera moves to a more head-on angle, that few degrees becomes less and less.

[Aaron Pozzer]

spoke too soon… this doesnt quite work. at least, doesnt work when applied to the zRot channel to keep the text lined up to screen horizontal.