duplicate operator: inverse range parameter not working for IM7

[piridium]

Prerequisites

[ x ] I have written a descriptive issue title
[ x ] I have verified that I am using the latest version of ImageMagick
[ x ] I have searched open and closed issues to ensure it has not already been reported

Description

According to the legacy docs (https://legacy.imagemagick.org/Usage/anim_mods/#patrol), a patrol-cycle style animation is created by reversing the range parameter of the duplicate operator. However, this does not work in ImageMagick 7.

Steps to Reproduce

For a patrol-cycle style animation, we want to append all the frames in reverse except for the first and the last frame.
While appending the frames in forward order works as expected:
magick xc:#000 xc:#001 xc:#002 xc:#003 xc:#004 -duplicate 1,1--2 info:
Frames 0, 1, 2, 3 and 4 are followed by 1, 2 and 3:

xc:#000[0] XC 1x1 1x1+0+0 16-bit sRGB 0.000u 0:00.000
xc:#001[1] XC 1x1 1x1+0+0 16-bit sRGB 0.000u 0:00.000
xc:#002[2] XC 1x1 1x1+0+0 16-bit sRGB 0.000u 0:00.000
xc:#003[3] XC 1x1 1x1+0+0 16-bit sRGB 0.000u 0:00.000
xc:#004[4] XC 1x1 1x1+0+0 16-bit sRGB 0.000u 0:00.000
xc:#001[5] XC 1x1 1x1+0+0 16-bit sRGB 0.000u 0:00.000
xc:#002[6] XC 1x1 1x1+0+0 16-bit sRGB 0.000u 0:00.000
xc:#003[7] XC 1x1 1x1+0+0 16-bit sRGB 0.000u 0:00.000

Reversing the range parameter...
magick xc:#000 xc:#001 xc:#002 xc:#003 xc:#004 -duplicate 1,-2-1 info:
... we would expect to see frames 0, 1, 2, 3 and 4 followed by 3, 2 and 1, but instead we get no change:

xc:#000[0] XC 1x1 1x1+0+0 16-bit sRGB 0.000u 0:00.000
xc:#001[1] XC 1x1 1x1+0+0 16-bit sRGB 0.000u 0:00.000
xc:#002[2] XC 1x1 1x1+0+0 16-bit sRGB 0.000u 0:00.000
xc:#003[3] XC 1x1 1x1+0+0 16-bit sRGB 0.000u 0:00.000
xc:#004[4] XC 1x1 1x1+0+0 16-bit sRGB 0.000u 0:00.000

There is a discussion here. Thanks @GeeMack for your help!

Proposed solution

Depending on the intended behavior of "-duplicate" and "-clone" either fix the inverse range method or update the docs with the workaround suggested by @GeeMack.

System Configuration

• ImageMagick version: ImageMagick 7.0.10-57 Q16 x86_64
• Environment (Operating system, version and so on): macOS 10.14.6
• Additional information: @GeeMack also tested with ImageMagick 7.0.10-56 Q16 x64 on Windows 10

[snibgo]

The example shown works fine with IM v7.0.8-64:

f:\web\im>%IMG7%magick xc:#000 xc:#001 xc:#002 xc:#003 xc:#004 -duplicate 1,-2-1
 info:
xc:#000[0] XC 1x1 1x1+0+0 16-bit sRGB 0.016u 0:00.011
xc:#001[1] XC 1x1 1x1+0+0 16-bit sRGB 0.031u 0:00.021
xc:#002[2] XC 1x1 1x1+0+0 16-bit sRGB 0.031u 0:00.030
xc:#003[3] XC 1x1 1x1+0+0 16-bit sRGB 0.031u 0:00.039
xc:#004[4] XC 1x1 1x1+0+0 16-bit sRGB 0.016u 0:00.047
xc:#003[5] XC 1x1 1x1+0+0 16-bit sRGB 0.016u 0:00.056
xc:#002[6] XC 1x1 1x1+0+0 16-bit sRGB 0.016u 0:00.067
xc:#001[7] XC 1x1 1x1+0+0 16-bit sRGB 0.031u 0:00.077

But it fails with v7.0.10-45:

f:\web\im>%IMG701010%magick xc:#000 xc:#001 xc:#002 xc:#003 xc:#004 -duplicate 1,-2-1 info:
xc:#000[0] XC 1x1 1x1+0+0 16-bit sRGB 0.000u 0:00.123
xc:#001[1] XC 1x1 1x1+0+0 16-bit sRGB 0.000u 0:00.157
xc:#002[2] XC 1x1 1x1+0+0 16-bit sRGB 0.016u 0:00.165
xc:#003[3] XC 1x1 1x1+0+0 16-bit sRGB 0.016u 0:00.174
xc:#004[4] XC 1x1 1x1+0+0 16-bit sRGB 0.016u 0:00.183

So it is a bug introduced between these versions.

[urban-warrior]

Thanks for the problem report. We can reproduce it and will have a patch to fix it in the GIT master branch @ https://github.com/ImageMagick/ImageMagick later today. The patch will be available in the beta releases of ImageMagick @ https://www.imagemagick.org/download/beta/ by sometime tomorrow.

[piridium]

I confirm that 7.0.10-58 fixes the bug. Thanks @urban-warrior for your great work!