[Dup] Fix SAME_UPPER/SAME_LOWER (auto_pad attribute) in ConvTranspose

[jcwchen]

Description:
Dup of #5368. Recreate this PR for cleaner commit log. Target it to ORT 1.10

To sync the definition of SAME_UPPER/SAME_LOWER among all operators and make it same as ONNX definition, switch the logic of SAME_UPPER and SAME_LOWER in ConvTranspose.

Definition of SAME_UPPER and SAME_LOWER should be as follows:

if auto_pads == 'SAME_UPPER':
  pad_head = paddings / 2  # smaller one 
  pad_tail = paddings - paddings / 2  # larger one
elif auto_pads == 'SAME_LOWER':
  pad_head = paddings - paddings / 2  # larger one
  pad_tail = paddings / 2  # smaller one

Motivation and Context
The auto_pad attribute, SAME_UPPER and SAME_LOWER of ConvTranspose is different from other operators' (pool and conv related operators) auto_pad attribute. The behavior of same attribute should be the same among all operators. Also, it does not meet the definition in ONNX.

• SAME_UPPER and SAME_LOWER in other operators
  

  onnxruntime/onnxruntime/core/providers/cpu/nn/pool_attributes.h

  Line 149 in c20fcf2

  *pad_head = pad_needed / 2;

• ConvTranspose definition in ONNX:
  https://github.com/onnx/onnx/blob/b2ed660d0a065b8346816f2c3a95d79ca79b88c9/onnx/defs/nn/defs.cc#L1222
• A related PR in ONNX (There is a contradiction of this in ONNX):
  Update spec for Convtranspose to make it sync onnx/onnx#3019

[jcwchen]

Globally remove cntk_simple_seg for now because it produces wrong output with old implementation. I will add it back after updating the output in another PR

[stale]

This issue has been automatically marked as stale due to inactivity and will be closed in 7 days if no further activity occurs. If further support is needed, please provide an update and/or more details.

[jcwchen]

Please note that this issue still exists.

[jcwchen]

@hariharans29 do you have time to review this PR? I just rebased this old PR with the latest branch. There are two issues about it already: 9370, 11927. Since it's a computation behavior change in ORT, do you have any concern regarding backward compatibility? Thank you.

[hariharans29]

@hariharans29 do you have time to review this PR? I just rebased this old PR with the latest branch. There are two issues about it already: 9370, 11927. Since it's a computation behavior change in ORT, do you have any concern regarding backward compatibility? Thank you.

IMO should be a "bug fix" rather than "breaking change" - so I think it should be okay. Any conerns @pranavsharma ?

[pranavsharma]

@hariharans29 do you have time to review this PR? I just rebased this old PR with the latest branch. There are two issues about it already: 9370, 11927. Since it's a computation behavior change in ORT, do you have any concern regarding backward compatibility? Thank you.

IMO should be a "bug fix" rather than "breaking change" - so I think it should be okay. Any conerns @pranavsharma ?

I can't really say how many models deployed in production would break because of this fix. Can we

1. print a warning for the upcoming 1.12 release
2. mention this in the release notes under the "Upcoming backward incompatible bug fixes" section
3. actually fix the bug in 1.13 release?

[jcwchen]

Thank you both. @pranavsharma your plan looks good to me. I have proposed another PR to print warning for upcoming 1.12 first: #11984.