# Is image.GetOffsetTable()\[0\] always equal to 1?

**URL:** <https://discourse.itk.org/t/is-image-getoffsettable-0-always-equal-to-1/893>\
**Category:** Engineering\
**Created:** [May 2, 2018, 12:40pm UTC](https://discourse.itk.org/t/is-image-getoffsettable-0-always-equal-to-1/893 "2018-05-02T12:40:48Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Niels\_Dekker](https://discourse.itk.org/letter_avatar_proxy/v4/letter/n/9d8465/32.png) [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)\
**Post date:** [May 2, 2018, 12:40pm UTC](https://discourse.itk.org/t/is-image-getoffsettable-0-always-equal-to-1/893/1 "2018-05-02T12:40:48Z")

</div>

[itkShapedImageNeighborhoodRange.h](https://github.com/Kitware/ITK/blob/05f6c9fbd7e09fc26603c02fc7fd5cbcb2b47f4f/Modules/Core/Common/include/itkShapedImageNeighborhoodRange.h#L535) has the following assert:

```
const OffsetValueType* const offsetTable = image.GetOffsetTable();
assert((offsetTable != nullptr) && (offsetTable[0] == 1));

```

Is it safe to assume that the first value of the _offset table_ of an image is always exactly 1? I mean, is the `assert` correct, for any image type?

---

<div class="post-metadata">

**Author:** ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)\
**Post date:** [May 2, 2018, 12:59pm UTC](https://discourse.itk.org/t/is-image-getoffsettable-0-always-equal-to-1/893/2 "2018-05-02T12:59:05Z")

</div>

Not using it is a violation of the data model that ITK has. This abstraction can enable different data layouts for the image buffer. Consider the definition of the[PyBuffer](https://docs.python.org/3/c-api/buffer.html) with its shape, strides and offsets. ITK has a similar defined abstract interface. Supporting this model in ITK proper code is an example of the distinction of what is expected in ITK proper code vs remove modules/review code.

However, recently many of the ITK defined models and interfaces are being thrown out the window, it may be that there is no longer an inclination to support the traditional ITK data models, and heavy weight abstractions.

Practically, the assumptions that `offsetTable[0] == 1` is correct. This really should not be a debug only assert, but should always generate an itk exception if this assumption is violated.

---

<div class="post-metadata">

**Author:** ![Niels\_Dekker](https://discourse.itk.org/letter_avatar_proxy/v4/letter/n/9d8465/32.png) [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)\
**Post date:** [May 2, 2018, 1:28pm UTC](https://discourse.itk.org/t/is-image-getoffsettable-0-always-equal-to-1/893/3 "2018-05-02T13:28:10Z")

</div>

Thanks, Brad! _ShapedImageNeighborhoodRange_ could certainly be adjusted to fully support `offsetTable[0] >= 2`. But that would somewhat reduce its performance. 😯 So I wonder if it’s worth it for now, given that such image types aren’t being used in practice…

Here is where [itkShapedImageNeighborhoodRange.h](https://github.com/Kitware/ITK/blob/05f6c9fbd7e09fc26603c02fc7fd5cbcb2b47f4f/Modules/Core/Common/include/itkShapedImageNeighborhoodRange.h#L387) deliberately skips multiplication by `offsetTable[0]` (at the 4th line of code):

```
reference operator*() const ITK_NOEXCEPT
{
  const OffsetType currentOffset = (*m_CurrentOffset);
  auto* result = m_ImageBufferPointer + GetClampedIndex(currentOffset[0] + m_Location[0], m_ImageSize[0]);

  for (ImageDimensionType i = 1; i < ImageDimension; ++i)
  {
    result += GetClampedIndex(currentOffset[i] + m_Location[i], m_ImageSize[i]) * m_OffsetTable[i];
  }

  return reference(result, m_NeighborhoodAccessor);
}

```

I hope that’s acceptable 🙂

---

<div class="post-metadata">

**Author:** ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)\
**Post date:** [May 2, 2018, 1:31pm UTC](https://discourse.itk.org/t/is-image-getoffsettable-0-always-equal-to-1/893/4 "2018-05-02T13:31:03Z")

</div>

> [@Niels\_Dekker](#):
>
> But that would somewhat reduce its performance

Did you quantify the performance difference? Do you have timing results from the experiment?

---

<div class="post-metadata">

**Author:** ![Niels\_Dekker](https://discourse.itk.org/letter_avatar_proxy/v4/letter/n/9d8465/32.png) [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)\
**Post date:** [May 2, 2018, 1:47pm UTC](https://discourse.itk.org/t/is-image-getoffsettable-0-always-equal-to-1/893/5 "2018-05-02T13:47:47Z")

</div>

> [@blowekamp](#):
>
> Did you quantify the performance difference? Do you have timing results from the experiment?

With my test from [Removal of `virtual` keywords from ConstNeighborhoodIterator - #4 by blowekamp](https://discourse.itk.org/t/removal-of-virtual-keywords-from-constneighborhooditerator/814/4) (topic item 4) I observed a very small increase of the run-time duration, when adding support for `offsetTable[0] != 1`, from ~12 to ~13 seconds. (Compiled by MSVC2015 x64 Release.) The performance drop certainly remains well below 10%. 🙂

---

<div class="post-metadata">

**Author:** ![Niels\_Dekker](https://discourse.itk.org/letter_avatar_proxy/v4/letter/n/9d8465/32.png) [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)\
**Post date:** [May 2, 2018, 3:00pm UTC](https://discourse.itk.org/t/is-image-getoffsettable-0-always-equal-to-1/893/6 "2018-05-02T15:00:16Z")

</div>

My next question is actually: Could an `offsetTable[i]` value possibly be negative? Or is it safe to assume that `offsetTable[i] >= 0` (for any unsigned integer `i` \< `ImageDimension`)?

---

<div class="post-metadata">

**Author:** ![Niels\_Dekker](https://discourse.itk.org/letter_avatar_proxy/v4/letter/n/9d8465/32.png) [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)\
**Post date:** [May 8, 2018, 1:22pm UTC](https://discourse.itk.org/t/is-image-getoffsettable-0-always-equal-to-1/893/7 "2018-05-08T13:22:01Z")

</div>

Just for the record: The OffsetTable assumptions that we discussed here, are now removed from ShapedImageNeighborhoodRange:

> <https://github.com/Kitware/ITK/commit/274e610af24fe0bf2ffc1ff70eead102d202ed54>

> <https://github.com/Kitware/ITK/commit/8baafe92b2c486c54af1cf27d21d3ca97fe6ae65>

Thanks for your feedback!

Kind regards, Niels