{
  "id": 26903,
  "title": "Image missalignment",
  "url": "/competitions/dstl-satellite-imagery-feature-detection/discussion/26903",
  "author_name": "",
  "post_date": "2016-12-24T20:12:40.950Z",
  "votes": 2,
  "comment_count": 14,
  "views": 916,
  "content": "<p>Hi!</p>\n\n<p>I was playing a bit with images and I realized that for 6120_2_2 there is a misalignment between 3, A M and P images. The biggest shift is between 3 and A images (upon resizing, of course). </p>\n\n<p>Has anybody noticed this? </p>",
  "messages": [
    {
      "id": "152291",
      "postDate": "12/24/2016 20:12:40",
      "content": "<p>Hi!</p>\n\n<p>I was playing a bit with images and I realized that for 6120_2_2 there is a misalignment between 3, A M and P images. The biggest shift is between 3 and A images (upon resizing, of course). </p>\n\n<p>Has anybody noticed this? </p>",
      "rawMarkdown": "Hi!\r\n\r\nI was playing a bit with images and I realized that for 6120_2_2 there is a misalignment between 3, A M and P images. The biggest shift is between 3 and A images (upon resizing, of course). \r\n\r\nHas anybody noticed this?",
      "votes": null
    },
    {
      "id": "152610",
      "postDate": "12/27/2016 13:32:54",
      "content": "<p>I find it hard to tell. But date is 2016-04-19 for \"3\" while 2016-03-30 for A, M and P.</p>",
      "rawMarkdown": "I find it hard to tell. But date is 2016-04-19 for \"3\" while 2016-03-30 for A, M and P.",
      "votes": null
    },
    {
      "id": "152620",
      "postDate": "12/27/2016 14:57:22",
      "content": "<p>visoft, can you post a photo of the misalignment? Also, Glimmung, where did you get those dates? I don't see any date info in the image metadata using gdalinfo. </p>",
      "rawMarkdown": "visoft, can you post a photo of the misalignment? Also, Glimmung, where did you get those dates? I don't see any date info in the image metadata using gdalinfo.",
      "votes": null
    },
    {
      "id": "152636",
      "postDate": "12/27/2016 16:46:39",
      "content": "<p>I used GetField(TiffTag.DATETIME) in BitMiracle.LibTiff.Classic</p>",
      "rawMarkdown": "I used GetField(TiffTag.DATETIME) in BitMiracle.LibTiff.Classic",
      "votes": null
    },
    {
      "id": "152896",
      "postDate": "12/29/2016 00:58:48",
      "content": "<p>I've also bumped into a misalignment with 6040_1_0, 6040_1_3 and also  6120_2_2.</p>\n\n<p>It's a misalignment between the train data and the M band raster.</p>\n\n<p>The error from 6040_1_3 reads...</p>\n\n<p>MaskError: Mask and data not compatible: data size is 709776, mask size is 708939.</p>",
      "rawMarkdown": "I've also bumped into a misalignment with 6040_1_0, 6040_1_3 and also  6120_2_2.\r\n\r\nIt's a misalignment between the train data and the M band raster.\r\n\r\nThe error from 6040_1_3 reads...\r\n\r\nMaskError: Mask and data not compatible: data size is 709776, mask size is 708939.",
      "votes": null
    },
    {
      "id": "153239",
      "postDate": "12/30/2016 15:11:16",
      "content": "<p>Image: 6120_2_2</p>\n\n<p>I resized all rasters to 3 band sizes and overlapped some bands from _3, _a and _p to create a RGB false color composite.</p>\n\n<p>The images speak for themselves :)</p>\n\n<p>(look at the trees, and the lake or whatever it is on the SE region)</p>\n\n<p>The differences between _3 and _a are ~1.5-2 pixels (in _a size) that translates to 20-50 pixels in _3 sizes. </p>\n\n<p>Between _3 and _m there is also a difference but only several pixels in _3 resolution so I ignored it.</p>\n\n<p><strong>Update:</strong></p>\n\n<p>My code to do the registration:</p>\n\n<p><a href=\"https://www.kaggle.com/visoft/dstl-satellite-imagery-feature-detection/correct-image-missalignment/\">https://www.kaggle.com/visoft/dstl-satellite-imagery-feature-detection/correct-image-missalignment/</a></p>",
      "rawMarkdown": "Image: 6120_2_2\r\n\r\nI resized all rasters to 3 band sizes and overlapped some bands from _3, _a and _p to create a RGB false color composite.\r\n\r\nThe images speak for themselves :)\r\n\r\n(look at the trees, and the lake or whatever it is on the SE region)\r\n\r\nThe differences between _3 and _a are ~1.5-2 pixels (in _a size) that translates to 20-50 pixels in _3 sizes. \r\n\r\nBetween _3 and _m there is also a difference but only several pixels in _3 resolution so I ignored it.\r\n\r\n**Update:**\r\n\r\nMy code to do the registration:\r\n\r\nhttps://www.kaggle.com/visoft/dstl-satellite-imagery-feature-detection/correct-image-missalignment/",
      "votes": null
    },
    {
      "id": "153255",
      "postDate": "12/30/2016 16:28:02",
      "content": "<p>looks like some of the images are missing data. Here is a screenshot of 6150_2_3  RGB and A images (same as _3 and _a) in greyscale with Class 5 overlayed on both. The transformation for the polygons was done the same on both, but it's way off for the A image. There is definitely some missing columns on the left edge of A as well.   visoft it looks like you corrected for this in 6120_2_2 by padding the missing pixels. </p>\n\n<p>I did a quick run thru of the training A images, and the severity of this varies among all of them. The RGB True color was correct in all of them. But the A and M images have different degrees of missing columns and rows, causing the polygons to be offset by different amounts. This is pretty annoying. </p>",
      "rawMarkdown": "looks like some of the images are missing data. Here is a screenshot of 6150_2_3  RGB and A images (same as _3 and _a) in greyscale with Class 5 overlayed on both. The transformation for the polygons was done the same on both, but it's way off for the A image. There is definitely some missing columns on the left edge of A as well.   visoft it looks like you corrected for this in 6120_2_2 by padding the missing pixels. \r\n\r\nI did a quick run thru of the training A images, and the severity of this varies among all of them. The RGB True color was correct in all of them. But the A and M images have different degrees of missing columns and rows, causing the polygons to be offset by different amounts. This is pretty annoying.",
      "votes": null
    },
    {
      "id": "153293",
      "postDate": "12/30/2016 21:35:41",
      "content": "<p>That's a big missalignment shawn. I was expecting that the W^2/(W-1) formula will \"work\" for all types of images, at least at their native resolution. </p>\n\n<p>My code \"pastes\" the registered image over the original one. It helps with visualizations. If the empty space is left wih 0s as it should be, the final dynamic range would be too high. </p>\n\n<p>The direction and size of displacement varies for each scene. I procesed only the training data, I hope that the method is stable enough for the rest of 400 scenes.</p>\n\n<p>At the moment I have some decent success with U shaped DenseNets, with forward shortcircuit between dense blocks, but in another project (segmentation). So everything I do here is with deep learning in mind.</p>\n\n<p>Such big shift between bands toughens a lot the problem. One could waste half of the architecture learning how to align the data. Also, using full convnets, we can use patches of images as input and x-class masks as output. In my current project, such an u shaped net fits nicely in 4G gpu. </p>",
      "rawMarkdown": "That's a big missalignment shawn. I was expecting that the W^2/(W-1) formula will \"work\" for all types of images, at least at their native resolution. \r\n\r\nMy code \"pastes\" the registered image over the original one. It helps with visualizations. If the empty space is left wih 0s as it should be, the final dynamic range would be too high. \r\n\r\nThe direction and size of displacement varies for each scene. I procesed only the training data, I hope that the method is stable enough for the rest of 400 scenes.\r\n\r\nAt the moment I have some decent success with U shaped DenseNets, with forward shortcircuit between dense blocks, but in another project (segmentation). So everything I do here is with deep learning in mind.\r\n\r\nSuch big shift between bands toughens a lot the problem. One could waste half of the architecture learning how to align the data. Also, using full convnets, we can use patches of images as input and x-class masks as output. In my current project, such an u shaped net fits nicely in 4G gpu.",
      "votes": null
    },
    {
      "id": "153358",
      "postDate": "12/31/2016 13:25:09",
      "content": "<p>The missalignment on 6150_2_3 yields an AJI drop from 0.167 using only M to 0.144 using M &amp; A for class type 4 (track), so I reckon it is problematic. I will implement an image fit to see if it gets better...</p>",
      "rawMarkdown": "The missalignment on 6150_2_3 yields an AJI drop from 0.167 using only M to 0.144 using M & A for class type 4 (track), so I reckon it is problematic. I will implement an image fit to see if it gets better...",
      "votes": null
    },
    {
      "id": "153396",
      "postDate": "12/31/2016 21:10:07",
      "content": "<p>similar issues here - used 6070_2_3:</p>\n\n<p>After re-projecting 6070_2_3_M (original x: 835 y:838) to the same dimensions as 6070_2_3_P (x:3338 y:3349) with GDAL_Warp there is a misalignment visible (see attached png: 6070_2_3_M-re-projected 50% transparency over 6070_2_3_P). With this overlay for the selected images it look to be off by about 2-3m only (on a 0.31m scale this is quite a bit), but I believe we might have a more general issue here. </p>\n\n<p>Given the (understandable) missing of Geo-coordinates to correct this automatically we must rely on having each of the image sets being aligned very precisely.</p>\n\n<p>I will try one more idea to address this (use the same dimensions for all diagrams e.g. 3403x3403) but in the moment this looks like quite an issue with this competition and it seems that I'm not the only one struggling with the images.  </p>\n\n<p>[update] issue solved see comments below</p>",
      "rawMarkdown": "similar issues here - used 6070_2_3:\r\n\r\nAfter re-projecting 6070_2_3_M (original x: 835 y:838) to the same dimensions as 6070_2_3_P (x:3338 y:3349) with GDAL_Warp there is a misalignment visible (see attached png: 6070_2_3_M-re-projected 50% transparency over 6070_2_3_P). With this overlay for the selected images it look to be off by about 2-3m only (on a 0.31m scale this is quite a bit), but I believe we might have a more general issue here. \r\n\r\nGiven the (understandable) missing of Geo-coordinates to correct this automatically we must rely on having each of the image sets being aligned very precisely.\r\n\r\nI will try one more idea to address this (use the same dimensions for all diagrams e.g. 3403x3403) but in the moment this looks like quite an issue with this competition and it seems that I'm not the only one struggling with the images.  \r\n\r\n[update] issue solved see comments below",
      "votes": null
    },
    {
      "id": "153467",
      "postDate": "01/01/2017 17:39:32",
      "content": "<p>Hm, maybe I should register M images too.</p>\n\n<p>It takes a bit of time but once they are registered you can save them. It shouldn't take more than a night to process all images.</p>",
      "rawMarkdown": "Hm, maybe I should register M images too.\r\n\r\nIt takes a bit of time but once they are registered you can save them. It shouldn't take more than a night to process all images.",
      "votes": null
    },
    {
      "id": "153523",
      "postDate": "01/02/2017 01:17:11",
      "content": "<p>@visoft - I'm quite keen to try some approaches with the infrared data in the M images.\nStruggling in getting them aligned.</p>\n\n<p>My starting point are the 3Bands as I understand the Xmax / Ymin in the grid_sizes file do refer to these.</p>\n\n<p>Problem starts with the xxx_P images (at least the ones I've tried) also don't align - maybe my approach is wrong - using gdalwrap and scale them to the dimensions of the corresponding 3Band image.\ne.g. 6070_2_3 (3band is 3338x3350, P is 3338x3349, A is 134x134, M is 835 x 838).</p>\n\n<p>Might need to use some sort of transformation / projection - as by the data description each of them should be 1000m x 1000m.</p>\n\n<p>Any ideas?  </p>",
      "rawMarkdown": "visoft - I'm quite keen to try some approaches with the infrared data in the M images.\r\nStruggling in getting them aligned.\r\n\r\nMy starting point are the 3Bands as I understand the Xmax / Ymin in the grid_sizes file do refer to these.\r\n\r\nProblem starts with the xxx_P images (at least the ones I've tried) also don't align - maybe my approach is wrong - using gdalwrap and scale them to the dimensions of the corresponding 3Band image.\r\ne.g. 6070_2_3 (3band is 3338x3350, P is 3338x3349, A is 134x134, M is 835 x 838).\r\n\r\nMight need to use some sort of transformation / projection - as by the data description each of them should be 1000m x 1000m.\r\n\r\nAny ideas?",
      "votes": null
    },
    {
      "id": "153560",
      "postDate": "01/02/2017 08:55:43",
      "content": "<p>Hi @FPP_UK! If you are on python, see my kernel for registration:</p>\n\n<p><a href=\"https://www.kaggle.com/visoft/dstl-satellite-imagery-feature-detection/correct-image-missalignment-v2/code\">https://www.kaggle.com/visoft/dstl-satellite-imagery-feature-detection/correct-image-missalignment-v2/code</a></p>\n\n<p>You need OpenCV but anaconda ships ver3.1 now.</p>\n\n<p>It is a full working kernel, just copy-paste from my code. Write there comments if you have troubles.</p>",
      "rawMarkdown": "Hi @FPP_UK! If you are on python, see my kernel for registration:\r\n\r\nhttps://www.kaggle.com/visoft/dstl-satellite-imagery-feature-detection/correct-image-missalignment-v2/code\r\n\r\nYou need OpenCV but anaconda ships ver3.1 now.\r\n\r\nIt is a full working kernel, just copy-paste from my code. Write there comments if you have troubles.",
      "votes": null
    },
    {
      "id": "153675",
      "postDate": "01/02/2017 18:29:57",
      "content": "<p>@visoft:</p>\n\n<p>attached first clean-up run of the images - now these seemed to be aligned - great, many thanks\n(the 3-6-7 bands image obviously has seen one more processing step after the alignment)</p>",
      "rawMarkdown": "visoft:\r\n\r\nattached first clean-up run of the images - now these seemed to be aligned - great, many thanks\r\n(the 3-6-7 bands image obviously has seen one more processing step after the alignment)",
      "votes": null
    },
    {
      "id": "158310",
      "postDate": "01/26/2017 19:40:43",
      "content": "<p>Just coming to this now - do you guys have any guidelines for the cc value? Is there a threshold above which we wouldn't bother with alignment? Or is that not really important?</p>",
      "rawMarkdown": "Just coming to this now - do you guys have any guidelines for the cc value? Is there a threshold above which we wouldn't bother with alignment? Or is that not really important?",
      "votes": null
    }
  ],
  "comments": [
    {
      "id": 152610,
      "author_name": "glimmung",
      "author_url": "",
      "post_date": "12/27/2016 13:32:54",
      "content": "<p>I find it hard to tell. But date is 2016-04-19 for \"3\" while 2016-03-30 for A, M and P.</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 152620,
      "author_name": "shawn775",
      "author_url": "",
      "post_date": "12/27/2016 14:57:22",
      "content": "<p>visoft, can you post a photo of the misalignment? Also, Glimmung, where did you get those dates? I don't see any date info in the image metadata using gdalinfo. </p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 152636,
      "author_name": "glimmung",
      "author_url": "",
      "post_date": "12/27/2016 16:46:39",
      "content": "<p>I used GetField(TiffTag.DATETIME) in BitMiracle.LibTiff.Classic</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 152896,
      "author_name": "playerpiano",
      "author_url": "",
      "post_date": "12/29/2016 00:58:48",
      "content": "<p>I've also bumped into a misalignment with 6040_1_0, 6040_1_3 and also  6120_2_2.</p>\n\n<p>It's a misalignment between the train data and the M band raster.</p>\n\n<p>The error from 6040_1_3 reads...</p>\n\n<p>MaskError: Mask and data not compatible: data size is 709776, mask size is 708939.</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 153239,
      "author_name": "visoft",
      "author_url": "",
      "post_date": "12/30/2016 15:11:16",
      "content": "<p>Image: 6120_2_2</p>\n\n<p>I resized all rasters to 3 band sizes and overlapped some bands from _3, _a and _p to create a RGB false color composite.</p>\n\n<p>The images speak for themselves :)</p>\n\n<p>(look at the trees, and the lake or whatever it is on the SE region)</p>\n\n<p>The differences between _3 and _a are ~1.5-2 pixels (in _a size) that translates to 20-50 pixels in _3 sizes. </p>\n\n<p>Between _3 and _m there is also a difference but only several pixels in _3 resolution so I ignored it.</p>\n\n<p><strong>Update:</strong></p>\n\n<p>My code to do the registration:</p>\n\n<p><a href=\"https://www.kaggle.com/visoft/dstl-satellite-imagery-feature-detection/correct-image-missalignment/\">https://www.kaggle.com/visoft/dstl-satellite-imagery-feature-detection/correct-image-missalignment/</a></p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 153255,
      "author_name": "shawn775",
      "author_url": "",
      "post_date": "12/30/2016 16:28:02",
      "content": "<p>looks like some of the images are missing data. Here is a screenshot of 6150_2_3  RGB and A images (same as _3 and _a) in greyscale with Class 5 overlayed on both. The transformation for the polygons was done the same on both, but it's way off for the A image. There is definitely some missing columns on the left edge of A as well.   visoft it looks like you corrected for this in 6120_2_2 by padding the missing pixels. </p>\n\n<p>I did a quick run thru of the training A images, and the severity of this varies among all of them. The RGB True color was correct in all of them. But the A and M images have different degrees of missing columns and rows, causing the polygons to be offset by different amounts. This is pretty annoying. </p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 153293,
      "author_name": "visoft",
      "author_url": "",
      "post_date": "12/30/2016 21:35:41",
      "content": "<p>That's a big missalignment shawn. I was expecting that the W^2/(W-1) formula will \"work\" for all types of images, at least at their native resolution. </p>\n\n<p>My code \"pastes\" the registered image over the original one. It helps with visualizations. If the empty space is left wih 0s as it should be, the final dynamic range would be too high. </p>\n\n<p>The direction and size of displacement varies for each scene. I procesed only the training data, I hope that the method is stable enough for the rest of 400 scenes.</p>\n\n<p>At the moment I have some decent success with U shaped DenseNets, with forward shortcircuit between dense blocks, but in another project (segmentation). So everything I do here is with deep learning in mind.</p>\n\n<p>Such big shift between bands toughens a lot the problem. One could waste half of the architecture learning how to align the data. Also, using full convnets, we can use patches of images as input and x-class masks as output. In my current project, such an u shaped net fits nicely in 4G gpu. </p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 153358,
      "author_name": "glimmung",
      "author_url": "",
      "post_date": "12/31/2016 13:25:09",
      "content": "<p>The missalignment on 6150_2_3 yields an AJI drop from 0.167 using only M to 0.144 using M &amp; A for class type 4 (track), so I reckon it is problematic. I will implement an image fit to see if it gets better...</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 153396,
      "author_name": "fppkaggle",
      "author_url": "",
      "post_date": "12/31/2016 21:10:07",
      "content": "<p>similar issues here - used 6070_2_3:</p>\n\n<p>After re-projecting 6070_2_3_M (original x: 835 y:838) to the same dimensions as 6070_2_3_P (x:3338 y:3349) with GDAL_Warp there is a misalignment visible (see attached png: 6070_2_3_M-re-projected 50% transparency over 6070_2_3_P). With this overlay for the selected images it look to be off by about 2-3m only (on a 0.31m scale this is quite a bit), but I believe we might have a more general issue here. </p>\n\n<p>Given the (understandable) missing of Geo-coordinates to correct this automatically we must rely on having each of the image sets being aligned very precisely.</p>\n\n<p>I will try one more idea to address this (use the same dimensions for all diagrams e.g. 3403x3403) but in the moment this looks like quite an issue with this competition and it seems that I'm not the only one struggling with the images.  </p>\n\n<p>[update] issue solved see comments below</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 153467,
      "author_name": "visoft",
      "author_url": "",
      "post_date": "01/01/2017 17:39:32",
      "content": "<p>Hm, maybe I should register M images too.</p>\n\n<p>It takes a bit of time but once they are registered you can save them. It shouldn't take more than a night to process all images.</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 153523,
      "author_name": "fppkaggle",
      "author_url": "",
      "post_date": "01/02/2017 01:17:11",
      "content": "<p>@visoft - I'm quite keen to try some approaches with the infrared data in the M images.\nStruggling in getting them aligned.</p>\n\n<p>My starting point are the 3Bands as I understand the Xmax / Ymin in the grid_sizes file do refer to these.</p>\n\n<p>Problem starts with the xxx_P images (at least the ones I've tried) also don't align - maybe my approach is wrong - using gdalwrap and scale them to the dimensions of the corresponding 3Band image.\ne.g. 6070_2_3 (3band is 3338x3350, P is 3338x3349, A is 134x134, M is 835 x 838).</p>\n\n<p>Might need to use some sort of transformation / projection - as by the data description each of them should be 1000m x 1000m.</p>\n\n<p>Any ideas?  </p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 153560,
      "author_name": "visoft",
      "author_url": "",
      "post_date": "01/02/2017 08:55:43",
      "content": "<p>Hi @FPP_UK! If you are on python, see my kernel for registration:</p>\n\n<p><a href=\"https://www.kaggle.com/visoft/dstl-satellite-imagery-feature-detection/correct-image-missalignment-v2/code\">https://www.kaggle.com/visoft/dstl-satellite-imagery-feature-detection/correct-image-missalignment-v2/code</a></p>\n\n<p>You need OpenCV but anaconda ships ver3.1 now.</p>\n\n<p>It is a full working kernel, just copy-paste from my code. Write there comments if you have troubles.</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 153675,
      "author_name": "fppkaggle",
      "author_url": "",
      "post_date": "01/02/2017 18:29:57",
      "content": "<p>@visoft:</p>\n\n<p>attached first clean-up run of the images - now these seemed to be aligned - great, many thanks\n(the 3-6-7 bands image obviously has seen one more processing step after the alignment)</p>",
      "votes": null,
      "replies": []
    },
    {
      "id": 158310,
      "author_name": "grantbey",
      "author_url": "",
      "post_date": "01/26/2017 19:40:43",
      "content": "<p>Just coming to this now - do you guys have any guidelines for the cc value? Is there a threshold above which we wouldn't bother with alignment? Or is that not really important?</p>",
      "votes": null,
      "replies": []
    }
  ],
  "raw_markdown_by_id": {
    "152291": "Hi!\r\n\r\nI was playing a bit with images and I realized that for 6120_2_2 there is a misalignment between 3, A M and P images. The biggest shift is between 3 and A images (upon resizing, of course). \r\n\r\nHas anybody noticed this?",
    "152610": "I find it hard to tell. But date is 2016-04-19 for \"3\" while 2016-03-30 for A, M and P.",
    "152620": "visoft, can you post a photo of the misalignment? Also, Glimmung, where did you get those dates? I don't see any date info in the image metadata using gdalinfo.",
    "152636": "I used GetField(TiffTag.DATETIME) in BitMiracle.LibTiff.Classic",
    "152896": "I've also bumped into a misalignment with 6040_1_0, 6040_1_3 and also  6120_2_2.\r\n\r\nIt's a misalignment between the train data and the M band raster.\r\n\r\nThe error from 6040_1_3 reads...\r\n\r\nMaskError: Mask and data not compatible: data size is 709776, mask size is 708939.",
    "153239": "Image: 6120_2_2\r\n\r\nI resized all rasters to 3 band sizes and overlapped some bands from _3, _a and _p to create a RGB false color composite.\r\n\r\nThe images speak for themselves :)\r\n\r\n(look at the trees, and the lake or whatever it is on the SE region)\r\n\r\nThe differences between _3 and _a are ~1.5-2 pixels (in _a size) that translates to 20-50 pixels in _3 sizes. \r\n\r\nBetween _3 and _m there is also a difference but only several pixels in _3 resolution so I ignored it.\r\n\r\n**Update:**\r\n\r\nMy code to do the registration:\r\n\r\nhttps://www.kaggle.com/visoft/dstl-satellite-imagery-feature-detection/correct-image-missalignment/",
    "153255": "looks like some of the images are missing data. Here is a screenshot of 6150_2_3  RGB and A images (same as _3 and _a) in greyscale with Class 5 overlayed on both. The transformation for the polygons was done the same on both, but it's way off for the A image. There is definitely some missing columns on the left edge of A as well.   visoft it looks like you corrected for this in 6120_2_2 by padding the missing pixels. \r\n\r\nI did a quick run thru of the training A images, and the severity of this varies among all of them. The RGB True color was correct in all of them. But the A and M images have different degrees of missing columns and rows, causing the polygons to be offset by different amounts. This is pretty annoying.",
    "153293": "That's a big missalignment shawn. I was expecting that the W^2/(W-1) formula will \"work\" for all types of images, at least at their native resolution. \r\n\r\nMy code \"pastes\" the registered image over the original one. It helps with visualizations. If the empty space is left wih 0s as it should be, the final dynamic range would be too high. \r\n\r\nThe direction and size of displacement varies for each scene. I procesed only the training data, I hope that the method is stable enough for the rest of 400 scenes.\r\n\r\nAt the moment I have some decent success with U shaped DenseNets, with forward shortcircuit between dense blocks, but in another project (segmentation). So everything I do here is with deep learning in mind.\r\n\r\nSuch big shift between bands toughens a lot the problem. One could waste half of the architecture learning how to align the data. Also, using full convnets, we can use patches of images as input and x-class masks as output. In my current project, such an u shaped net fits nicely in 4G gpu.",
    "153358": "The missalignment on 6150_2_3 yields an AJI drop from 0.167 using only M to 0.144 using M & A for class type 4 (track), so I reckon it is problematic. I will implement an image fit to see if it gets better...",
    "153396": "similar issues here - used 6070_2_3:\r\n\r\nAfter re-projecting 6070_2_3_M (original x: 835 y:838) to the same dimensions as 6070_2_3_P (x:3338 y:3349) with GDAL_Warp there is a misalignment visible (see attached png: 6070_2_3_M-re-projected 50% transparency over 6070_2_3_P). With this overlay for the selected images it look to be off by about 2-3m only (on a 0.31m scale this is quite a bit), but I believe we might have a more general issue here. \r\n\r\nGiven the (understandable) missing of Geo-coordinates to correct this automatically we must rely on having each of the image sets being aligned very precisely.\r\n\r\nI will try one more idea to address this (use the same dimensions for all diagrams e.g. 3403x3403) but in the moment this looks like quite an issue with this competition and it seems that I'm not the only one struggling with the images.  \r\n\r\n[update] issue solved see comments below",
    "153467": "Hm, maybe I should register M images too.\r\n\r\nIt takes a bit of time but once they are registered you can save them. It shouldn't take more than a night to process all images.",
    "153523": "visoft - I'm quite keen to try some approaches with the infrared data in the M images.\r\nStruggling in getting them aligned.\r\n\r\nMy starting point are the 3Bands as I understand the Xmax / Ymin in the grid_sizes file do refer to these.\r\n\r\nProblem starts with the xxx_P images (at least the ones I've tried) also don't align - maybe my approach is wrong - using gdalwrap and scale them to the dimensions of the corresponding 3Band image.\r\ne.g. 6070_2_3 (3band is 3338x3350, P is 3338x3349, A is 134x134, M is 835 x 838).\r\n\r\nMight need to use some sort of transformation / projection - as by the data description each of them should be 1000m x 1000m.\r\n\r\nAny ideas?",
    "153560": "Hi @FPP_UK! If you are on python, see my kernel for registration:\r\n\r\nhttps://www.kaggle.com/visoft/dstl-satellite-imagery-feature-detection/correct-image-missalignment-v2/code\r\n\r\nYou need OpenCV but anaconda ships ver3.1 now.\r\n\r\nIt is a full working kernel, just copy-paste from my code. Write there comments if you have troubles.",
    "153675": "visoft:\r\n\r\nattached first clean-up run of the images - now these seemed to be aligned - great, many thanks\r\n(the 3-6-7 bands image obviously has seen one more processing step after the alignment)",
    "158310": "Just coming to this now - do you guys have any guidelines for the cc value? Is there a threshold above which we wouldn't bother with alignment? Or is that not really important?"
  },
  "source": "meta"
}