ElasticTransformation incorrect filling new pixels #561
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
For all other geometric augmentations, when applied to 3-channel pictures `cval` value interpreted as (cval,cval,cval), so you can set either black/gray/white filling of emerged pixels. However, for Elastic Transformation setting `cval=255` leads to red pixels. That is happening because cv2.remap takes RGB tuple for 3-channel images for `borderValue`. If integer passed, it is used as (cval,0,0), hence producing red pixels. I'm not sure this is correct way to fix this issue, but at least on my setup it works.
Codecov Report
@@ Coverage Diff @@
## master #561 +/- ##
==========================================
- Coverage 96.43% 96.42% -0.01%
==========================================
Files 38 38
Lines 13933 13933
==========================================
- Hits 13436 13434 -2
- Misses 497 499 +2 |
|
Nice, thanks a lot for pointing this one out. There were tests for the The way it is implemented should be good for now. The cval should probably be sampled channelwise at some point so that e.g. RGB values and not just intensity values are possible. But that can be reserved for a follow-up patch. |
|
Merged. |
aleju
added a commit
that referenced
this pull request
Jan 11, 2020
This is a follow-up patch for PR #561, which fixed that new pixels were filled by ElasticTransformation with `(cval, 0, 0)` instead of `(cval, cval, cval)`. This patch adds a corresponding changelog entry and test case.
aleju
added a commit
that referenced
this pull request
Jan 11, 2020
Follow-up on PR #561 (test, changelog entry)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For all other geometric augmentations, when applied to 3-channel pictures
cvalvalue interpreted as (cval,cval,cval), so you can set either black/gray/white filling of emerged pixels. However, for Elastic Transformation settingcval=255leads to red pixels. That is happening because cv2.remap takes RGB tuple for 3-channel images forborderValue. If integer passed, it is used as (cval,0,0), hence producing red pixels.I'm not sure this is correct way to fix this issue, but at least on my setup it works.