PadIfNeeded seems to not correctly work with ReplayCompose in certain cases

[fhung65]

🐛 Bug

Using ReplayCompose with PadIfNeeded seems to not reproduce the transform if a non-default value of "position" is used

To Reproduce

Steps to reproduce the behavior:

import numpy as np

from albumentations import ReplayCompose
from albumentations.augmentations.geometric.transforms import PadIfNeeded

IM_HEIGHT = 124
SQUARE_SIZE = 256
img = np.random.rand(IM_HEIGHT, SQUARE_SIZE, 3)

transform_pad_br = ReplayCompose([
    PadIfNeeded(
        min_height=SQUARE_SIZE,
        min_width=SQUARE_SIZE,
        position=PadIfNeeded.PositionType.BOTTOM_RIGHT, # <--- default is CENTER
        border_mode=0, # AKA cv2.BORDER_CONSTANT
        value=0,
        mask_value=0,
    ),
])

# original
test_pad = transform_pad_br(image=img)

# replay
replay_data = test_pad['replay']
test_replay_pad = ReplayCompose.replay(replay_data, image=img)

Expected behavior

Original pad has a top bar (BOTTOM_RIGHT position)

import matplotlib.pyplot as plt
plt.imshow(test_pad['image'])
plt.show()

But, the replayed pad has top/bottom bars (default CENTER position)

plt.imshow(replay_test_pad['image'])
plt.show()

Environment

• Albumentations version (e.g., 0.1.8): 1.3.0 (also tested 1.3.1)
• Python version (e.g., 3.7): 3.7.10
• OS (e.g., Linux): Ubuntu 22.04.3 LTS
• How you installed albumentations (conda, pip, source): pip
• Any other relevant information:

Additional context

hacking 'position' back in seems to help

# fix
import copy
new_replay_data = copy.deepcopy(replay_data)
new_replay_data['transforms'][0]['position'] = PadIfNeeded.PositionType.BOTTOM_RIGHT
fixed_replay_pad = ReplayCompose.replay(new_replay_data, image=img)
assert(np.all(fixed_replay_pad['image'] == test_pad['image']))

# note:
# maybe a fix is to update PadIfNeeded.get_transform_init_args_names() to also return 'position'
# but I'm not sure what else this effects

[dash-uvic]

Possibly related. If you use PadIfNeeded with RandomScale, it calculates the padding for OpenCVs copyMakeBorder for the initial image/mask size, not from the incoming image/mask from the Compose pipeline. Since RandomScale doesn't preserve that input shape, it'll be padded to a random size. Which caused me a hell of a headache trying to figure out why my crops were failing.

[ternaus]

Thanks. Will look into both issues.

[ternaus]

I believe this issue was fixed in #1570

I cannot reproduce this bug in version 1.4.2

[ternaus]

Possibly related. If you use PadIfNeeded with RandomScale, it calculates the padding for OpenCVs copyMakeBorder for the initial image/mask size, not from the incoming image/mask from the Compose pipeline. Since RandomScale doesn't preserve that input shape, it'll be padded to a random size. Which caused me a hell of a headache trying to figure out why my crops were failing.

Could you please share an example that I could reproduce?