Stuck at ExportByteArray
See original GitHub issuesession=WolframLanguageSession()
img = Image.open("path_to_image")
data = session.evaluate(wl.CurvatureFlowFilter(img, 50))
z = session.evaluate(wl.ExportByteArray(data, "PNG"))
Changing CurvatureFlowFilter to other functions like ‘Binarize’ gives the desired output but gets stuck at ExportByteArray.
This is the Trace when process is manually interrupted:
File “/home/nikhal/.PyCharmCE2019.1/config/scratches/scratch_82.py”, line 25, in Binarize z = session.evaluate(wl.ExportByteArray(data, “PNG”)) File “/usr/local/lib/python3.6/dist-packages/wolframclient/evaluation/kernel/localsession.py”, line 259, in evaluate result = self.evaluate_wrap(expr, **kwargs) File “/usr/local/lib/python3.6/dist-packages/wolframclient/evaluation/kernel/localsession.py”, line 256, in evaluate_wrap return self.evaluate_wrap_future(expr, **kwargs).result() File “/usr/lib/python3.6/concurrent/futures/_base.py”, line 427, in result self._condition.wait(timeout) File “/usr/lib/python3.6/threading.py”, line 295, in wait waiter.acquire() KeyboardInterrupt
Here is my code: binarize.txt
Issue Analytics
- State:
- Created 4 years ago
- Reactions:2
- Comments:10 (7 by maintainers)
I suspect that the size of the input image makes a difference here.
I ran your script on a 100kb file (
ExampleData[{"TestImage", "House"}]
) and it worked. Then I used a bigger one generated withRandomImage[1, {2000, 2000}, ColorSpace -> "RGB"]
. This time it took a lot of time to evaluateCurvatureFlowFilter
. Log says ~80sec.To better understand where the bottleneck is, I ran the code in a notebook. With an image of size 200x200 pixels, I already get an evaluation timer of a second:
No doubt that it would takes tens of seconds for the bigger picture I mentioned above.
A quick comment, not related, in general one should avoid as much as possible to send data back and forth to the kernel. Remove unnecessary intermediate variables whenever you can.
e.g.: rewriting
as
reduces the data exchanged to only the resulting byte array. Of course your code is much easier to debug and I understand why you would write it this way until it actually works, so feel free to ignore this.
Closing the issue.