Can somebody explain what is the logic behind that the VSE transform position attributes are integer data type?
The position X/Y are pixel values as the UI hints:
And that means (AFIK) if we animate those attributes it results a kind of a stepped animation curve:
And the animation is obviously stop/stepped motion accordingly. I think this is definitely not what we want most of the time.
Pixel is not divisible, and previously offset values were integer, so they have been kept as integer. Why do you think this is an issue?
I understand that pixel is not divisible that is why 2D transformations are filtered/interpolated in CGI (as the Transformation Effect Strip is) . So maybe it is more precise to ask: why the 2D transform of a strip is not filtered?
During preview nearest interpolation is used and bilinear for rendering. This decision has been questioned in âš™ D12807 VSE: Added filter mode to strip transform.
But you are correct in that using float values can result in smoother looking animations, which I haven’t thought about. I think this would be good idea to change. Thanks for feedback!
I tried to find a solution to this exact issue. I’m making a slideshow using the vse, where pictures are zoomed and moved continuously. I believe in earlier versions of blender, this could be done using the “transform” effect in vse, because its position is stored as a float. In that case, the offset and scaling of the original image strip had to be disabled and a box had to be ticked in the “crop” field, giving the “transform” effect direct access to the full image data (as far as I remember). With the current version of blender, this no longer works (the offset, scaling and cropping of image strips in the vse can’t be disabled anymore). Therefore, the original image is first scaled or cropped to the scene render size, where data is lost. This version of the image is then used as the input of the “transform” effect.
I tried animating the position of the original image strip in the vse. This did not look nice because the one-pixel-steps are clearly visible in the finished animation. So I dug a little deeper and took a look at the source code. As it turns out, it may be sufficient to change the data type of the position value of sequencer strips from int to float. At least, it works well in my case. It’s also backward compatible as far as I tested.
The only code changes necessary are:
blender/source/blender/makesdna/DNA_sequence_types.h
...
typedef struct StripTransform {
float xofs;
float yofs;
...
blender/source/blender/makesrna/rna_sequencer.c
...
prop = RNA_def_property(srna, "offset_x", PROP_FLOAT, PROP_PIXEL);
RNA_def_property_float_sdna(prop, NULL, "xofs");
RNA_def_property_ui_text(prop, "Translate X", "Move along X axis");
RNA_def_property_ui_range(prop, -FLT_MAX, FLT_MAX, 1, 6);
RNA_def_property_update(prop, NC_SCENE | ND_SEQUENCER, "rna_SequenceTransform_update");
prop = RNA_def_property(srna, "offset_y", PROP_FLOAT, PROP_PIXEL);
RNA_def_property_float_sdna(prop, NULL, "yofs");
RNA_def_property_ui_text(prop, "Translate Y", "Move along Y axis");
RNA_def_property_ui_range(prop, -FLT_MAX, FLT_MAX, 1, 6);
RNA_def_property_update(prop, NC_SCENE | ND_SEQUENCER, "rna_SequenceTransform_update");
...
The next problem in my usage case is Moiré artifacts caused by the bilinear down-scaling. My pictures are 32 megapixels in size and the render size is 1080p. Blender’s bilinear transformation is only good for down-scaling up to a scale factor of 0.5. But that’s a story for another time.
I see, thank you very much! I’m looking forward to seeing this in an upcoming release.
