Hi!\nI think there is discrepancy between the competition rules and the actual way to submissions are checked. In the most popular kernels for mask-to-RLE encoding (https://www.kaggle.com/stainsby/fast-tested-rle, https://www.kaggle.com/paulorzp/fast-run-length-encode) the competitors use .flatten() method on a mask which concatenates rows ([r0, r1, r2, ...]). So the order of elements is (1, 1), (1, 2), etc. And it seems that is working for them perfectly fine.\nFor example, from Sam's kernel:
est_mask = np.asarray(\n [[0, 0, 0, 0],\n [0, 0, 1, 1],\n [0, 0, 1, 1],\n [0, 0, 0, 0]])\nassert rle_to_string(rle_encode(test_mask)) == '7 2 11 2'\nOn the other hand, the competition rules say The pixels are numbered from top to bottom, then left to right: 1 is pixel (1,1), 2 is pixel (2,1), etc., i.e. the above is not correct, as the RLE codes are expected to be built in a column-first manner: [c0, c1, c2, ...].
So, the correct RLE for the example above has to be 10 2 14 2.
I've tried both methods, but my submissions fail on the second one due to a timeout.\nCould someone, please, clarify the correct format? If I'm right, the competition rules has to be fixed.
", "messages": [ { "id": "208817", "postDate": "07/31/2017 06:40:10", "content": "Hi!\nI think there is discrepancy between the competition rules and the actual way to submissions are checked. In the most popular kernels for mask-to-RLE encoding (https://www.kaggle.com/stainsby/fast-tested-rle, https://www.kaggle.com/paulorzp/fast-run-length-encode) the competitors use .flatten() method on a mask which concatenates rows ([r0, r1, r2, ...]). So the order of elements is (1, 1), (1, 2), etc. And it seems that is working for them perfectly fine.\nFor example, from Sam's kernel:
est_mask = np.asarray(\n [[0, 0, 0, 0],\n [0, 0, 1, 1],\n [0, 0, 1, 1],\n [0, 0, 0, 0]])\nassert rle_to_string(rle_encode(test_mask)) == '7 2 11 2'\nOn the other hand, the competition rules say The pixels are numbered from top to bottom, then left to right: 1 is pixel (1,1), 2 is pixel (2,1), etc., i.e. the above is not correct, as the RLE codes are expected to be built in a column-first manner: [c0, c1, c2, ...].
So, the correct RLE for the example above has to be 10 2 14 2.
I've tried both methods, but my submissions fail on the second one due to a timeout.\nCould someone, please, clarify the correct format? If I'm right, the competition rules has to be fixed.
", "rawMarkdown": "Hi!\nI think there is discrepancy between the competition rules and the actual way to submissions are checked. In the most popular kernels for mask-to-RLE encoding (https://www.kaggle.com/stainsby/fast-tested-rle, https://www.kaggle.com/paulorzp/fast-run-length-encode) the competitors use `.flatten()` method on a mask which concatenates rows ([r0, r1, r2, ...]). So the order of elements is (1, 1), (1, 2), etc. And it seems that is working for them perfectly fine.\nFor example, from Sam's kernel:\n\n est_mask = np.asarray(\n [[0, 0, 0, 0],\n [0, 0, 1, 1],\n [0, 0, 1, 1],\n [0, 0, 0, 0]])\n assert rle_to_string(rle_encode(test_mask)) == '7 2 11 2'\n\nOn the other hand, the competition rules say `The pixels are numbered from top to bottom, then left to right: 1 is pixel (1,1), 2 is pixel (2,1), etc.`, i.e. the above is not correct, as the RLE codes are expected to be built in a _column-first_ manner: [c0, c1, c2, ...].\n\nSo, the correct RLE for the example above has to be `10 2 14 2`.\n\nI've tried both methods, but my submissions fail on the second one due to a timeout.\nCould someone, please, clarify the correct format? If I'm right, the competition rules has to be fixed.", "votes": null }, { "id": "208819", "postDate": "07/31/2017 06:45:15", "content": "Agreed, I've been using this kernel and got good results, not to mention it actually verifies the train masks. I think the wording should be \"The pixels are numbered from left to right, then top to bottom: 1 is pixel (1,1), 2 is pixel (1,2), etc.\"
", "rawMarkdown": "Agreed, I've been using this kernel and got good results, not to mention it actually verifies the train masks. I think the wording should be \"The pixels are numbered from left to right, then top to bottom: 1 is pixel (1,1), 2 is pixel (1,2), etc.\"", "votes": null }, { "id": "208882", "postDate": "07/31/2017 13:44:40", "content": "A few days ago I came across the same issue when I saw the rules, because I thought \"hey its not good to use column-wise computation, since we have more mask pixels row-wise.\" Than I started to check the rle/flatten calls as well:
\n\nIf you look at the shape after ndimage.imread and PIL.open, you will see the matrix is transposed. The shape is (h,w) and thus flatten(default=row-wise) will be column-wise for (w,h) and so, comply with the competition rules.
\n\nBut I am still confused, something is weird :))
", "rawMarkdown": "A few days ago I came across the same issue when I saw the rules, because I thought \"hey its not good to use column-wise computation, since we have more mask pixels row-wise.\" Than I started to check the rle/flatten calls as well:\n\nIf you look at the shape after ndimage.imread and PIL.open, you will see the matrix is transposed. The shape is (h,w) and thus flatten(default=row-wise) will be column-wise for (w,h) and so, comply with the competition rules.\n\nBut I am still confused, something is weird :))", "votes": null }, { "id": "208888", "postDate": "07/31/2017 14:05:14", "content": "Ah, indeed, I've missed this part of the kernel.\nAccording to the docs of scipy.ndimage.imread - When flatten is True, the image is converted using mode ‘F’.. So it is column-wise after all...
Agreed, I've been using this kernel and got good results, not to mention it actually verifies the train masks. I think the wording should be \"The pixels are numbered from left to right, then top to bottom: 1 is pixel (1,1), 2 is pixel (1,2), etc.\"
", "votes": null, "replies": [] }, { "id": 208882, "author_name": "firolino", "author_url": "", "post_date": "07/31/2017 13:44:40", "content": "A few days ago I came across the same issue when I saw the rules, because I thought \"hey its not good to use column-wise computation, since we have more mask pixels row-wise.\" Than I started to check the rle/flatten calls as well:
\n\nIf you look at the shape after ndimage.imread and PIL.open, you will see the matrix is transposed. The shape is (h,w) and thus flatten(default=row-wise) will be column-wise for (w,h) and so, comply with the competition rules.
\n\nBut I am still confused, something is weird :))
", "votes": null, "replies": [ { "id": 208888, "author_name": "panfilov", "author_url": "", "post_date": "07/31/2017 14:05:14", "content": "Ah, indeed, I've missed this part of the kernel.\nAccording to the docs of scipy.ndimage.imread - When flatten is True, the image is converted using mode ‘F’.. So it is column-wise after all...