Automatically picking bit-depth based on value seems dangerous, but a
`guess_best_dtype(input_data: np.array) -> dtype` helper function would be
useful.
Tom
On Fri, Mar 30, 2018 at 10:10 AM Gregory Lee <grlee77(a)gmail.com> wrote:
> On Thu, Mar 29, 2018 at 1:46 PM, Juan Nunez-Iglesias <jni.soma(a)gmail.com>
> wrote:
>
>> I think maybe 50% of our bug reports/help requests have to do with image
>> data types. Does anyone want to express an opinion about how …
[View More]we can fix
>> things?
>>
>> My humble (really) suggestions, *to start* (ie more needs to be done than
>> this):
>>
>> * If a 16-bit or higher image has no values above 4096 or below 0, treat
>> the image as 12 bit. This is a very common image type for some reason.
>>
>
>
> One common source for 12-bit is the DICOM standard used by industry for
> medical imaging.
>
>
> * If an integer image has no values above 255, treat it as an 8-bit image.
>> This also happens a lot.
>>
>
>> * If a floating point image has values outside [0, 1], don’t croak, just
>> accept it. (This might have already happened?) If it has values only in [0,
>> 1/255], and the user wants to convert to uint8, use the input range as the
>> range.
>>
>>
> I am in favor of accepting arbitrarily scaled floats unless the algorithm
> depends on values being within a particular range (not sure if we have many
> of these?). We do already allow unscaled floats in some places (e.g.
> compare_nrmse, etc), but it is not very consistent. For example, I
> recently noticed that denoise_wavelet enforces floats to be in [0, 1] (or
> [-1, 1]), but it would work equally well for unscaled data.
>
>
>
>> Some of these, especially the last one, may appear too magical, and in
>> some ways I think they are, but honestly, given the frequency of problems
>> that we get because of this, I think it’s time to suck it up and really
>> work on doing what most of our users want most of the time. We don’t need
>> to coddle the power users — they can be annoyed and micromanage the image
>> range properly. To paraphrase a tweet I saw once (sorry, couldn’t find
>> attribution): “edge cases should be used to check the design, not drive it.”
>>
>> Applied to this case, we shouldn’t scale a uint32 image by 2**(-32) just
>> because we can come up with a test case where this is useful.
>>
>> Some of these problems would be alleviated by some consistent metadata
>> conventions.
>>
>> Juan.
>>
>>
>> _______________________________________________
>> scikit-image mailing list
>> scikit-image(a)python.org
>> https://mail.python.org/mailman/listinfo/scikit-image
>>
>> _______________________________________________
> scikit-image mailing list
> scikit-image(a)python.org
> https://mail.python.org/mailman/listinfo/scikit-image
>
[View Less]
I think maybe 50% of our bug reports/help requests have to do with image data types. Does anyone want to express an opinion about how we can fix things?
My humble (really) suggestions, *to start* (ie more needs to be done than this):
* If a 16-bit or higher image has no values above 4096 or below 0, treat the image as 12 bit. This is a very common image type for some reason.
* If an integer image has no values above 255, treat it as an 8-bit image. This also happens a lot.
* If a floating …
[View More]point image has values outside [0, 1], don’t croak, just accept it. (This might have already happened?) If it has values only in [0, 1/255], and the user wants to convert to uint8, use the input range as the range.
Some of these, especially the last one, may appear too magical, and in some ways I think they are, but honestly, given the frequency of problems that we get because of this, I think it’s time to suck it up and really work on doing what most of our users want most of the time. We don’t need to coddle the power users — they can be annoyed and micromanage the image range properly. To paraphrase a tweet I saw once (sorry, couldn’t find attribution): “edge cases should be used to check the design, not drive it.”
Applied to this case, we shouldn’t scale a uint32 image by 2**(-32) just because we can come up with a test case where this is useful.
Some of these problems would be alleviated by some consistent metadata conventions.
Juan.
[View Less]
Hello,
I'm having trouble achieving robust performance with
`skimage.measure.ransac` when estimating fundamental matrix for a pair
of images.
I'm seeing highly varying results with different random seeds when
compared to OpenCV's `findFundamentalMatrix`.
I'm running both skimage's and opencv's ransac on the same sets of
keypoints and with (what I'm assuming are) equivalent parameters.
I'm using the same image pair as OpenCV python tutorials
(https://github.com/abidrahmank/OpenCV2-Python-…
[View More]Tutorials/tree/master/data).
Here's my demonstration script:
import cv2
import numpy as np
from skimage import io
from skimage.measure import ransac
from skimage.feature import ORB, match_descriptors
from skimage.transform import FundamentalMatrixTransform
orb = ORB(n_keypoints=500)
img1 = io.imread('images/right.jpg', as_grey=True)
orb.detect_and_extract(img1)
kp1 = orb.keypoints
desc1 = orb.descriptors
img2 = io.imread('images/left.jpg', as_grey=True)
orb.detect_and_extract(img2)
kp2 = orb.keypoints
desc2 = orb.descriptors
matches = match_descriptors(desc1, desc2, metric='hamming',
cross_check=True)
kp1 = kp1[matches[:, 0]]
kp2 = kp2[matches[:, 1]]
n_iter = 10
skimage_inliers = np.empty((n_iter, len(matches)))
opencv_inliers = skimage_inliers.copy()
for i in range(n_iter):
fmat, inliers = ransac((kp1, kp2), FundamentalMatrixTransform,
min_samples=8, residual_threshold=3,
max_trials=5000, stop_probability=0.99,
random_state=i)
skimage_inliers[i, :] = inliers
cv2.setRNGSeed(i)
fmat, inliers = cv2.findFundamentalMat(kp1, kp2,
method=cv2.FM_RANSAC,
param1=3, param2=0.99)
opencv_inliers[i, :] = (inliers.ravel() == 1)
skimage_sum_of_vars = np.sum(np.var(skimage_inliers, axis=0))
opencv_sum_of_vars = np.sum(np.var(opencv_inliers, axis=0))
print(f'Scikit-Image sum of inlier variances:
{skimage_sum_of_vars:>8.3f}')
print(f'OpenCV sum of inlier variances: {opencv_sum_of_vars:>8.3f}')
And the output:
Scikit-Image sum of inlier variances: 13.240
OpenCV sum of inlier variances: 0.000
I use the sum of variances of inliers obtained from different random
seeds as the metric of robustness.
I would expect this number to be very close to zero, because truly
robust ransac should converge to the same model independently of it's
random initialization.
How can I make skimage's `ransac` behave as robustly as opencv's?
Any other tips on this subject would be greatly appreciated.
Best regards,
Martin
(I originally posted this question on stackoverflow, but I'm not getting
much traction there, so I figured I'd try the mailing list.)
https://stackoverflow.com/questions/49342469/robust-epipolar-geometry-estim…
[View Less]