Skip to main content
Commonmark migration
Source Link

Here are some debugging ideas and a possible workaround. Note that for v10, I am using the Wolfram Programming Cloud, which as far as I can tell, is reproducing your results.

##Version specific specific problem##

Version specific specific problem

Using this code:

$HistoryLength = 0; i = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; GaussianFilter[i, 5]; N[(MemoryInUse[] - oldMem)/1000/1000] 

A fresh WPC session returns 62.8 and a fresh v9 (Windows 7, 64-bit) returns 2.11. Subsequent executions of the same cell in WPC always to 62.8 until such point that I have reached the maximum memory allocated to my plan. On v9, however, four executions of the same cell results in -0.000952 being returned.

Independent of filter

##Independent of filter## NoteNote that the same problem occurs when GaussianFilter is replaced with LaplacianFilter, LaplacianGaussianFilter, but not GradientFilter. For the latter, I obtain similar values for the memory difference on the WPC and v9. For the Laplacian and Gaussian filters, memory differences are on the order of 60 MB.

Possible workaround

##Possible workaround## TheThe problem appears to lie in how the filters are using 3D image files. If we extract ImageData, the problem seems to be mitigated:

$HistoryLength = 0; i = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; Image3D@GaussianFilter[ImageData@i, 5]; N[(MemoryInUse[] - oldMem)/1000/1000] 

The output of the above code block is 1.5 on the WPC and 2.1 on v9. Both platforms return a negative value after 4 executions of the same cell.

It appears that converting the image to data prior to filtering may be a suitable workaround.

i2 = GaussianFilter[i, 5] i3 = Image3D[GaussianFilter[ImageData@i, 5]] 

i2===i3 returns false; however ImageDifference[i2,i3] returns:

enter image description here

A bit of spelunking

##A bit of spelunking## @SimonWoods@SimonWoods traced the problem to Image`FilteringDump`image3DConvolve and came to a similar conclusion with respect to a possible workaround. He graciously allowed me to copy his answer into this one for completeness.

Using Trace and Spelunk I tracked the evaluation of your GaussianFilter through to Image`FilteringDump`image3DConvolve. The memory leak occurs somewhere inside that function, though I was unable to pin it down any further. I couldn't find any sign of leaked temporary symbols in the Image context, so I guess the memory leak is somewhere inside the kernel code.

For a workaround you can apply the filter to the image data directly, which will use ListConvolve internally rather than Image`FilteringDump`image3DConvolve:

$HistoryLength = 0; image = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; Image3D @ GaussianFilter[ImageData @ image, 1]; N[(MemoryInUse[] - oldMem)/1000/1000] (* 0.000984 *) 

Here are some debugging ideas and a possible workaround. Note that for v10, I am using the Wolfram Programming Cloud, which as far as I can tell, is reproducing your results.

##Version specific specific problem##

Using this code:

$HistoryLength = 0; i = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; GaussianFilter[i, 5]; N[(MemoryInUse[] - oldMem)/1000/1000] 

A fresh WPC session returns 62.8 and a fresh v9 (Windows 7, 64-bit) returns 2.11. Subsequent executions of the same cell in WPC always to 62.8 until such point that I have reached the maximum memory allocated to my plan. On v9, however, four executions of the same cell results in -0.000952 being returned.

##Independent of filter## Note that the same problem occurs when GaussianFilter is replaced with LaplacianFilter, LaplacianGaussianFilter, but not GradientFilter. For the latter, I obtain similar values for the memory difference on the WPC and v9. For the Laplacian and Gaussian filters, memory differences are on the order of 60 MB.

##Possible workaround## The problem appears to lie in how the filters are using 3D image files. If we extract ImageData, the problem seems to be mitigated:

$HistoryLength = 0; i = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; Image3D@GaussianFilter[ImageData@i, 5]; N[(MemoryInUse[] - oldMem)/1000/1000] 

The output of the above code block is 1.5 on the WPC and 2.1 on v9. Both platforms return a negative value after 4 executions of the same cell.

It appears that converting the image to data prior to filtering may be a suitable workaround.

i2 = GaussianFilter[i, 5] i3 = Image3D[GaussianFilter[ImageData@i, 5]] 

i2===i3 returns false; however ImageDifference[i2,i3] returns:

enter image description here

##A bit of spelunking## @SimonWoods traced the problem to Image`FilteringDump`image3DConvolve and came to a similar conclusion with respect to a possible workaround. He graciously allowed me to copy his answer into this one for completeness.

