render-parameters off by 1 for 1024 png images

[fcollman]

render seems to be confused about some 1024 tiles we have loaded here

for example...

this call
http://em-131fs:8999/render-ws/v1/owner/gayathri/project/EM_Phase1/stack/Pinky40_20170313_aibsdata_flipped/tile/1,3484_aligned_0_1/render-parameters

returns

{
"meshCellSize" : 64.0,
"minMeshCellSize" : 0.0,
"x" : 1896.0,
"y" : 876.0,
"width" : 1023,
"height" : 1023,
"scale" : 1.0,
"areaOffset" : false,
"convertToGray" : false,
"quality" : 0.85,
"numberOfThreads" : 1,
"skipInterpolation" : false,
"binaryMask" : false,
"excludeMask" : false,
"doFilter" : false,
"tileSpecs" : [ {
"tileId" : "1,3484_aligned_0_1",
"layout" : {
"sectionId" : "None",
"temca" : "None",
"camera" : "None"
},
"z" : 3484.0,
"minX" : 1896.0,
"minY" : 876.0,
"maxX" : 2919.0,
"maxY" : 1899.0,
"width" : 1024.0,
"height" : 1024.0,
"minIntensity" : 0.0,
"maxIntensity" : 255.0,
"mipmapLevels" : {
"0" : {
"imageUrl" : "file:///data/nc-em/russelt/20170227_Princeton_Pinky40/4_aligned_tiled/1,3484_aligned_0_1_flip.png"
}
},
"transforms" : {
"type" : "list",
"specList" : [ {
"type" : "leaf",
"className" : "mpicbg.trakem2.transform.AffineModel2D",
"dataString" : "1.0000000000 0.0000000000 0.0000000000 1.0000000000 1896.0000000000 -876.0000000000"
}, {
"type" : "leaf",
"className" : "mpicbg.trakem2.transform.AffineModel2D",
"dataString" : "1.0000000000 0.0000000000 0.0000000000 1.0000000000 0.0000000000 1752.0000000000"
} ]
},
"meshCellSize" : 64.0
} ],
"minBoundsMeshCellSize" : 64.0
}

as you can see the image is 1024x1024 (and the png file is that)
but the render-parameters have it as 1023x1023, and bounding_box sytle renderings often have black pixel lines as the tile doesn't quite fill the space it should.

ideas?

[trautmane]

Sadly, it took over 2 years for me to realize that I misunderstood this issue. My original fix was a hack that just hid the real problem which is with the tile spec bounding box derivation code. Ironically, the "sloppy" derivation introduced by Saalfeld in ec46251 corrects this specific case but sloppy=false derivation still exposes the original problem. I have rolled back my original hack and have reopened this issue.

[miketaormina]

I'm not sure if this is related or not, but I have 2048x2048 image tiles that come back as 2049x2049 when I request the tile image data (I guess the opposite behavior as Forrest notes above).
In this case, the Render Parameters call shows the correct dimensions, but returned data does not match:

http://10.128.50.158:8080/render-ws/v1/owner/optical_coordinates/project/495710_08/stack/Moxd1_5_01/tile/495710.08.1.0.5.400/render-parameters

{
  "meshCellSize": 64,
  "minMeshCellSize": 0,
  "x": -810,
  "y": 0,
  "width": 2049,
  "height": 2049,
  "scale": 1,
  "areaOffset": false,
  "convertToGray": false,
  "quality": 0.85,
  "numberOfThreads": 1,
  "skipInterpolation": false,
  "binaryMask": false,
  "excludeMask": false,
  "doFilter": false,
  "addWarpFieldDebugOverlay": false,
  "fillWithNoise": false,
  "tileSpecs": [
    {
      "tileId": "495710.08.1.0.5.400",
      "layout": {
        "sectionId": "0400",
        "imageRow": 0,
        "imageCol": 0,
        "stageX": 10593.02,
        "stageY": 47465.79
      },
      "z": 400,
      "minX": -810,
      "minY": 0,
      "maxX": 1238,
      "maxY": 2048,
      "width": 2048,
      "height": 2048,
      "mipmapLevels": {
        "0": {
          "imageUrl": "/integration_test/camera_coord_tiles/WP.000021.R1/495710.08.R1/Camera-1-640/495710_08_1_0_5_400.tif"
        }
      },
      "transforms": {
        "type": "list",
        "specList": [
          {
            "type": "leaf",
            "className": "mpicbg.trakem2.transform.AffineModel2D",
            "dataString": "1.0000000000 0.0000000000 0.0000000000 1.0000000000 -810.0000000000 -0.0000000000"
          }
        ]
      },
      "meshCellSize": 64
    }
  ],
  "minBoundsMeshCellSize": 64
}

Edit: now that I see it here, I notice that the width and height are indeed inconsistent with the tileSpec data. I also should note that this behavior is not confined to PNG images.

[trautmane]

Hi Mike - yes you found the same thing I did last November. On the geometric_descriptor branch (where we've been doing most of our work recently), I removed my original hack in 6aee2f7 and then re-opened this issue with the hope that at some point I could investigate further and properly fix the sloppy=false bounding box derivation code. Is this bug causing trouble for you or is it just something you noticed? If the bug is a problem, I'll try to solve it for you sooner.
--Eric

[miketaormina]

I noticed it quite a while ago, but haven't generally used tile images until recently (previously mainly used bb_image). It isn't causing me trouble, as I've just been either ignoring it or truncating the image. I finally went to put it here just so that someone would know about it, and then found this issue.

Also, I'm not sure if this is also related:
I can't seem to recall the specifics, but it seemed like there was also an inconsistency with how z is treated in the stack bounds. If I recall, maxZ - minZ does not equal sectionCount, but maxX - minX does equal the total extent of the stack in x. I've never really figured out if it's weird or not, since the 0 indexing does make sense and there's no equivalent to sectionCount for x.

Again, neither of these is hangin me up, so no worries. I'm just really glad to have the Render package as a resource and will try to help as my skill set allows.

[trautmane]

Thanks Mike - the sectionCount in the stack metadata is the number of distinct sectionId values across all tiles in the stack. For "simple" stacks where there is a one-to-one correspondence between sectionId and z and you have a contiguous set of layers, the sectionCount happens to be equal to maxZ - minZ + 1 (but that's not how it is calculated). We have data sets where the same layers have been acquired at different times - typically re-imaging of problem areas. The re-acquired data is assigned a different sectionId from the original data, but ultimately gets assigned the same z. In these cases, the sectionCount is much higher than the z range. We also have data sets with non-contiguous layers / z values where the sectionCount is less than the z range.