There is nothing wrong. You are not converting your coordinates properly, hence a different area than the one you expect is being sampled. Especially with shape layers this can be extremely tricky due to the individual transforms of each group. Layer space transforms are your friend or write your own compensation code.
It would really help if we could see the properties of all layers involved. I don't know what the layer Luma is or what it does.
I take it that you color sample the location of the point control and convert that to frames to drive the time remapping.
Is the time remapped layer the red square? When you pre-composed did you move all attributes? What are the other properties of the red square layer?
Your expression works just fine with this project. I only changed the max number of frames.
Dropbox - bouncyThingie_CC.aep(Note: Dropbox will add a .txt expression to the .aep file. Just remove it to open the sample file)
Thank you both for taking a look!
Rick, you example is perfect, I edited it with that I described in main post, white line, and it happens again, I uploaded the modified file and here is a screenshot to make it clear what is not working.
is it something I am doing wrong?
Well it turns out it has nothing to do with sampleImage, it is a pure Time Remap problem
if you remove the expression all together and simply keyframe Time Remap:
frame 0 - value 0
frame 1 - value 149
frame 2 - value 0
it has the same problem, the result is the same for frames 0 and 1, both show frame internal frame 149...
This it totally unusable, does anyone know of an alternative or something, I wold really like to get this to work...
I think you have found a bug. Set frame 0 to anything but 0 and it works or move the third keyframe to frame 3 and it works. I'm not sure what's going on mathematically but all it takes is a one frame separation. IOW, set the keyframes to 1, 149, 0 or 0, 149, 1, 0 and everything works.
Here's the deal, at 29.97 or even 20 fps a single frame of the image popping in and out of a major position shift is not going to register with most audiences. If you really want the motion to jump then you have to enable hold keyframes.
I'm not saying that this bug doesn't matter but I can't see a situation where it would be useful to stutter one frame for only one frame. This works just fine if you make the distance between keyframes 2 frames.
Rick, thanks for checking.
The example I provided was a only a segment of my setup, I have a grid of rectangles 21x21, and if you imagine a vertical line traveling from left to right, the rectangles should "turn on" only when over a line, so this looks very wonky with this bug... this is just the situation where it goes really wrong and it is noticeable... so in this situation this bug matters.
After trying to figure out a work around, I noticed this bug appears only when I am remapping a composition, not a footage, so I "solved" it by prerendering what is in the composition that I am remapping.
But still, lost so much time for something so basic...
Thanks again for your time,