Using Trace and Spelunk I tracked the evaluation of your GaussianFilter through to Image`FilteringDump`image3DConvolve. The memory leak occurs somewhere inside that function, though I was unable to pin it down any further. I couldn't find any sign of leaked temporary symbols in the Image context, so I guess the memory leak is somewhere inside the kernel code.

For a workaround you can apply the filter to the image data directly, which will use ListConvolve internally rather than Image`FilteringDump`image3DConvolve:

$HistoryLength = 0; image = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; Image3D @ GaussianFilter[ImageData @ image, 1]; N[(MemoryInUse[] - oldMem)/1000/1000] (* 0.000984 *) 

Here are some debugging ideas and a possible workaround. Note that for v10, I am using the Wolfram Programming Cloud, which as far as I can tell, is reproducing your results.

Version specific specific problem

Using this code:

$HistoryLength = 0; i = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; GaussianFilter[i, 5]; N[(MemoryInUse[] - oldMem)/1000/1000] 

A fresh WPC session returns 62.8 and a fresh v9 (Windows 7, 64-bit) returns 2.11. Subsequent executions of the same cell in WPC always to 62.8 until such point that I have reached the maximum memory allocated to my plan. On v9, however, four executions of the same cell results in -0.000952 being returned.

Independent of filter

Note that the same problem occurs when GaussianFilter is replaced with LaplacianFilter, LaplacianGaussianFilter, but not GradientFilter. For the latter, I obtain similar values for the memory difference on the WPC and v9. For the Laplacian and Gaussian filters, memory differences are on the order of 60 MB.

Possible workaround

The problem appears to lie in how the filters are using 3D image files. If we extract ImageData, the problem seems to be mitigated:

$HistoryLength = 0; i = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; Image3D@GaussianFilter[ImageData@i, 5]; N[(MemoryInUse[] - oldMem)/1000/1000] 

The output of the above code block is 1.5 on the WPC and 2.1 on v9. Both platforms return a negative value after 4 executions of the same cell.

It appears that converting the image to data prior to filtering may be a suitable workaround.

i2 = GaussianFilter[i, 5] i3 = Image3D[GaussianFilter[ImageData@i, 5]] 

i2===i3 returns false; however ImageDifference[i2,i3] returns:

enter image description here

A bit of spelunking

@SimonWoods traced the problem to Image`FilteringDump`image3DConvolve and came to a similar conclusion with respect to a possible workaround. He graciously allowed me to copy his answer into this one for completeness.

Using Trace and Spelunk I tracked the evaluation of your GaussianFilter through to Image`FilteringDump`image3DConvolve. The memory leak occurs somewhere inside that function, though I was unable to pin it down any further. I couldn't find any sign of leaked temporary symbols in the Image context, so I guess the memory leak is somewhere inside the kernel code.

For a workaround you can apply the filter to the image data directly, which will use ListConvolve internally rather than Image`FilteringDump`image3DConvolve:

$HistoryLength = 0; image = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; Image3D @ GaussianFilter[ImageData @ image, 1]; N[(MemoryInUse[] - oldMem)/1000/1000] (* 0.000984 *) 
replaced http://mathematica.stackexchange.com/ with https://mathematica.stackexchange.com/
Source Link

Here are some debugging ideas and a possible workaround. Note that for v10, I am using the Wolfram Programming Cloud, which as far as I can tell, is reproducing your results.

##Version specific specific problem##

Using this code:

$HistoryLength = 0; i = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; GaussianFilter[i, 5]; N[(MemoryInUse[] - oldMem)/1000/1000] 

A fresh WPC session returns 62.8 and a fresh v9 (Windows 7, 64-bit) returns 2.11. Subsequent executions of the same cell in WPC always to 62.8 until such point that I have reached the maximum memory allocated to my plan. On v9, however, four executions of the same cell results in -0.000952 being returned.

##Independent of filter## Note that the same problem occurs when GaussianFilter is replaced with LaplacianFilter, LaplacianGaussianFilter, but not GradientFilter. For the latter, I obtain similar values for the memory difference on the WPC and v9. For the Laplacian and Gaussian filters, memory differences are on the order of 60 MB.

##Possible workaround## The problem appears to lie in how the filters are using 3D image files. If we extract ImageData, the problem seems to be mitigated:

$HistoryLength = 0; i = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; Image3D@GaussianFilter[ImageData@i, 5]; N[(MemoryInUse[] - oldMem)/1000/1000] 

