{"action":"closed","issue":{"url":"https://api.github.com/repos/Radiomics/pyradiomics/issues/392","repository_url":"https://api.github.com/repos/Radiomics/pyradiomics","labels_url":"https://api.github.com/repos/Radiomics/pyradiomics/issues/392/labels{/name}","comments_url":"https://api.github.com/repos/Radiomics/pyradiomics/issues/392/comments","events_url":"https://api.github.com/repos/Radiomics/pyradiomics/issues/392/events","html_url":"https://github.com/Radiomics/pyradiomics/issues/392","id":334528882,"node_id":"MDU6SXNzdWUzMzQ1Mjg4ODI=","number":392,"title":"Inconsistent wavelet feature values between v1.2.0 and v1.3.0","user":{"login":"sandfis","id":40466488,"node_id":"MDQ6VXNlcjQwNDY2NDg4","avatar_url":"https://avatars3.githubusercontent.com/u/40466488?v=4","gravatar_id":"","url":"https://api.github.com/users/sandfis","html_url":"https://github.com/sandfis","followers_url":"https://api.github.com/users/sandfis/followers","following_url":"https://api.github.com/users/sandfis/following{/other_user}","gists_url":"https://api.github.com/users/sandfis/gists{/gist_id}","starred_url":"https://api.github.com/users/sandfis/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sandfis/subscriptions","organizations_url":"https://api.github.com/users/sandfis/orgs","repos_url":"https://api.github.com/users/sandfis/repos","events_url":"https://api.github.com/users/sandfis/events{/privacy}","received_events_url":"https://api.github.com/users/sandfis/received_events","type":"User","site_admin":false},"labels":[{"id":260718201,"node_id":"MDU6TGFiZWwyNjA3MTgyMDE=","url":"https://api.github.com/repos/Radiomics/pyradiomics/labels/question","name":"question","color":"cc317c","default":true}],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":11,"created_at":"2018-06-21T14:48:04Z","updated_at":"2018-08-14T11:47:18Z","closed_at":"2018-08-14T11:47:18Z","author_association":"NONE","body":"Hi! I have taken on a project that was previously started by someone who was using pyradiomics v1.2. Given that I just started, I opted for the latest version (v.1.3). To ensure that I was on the right track, I was comparing resulting features from my runs with the person who was working with v1.2 and I found some significant discrepancies in the features calculated from the wavelet filtered images. I have been able to pin-point two issues:\r\n\r\nIssue 1:\r\nIn version 1.3, I found that some of the decomposition names were not attributed to the correct decomposition image. I discovered this when I saw that there was almost perfect symmetry comparing to version 1.2.  \r\n![image](https://user-images.githubusercontent.com/40466488/41724877-8d179048-753c-11e8-8915-f36be53c576e.png)\r\nThis is specific to the wavelet decompositions whose names are not palindromes (e.g. “LLL” features were the same across versions whereas HHL(v1.3) = LHH(v.1.2), LLH (v1.3) = HHL (v.1.2), etc). Digging a bit into the getWaveletImage function in imageoperations.py, I saw that there was the addition of the following lines in v1.3:\r\n\r\naxes = {2, 1, 0}  # set\r\nif kwargs.get('force2D', False):\r\n    axes -= {kwargs.get('force2Ddimension', 0)}  # set\r\n\r\napprox, ret = _swt3(inputImage, kwargs.get('wavelet', 'coif1'), kwargs.get('level', 1), kwargs.get('start_level', 0), axes=tuple(axes))\r\n\r\nFrom my understanding of pywavelet, axes is the variable whose order determines the order of the letters in the decomposition name. I was wondering why this is a set? It seems to me that its order would then be unpredicatable when converting to a tuple in the _swt3 function which could then change the decomposition name and feature labels. When I change the axes variable to a list, I'm no longer getting the issue.\r\n\r\nIssue 2: \r\nWhen I fixed the above issue, I started getting the same wavelet feature values as v1.2 for some of the images but not others. And this time the discrepancies were random (and significant). \r\n![image](https://user-images.githubusercontent.com/40466488/41725757-91239dba-753e-11e8-9f2f-9ac721b246f2.png)\r\nAgain looking at the getWaveletImage function in imageoperations.py v1.3, it seems that the images are getting padded if their dimensions are not divisible by 2. This seems to be a constraint placed by pywavelets where signal length must be divisible by 2**level (2 in this case). I don't think the same padding is occurring in v 1.2. Indeed, when I look at the dimensions of the images that I tested, the images that match perfectly with v1.2 had even dimensions (no padding in v.1.3) whereas those that did not had at least one odd dimension (padding in v1.3). Is it safe to say that v1.3 has the most accurate feature values for the wavelet filtered images (with the exception of the first issue)?\r\n"}}
{"actor":{"display_login":"JoostJM"}}