resizeImage(...) for unbound values
Borda opened this issue · 8 comments
Hello, I found some difficulty with using resizeImage(...) for a geometrically warped image. I was performing image registration via RNiftyReg package and their transformation slightly change the pixel values from (0, 1) to (0, 1.09). This case that the resized image is just black/white with a few dots. In the end clip image values to the range (0, 1) solves the issue but it quite unintuitive what and why the resize returns unexpected results...
hello @Borda and I'm sorry for the late reply,
what a coincidence a few days ago I visited your 'pyImSegm' Github repository. I'm currently interested on the utilization of super-pixels for various machine learning tasks.
If you could add a reproducible example, I will be in place to alter the function so that similar issues can be avoided. thanks.
Thank you, the use case I am talking about is following and my fix to the issue https://github.com/Borda/BIRL/blob/master/scripts/Rscript/RNiftyReg_linear.r#L71
@Borda I edited my previous comment,
actually the issue isn't related with the resizeImage() function and the fact that I use internally a maximum value of 255.0, because the 'resizeImage()' function returns values between 0.0 and 1.0
If you want to avoid clipping the values (which might modify the output of the 'niftyreg.linear()' function) you can use the OpenImageR::norm_matrix_range function which normalizes the matrix values to a specific range (here between 0.0 and 1.0),
imgWarp <- applyTransform( forward(result) , source)
imgWarp = OpenImageR::norm_matrix_range(imgWarp, min_value = 0.0, max_value = 1.0)
if (scale > 1) {
imgWarp <- resizeImage(imgWarp, round(dim(imgWarp)[1] * scale), round(dim(imgWarp)[2] * scale))
}
hopefully this will resolve your issue.
I see, but my point was more about what you have to think about clipping the image range... because for example while saving the image the slightly larger values than 1. do not have any negative impact compared to using resize where it moves to a binary image with 1 for >1 and 0 for <1...
In the end, I just say that the behaviour is not very intuitive and it would be safer to assume image with values < 1.5 to be in range (0, 1)
@mlampros I have tried your proposed clipping but then in crashes
Error in writeImage(imgWarp, outImg) :
supported image data are matrix, data frame, array
In addition: Warning message:
In if (!class(data) %in% c("matrix", "array")) stop("supported image data are matrix, data frame, array") :
the condition has length > 1 and only the first element will be used
Execution halted
I'm trying to follow your thinking.
From your R script I understand that you want to perform image registration, so you load the 'reference' image and a second image (which should be adjusted ), then if the 'scale' parameter is greater than 1 you do resizing (which till now does not give any problems as the values are between 0.0 and 1.0). Then you utilize the 'niftyreg.linear' function in order to register the images. The output of the 'niftyreg.linear' has values in the range,
imgWarp <- applyTransform( forward(result) , source)
summary(as.vector(imgWarp))
Min. 1st Qu. Median Mean 3rd. Qu. Max.
-0.07581 0.79166 0.86537 0.83790 0.95674 1.09163
so you clip the images between 0 and 1 (some values are less than 0.0 and other greater than 1.0) and perform resizing without an issue. Am I correct?
My suggestion here is to normalize the 'imgWarp' niftiImage mainly because if you clip the values to a specific range then your output will be modified. For instance in your function you moved all values less than 0 to become 0 and values greater than 1 to become 1. This does not happen if you use the 'OpenImageR::norm_matrix_range' function. The closest explanation I've found on the web was this stackoverflow thread ( especially the comment which mentions about changing the direction of a vector )
ok, thank you :)
you are welcome. Thanks for the BIRL (Benchmark on Image Registration methods with Landmark validations) and for making me aware of the ' RNiftyReg' package. I'll definitely take a look as I find image registration useful but at the same time difficult too.