The output of the above code block is 1.5 on the WPC and 2.1 on v9. Both platforms return a negative value after 4 executions of the same cell.

It appears that converting the image to data prior to filtering may be a suitable workaround.

i2 = GaussianFilter[i, 5] i3 = Image3D[GaussianFilter[ImageData@i, 5]] 

i2===i3 returns false; however ImageDifference[i2,i3] returns:

enter image description here

##A bit of spelunking## @SimonWoods traced the problem to Image`FilteringDump`image3DConvolve and came to a similar conclusion with respect to a possible workaround. He graciously allowed me to copy his answer into this one for completeness.

Using Trace and SpelunkSpelunk I tracked the evaluation of your GaussianFilter through to Image`FilteringDump`image3DConvolve. The memory leak occurs somewhere inside that function, though I was unable to pin it down any further. I couldn't find any sign of leaked temporary symbols in the Image context, so I guess the memory leak is somewhere inside the kernel code.

For a workaround you can apply the filter to the image data directly, which will use ListConvolve internally rather than Image`FilteringDump`image3DConvolve:

$HistoryLength = 0; image = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; Image3D @ GaussianFilter[ImageData @ image, 1]; N[(MemoryInUse[] - oldMem)/1000/1000] (* 0.000984 *) 

Here are some debugging ideas and a possible workaround. Note that for v10, I am using the Wolfram Programming Cloud, which as far as I can tell, is reproducing your results.

##Version specific specific problem##

Using this code:

$HistoryLength = 0; i = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; GaussianFilter[i, 5]; N[(MemoryInUse[] - oldMem)/1000/1000] 

A fresh WPC session returns 62.8 and a fresh v9 (Windows 7, 64-bit) returns 2.11. Subsequent executions of the same cell in WPC always to 62.8 until such point that I have reached the maximum memory allocated to my plan. On v9, however, four executions of the same cell results in -0.000952 being returned.

##Independent of filter## Note that the same problem occurs when GaussianFilter is replaced with LaplacianFilter, LaplacianGaussianFilter, but not GradientFilter. For the latter, I obtain similar values for the memory difference on the WPC and v9. For the Laplacian and Gaussian filters, memory differences are on the order of 60 MB.

##Possible workaround## The problem appears to lie in how the filters are using 3D image files. If we extract ImageData, the problem seems to be mitigated:

$HistoryLength = 0; i = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; Image3D@GaussianFilter[ImageData@i, 5]; N[(MemoryInUse[] - oldMem)/1000/1000] 

The output of the above code block is 1.5 on the WPC and 2.1 on v9. Both platforms return a negative value after 4 executions of the same cell.

It appears that converting the image to data prior to filtering may be a suitable workaround.

i2 = GaussianFilter[i, 5] i3 = Image3D[GaussianFilter[ImageData@i, 5]] 

i2===i3 returns false; however ImageDifference[i2,i3] returns:

enter image description here

##A bit of spelunking## @SimonWoods traced the problem to Image`FilteringDump`image3DConvolve and came to a similar conclusion with respect to a possible workaround. He graciously allowed me to copy his answer into this one for completeness.

Using Trace and Spelunk I tracked the evaluation of your GaussianFilter through to Image`FilteringDump`image3DConvolve. The memory leak occurs somewhere inside that function, though I was unable to pin it down any further. I couldn't find any sign of leaked temporary symbols in the Image context, so I guess the memory leak is somewhere inside the kernel code.

For a workaround you can apply the filter to the image data directly, which will use ListConvolve internally rather than Image`FilteringDump`image3DConvolve:

$HistoryLength = 0; image = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; Image3D @ GaussianFilter[ImageData @ image, 1]; N[(MemoryInUse[] - oldMem)/1000/1000] (* 0.000984 *) 

Here are some debugging ideas and a possible workaround. Note that for v10, I am using the Wolfram Programming Cloud, which as far as I can tell, is reproducing your results.

##Version specific specific problem##

Using this code:

$HistoryLength = 0; i = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; GaussianFilter[i, 5]; N[(MemoryInUse[] - oldMem)/1000/1000] 

A fresh WPC session returns 62.8 and a fresh v9 (Windows 7, 64-bit) returns 2.11. Subsequent executions of the same cell in WPC always to 62.8 until such point that I have reached the maximum memory allocated to my plan. On v9, however, four executions of the same cell results in -0.000952 being returned.

