A question about Operator "crop" and "slice".

[ascust]

In the document, it says "crop is deprecated. Use slice instead". But I think "slice" is not a complete alternative to "crop", because "crop" can use a "reference" symbol as an input, while "slice" can only use fixed parameters to crop. Sometimes, the input can have various size, we can not define everything in advance. In the future release, is "crop" going to be kept?

[reminisce]

Can you give the precise definition of crop? It's too vague to get the difference between crop and slice in your statement. Maybe a few examples are helpful here.

[ascust]

@reminisce
For example, for "crop", we can have something like this:

data = mx.sym.Variable("data")
ref = mx.sym.Variable("ref")
cropped_data = mx.sym.Crop(data, ref)

For "slice", I don't see the argument for this "reference" symbol.

[reminisce]

What is the role of ref here? What's the expected behavior of Crop in your code?

[ascust]

@reminisce
In the official doc,

Crop the 2nd and 3rd dim of input data, with the corresponding size of h_w or with width and height of the second input symbol, i.e., with one input, we need h_w to specify the crop height and width, otherwise the second input symbol’s size will be used.

The role of "ref" is to show the target shape of the cropped_data.

[reminisce]

Are you referring to the definition here: https://turi.com/products/create/docs/generated/graphlab.mxnet.symbol.Crop.html?

I don't think we are aligning with the doc on that website.

It's looks to me that you can prepare the proper params of begin, end, and step for using slice to achieve the same purpose.

[reminisce]

I just checked the code, there is indeed a Crop (upper-case C) operator working as you described. What has been deprecated is crop (lower-case c).

[ascust]

@reminisce It seems both Crop and crop are deprecated in the documentation. So are you saying the documentation is a bit out-of-date? Maybe it can be fixed for avoiding confusion.

[reminisce]

I don't know why Crop is deprecated, but it looks like so. As I said in a previous comment, you can use slice to achieve the same purpose of Crop if you want. Let me know if you have trouble in doing that.

[ascust]

@reminisce For fixed-sized input, your way has no problem, but image we have various input size for both "data" and "ref", we cannot keep creating new symbols and modules, that would not be an efficient way.

[Pagey]

I too second that we need to keep Crop with a "crop_like shape reference"
It seems to be working in current version (1.2.0), with usage:
kak = mx.symbol.Crop(kak_before,zai)

where zai is the shape reference symbol

[AnaRhisT94]

Hi, I'm trying to use the slice instead of crop because ONNX doesn't support Crop properly - and I don't want to change ONNX's function. but rather use Slice instead.
When changing Crop to slice_axis with axis=1 on a pretrained model in the .json, I'm getting an error when trying to use that sliced node. More precisely, I feed a 128x80x60 shaped node to a elemwise_add node which takes as input same 128x80x60 nodes and adds them together. Which works great with the Crop operation in the .json file, changing it to Slice operation properly (checked the dimensions - they match in the add operation) it gives an error.
Getting this error:

onnx.onnx_cpp2py_export.checker.ValidationError: Node (slice_axis) has input size 1 not in range [min=3, max=5].
Also:
==> Context: Bad node spec: input: “ssh_m2_red_upsampling” output: “slice_axis” name: “slice_axis” op_type: “Slice” attribute { name: “axes” ints: 1 type: INTS } attribute { name: “ends” ints: 128 type: INTS } attribute { name: “starts” ints: 0 type: INTS }

Any ideas how to solve this?

[ChaiBapchya]

Hey @AnaRhisT94 sorry for delayed response. Did your problem get resolved? If not, can you give a minimum reproducible script for the same?