##Independent of filter## Note that the same problem occurs when GaussianFilter is replaced with LaplacianFilter, LaplacianGaussianFilter, but not GradientFilter. For the latter, I obtain similar values for the memory difference on the WPC and v9. For the Laplacian and Gaussian filters, memory differences are on the order of 60 MB.

##Possible workaround## The problem appears to lie in how the filters are using 3D image files. If we extract ImageData, the problem seems to be mitigated:

$HistoryLength = 0; i = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; Image3D@GaussianFilter[ImageData@i, 5]; N[(MemoryInUse[] - oldMem)/1000/1000] 

The output of the above code block is 1.5 on the WPC and 2.1 on v9. Both platforms return a negative value after 4 executions of the same cell.

It appears that converting the image to data prior to filtering may be a suitable workaround.

i2 = GaussianFilter[i, 5] i3 = Image3D[GaussianFilter[ImageData@i, 5]] 

i2===i3 returns false; however ImageDifference[i2,i3] returns:

enter image description here

##A bit of spelunking## @SimonWoods traced the problem to Image`FilteringDump`image3DConvolve and came to a similar conclusion with respect to a possible workaround. He graciously allowed me to copy his answer into this one for completeness.

Using Trace and Spelunk I tracked the evaluation of your GaussianFilter through to Image`FilteringDump`image3DConvolve. The memory leak occurs somewhere inside that function, though I was unable to pin it down any further. I couldn't find any sign of leaked temporary symbols in the Image context, so I guess the memory leak is somewhere inside the kernel code.

For a workaround you can apply the filter to the image data directly, which will use ListConvolve internally rather than Image`FilteringDump`image3DConvolve:

$HistoryLength = 0; image = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; Image3D @ GaussianFilter[ImageData @ image, 1]; N[(MemoryInUse[] - oldMem)/1000/1000] (* 0.000984 *) 
Bounty Awarded with 100 reputation awarded by g3kk0
updated answer per comments
Source Link
bobthechemist
  • 19.8k
  • 4
  • 57
  • 150

Here are some debugging ideas and a possible workaround. Note that for v10, I am using the Wolfram Programming Cloud, which as far as I can tell, is reproducing your results.

##Version specific specific problem##

Using this code:

$HistoryLength = 0; i = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; GaussianFilter[i, 5]; N[(MemoryInUse[] - oldMem)/1000/1000] 

A fresh WPC session returns 62.8 and a fresh v9 (Windows 7, 64-bit) returns 2.11. Subsequent executions of the same cell in WPC always to 62.8 until such point that I have reached the maximum memory allocated to my plan. On v9, however, four executions of the same cell results in -0.000952 being returned.

##Independent of filter## Note that the same problem occurs when GaussianFilter is replaced with LaplacianFilter, LaplacianGaussianFilter, but not GradientFilter. For the latter, I obtain similar values for the memory difference on the WPC and v9. For the Laplacian and Gaussian filters, memory differences are on the order of 60 MB.

##Possible workaround## The problem appears to lie in how the filters are using 3D image files. If we extract ImageData, the problem seems to be mitigated:

$HistoryLength = 0; i = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; Image3D@GaussianFilter[ImageData@i, 5]; N[(MemoryInUse[] - oldMem)/1000/1000] 

The output of the above code block is 1.5 on the WPC and 2.1 on v9. Both platforms return a negative value after 4 executions of the same cell.

It appears that converting the image to data prior to filtering may be a suitable workaround.

i2 = GaussianFilter[i, 5] i3 = Image3D[GaussianFilter[ImageData@i, 5]] 

i2===i3 returns false; however ImageDifference[i2,i3] returns:

enter image description here

##A bit of spelunking## @SimonWoods traced the problem to Image`FilteringDump`image3DConvolve and came to a similar conclusion with respect to a possible workaround. He graciously allowed me to copy his answer into this one for completeness.

Using Trace and Spelunk I tracked the evaluation of your GaussianFilter through to Image`FilteringDump`image3DConvolve. The memory leak occurs somewhere inside that function, though I was unable to pin it down any further. I couldn't find any sign of leaked temporary symbols in the Image context, so I guess the memory leak is somewhere inside the kernel code.

For a workaround you can apply the filter to the image data directly, which will use ListConvolve internally rather than Image`FilteringDump`image3DConvolve:

$HistoryLength = 0; image = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; Image3D @ GaussianFilter[ImageData @ image, 1]; N[(MemoryInUse[] - oldMem)/1000/1000] (* 0.000984 *) 

Here are some debugging ideas and a possible workaround. Note that for v10, I am using the Wolfram Programming Cloud, which as far as I can tell, is reproducing your results.

##Version specific specific problem##

Using this code:

$HistoryLength = 0; i = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; GaussianFilter[i, 5]; N[(MemoryInUse[] - oldMem)/1000/1000] 

A fresh WPC session returns 62.8 and a fresh v9 (Windows 7, 64-bit) returns 2.11. Subsequent executions of the same cell in WPC always to 62.8 until such point that I have reached the maximum memory allocated to my plan. On v9, however, four executions of the same cell results in -0.000952 being returned.

##Independent of filter## Note that the same problem occurs when GaussianFilter is replaced with LaplacianFilter, LaplacianGaussianFilter, but not GradientFilter. For the latter, I obtain similar values for the memory difference on the WPC and v9. For the Laplacian and Gaussian filters, memory differences are on the order of 60 MB.

##Possible workaround## The problem appears to lie in how the filters are using 3D image files. If we extract ImageData, the problem seems to be mitigated:

$HistoryLength = 0; i = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; Image3D@GaussianFilter[ImageData@i, 5]; N[(MemoryInUse[] - oldMem)/1000/1000] 

The output of the above code block is 1.5 on the WPC and 2.1 on v9. Both platforms return a negative value after 4 executions of the same cell.

It appears that converting the image to data prior to filtering may be a suitable workaround.

i2 = GaussianFilter[i, 5] i3 = Image3D[GaussianFilter[ImageData@i, 5]] 

i2===i3 returns false; however ImageDifference[i2,i3] returns:

enter image description here

Here are some debugging ideas and a possible workaround. Note that for v10, I am using the Wolfram Programming Cloud, which as far as I can tell, is reproducing your results.

##Version specific specific problem##

Using this code:

$HistoryLength = 0; i = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; GaussianFilter[i, 5]; N[(MemoryInUse[] - oldMem)/1000/1000] 

A fresh WPC session returns 62.8 and a fresh v9 (Windows 7, 64-bit) returns 2.11. Subsequent executions of the same cell in WPC always to 62.8 until such point that I have reached the maximum memory allocated to my plan. On v9, however, four executions of the same cell results in -0.000952 being returned.

##Independent of filter## Note that the same problem occurs when GaussianFilter is replaced with LaplacianFilter, LaplacianGaussianFilter, but not GradientFilter. For the latter, I obtain similar values for the memory difference on the WPC and v9. For the Laplacian and Gaussian filters, memory differences are on the order of 60 MB.

##Possible workaround## The problem appears to lie in how the filters are using 3D image files. If we extract ImageData, the problem seems to be mitigated:

$HistoryLength = 0; i = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; Image3D@GaussianFilter[ImageData@i, 5]; N[(MemoryInUse[] - oldMem)/1000/1000] 

The output of the above code block is 1.5 on the WPC and 2.1 on v9. Both platforms return a negative value after 4 executions of the same cell.

It appears that converting the image to data prior to filtering may be a suitable workaround.

i2 = GaussianFilter[i, 5] i3 = Image3D[GaussianFilter[ImageData@i, 5]] 

i2===i3 returns false; however ImageDifference[i2,i3] returns:

enter image description here

##A bit of spelunking## @SimonWoods traced the problem to Image`FilteringDump`image3DConvolve and came to a similar conclusion with respect to a possible workaround. He graciously allowed me to copy his answer into this one for completeness.

Using Trace and Spelunk I tracked the evaluation of your GaussianFilter through to Image`FilteringDump`image3DConvolve. The memory leak occurs somewhere inside that function, though I was unable to pin it down any further. I couldn't find any sign of leaked temporary symbols in the Image context, so I guess the memory leak is somewhere inside the kernel code.

For a workaround you can apply the filter to the image data directly, which will use ListConvolve internally rather than Image`FilteringDump`image3DConvolve:

$HistoryLength = 0; image = Import["ExampleData/CTengine.tiff", "Image3D"]; oldMem = MemoryInUse[]; Image3D @ GaussianFilter[ImageData @ image, 1]; N[(MemoryInUse[] - oldMem)/1000/1000] (* 0.000984 *) 
Source Link
bobthechemist
  • 19.8k
  • 4
  • 57
  • 150
Loading