Closed imcom closed 2 years ago
I dont' have a iMac at hand to reproduce this bug, have you tweaked with renders.py to see if some settings may have an effect on this behavier? For example change float
to ti.f32
in this line? Though it's a very rare chance that this is the cause of the bug ...
I dont' have a iMac at hand to reproduce this bug, have you tweaked with renders.py to see if some settings may have an effect on this behavier? For example change
float
toti.f32
in this line? Though it's a very rare chance that this is the cause of the bug ...
Nope, I am not sure what params can/shall be tweaked :P, I will try the float
-> ti.f32
tonight to see if the crash still happens
Hello! The imwrite issue is a bit weird. Can you try using an absolute path instead of relative for the file? As for the CPU backend / GGUI compatibility issue, it seems to be a bug for a while, we are still trying to figure out why, sorry for that!
On my M1 Mac:
[E 04/18/22 14:54:47.466 7900605] [image_io.cpp:imwrite@30] Cannot write image file [screenshot-2022-04-18-145447.jpg]
* Taichi Core - Stack Traceback *
==========================================================================================
| Module | Offset | Function |
|----------------------------------------------------------------------------------------|
* taichi_core.so | 120 | taichi::Logger::error(std::__1::basic_string< |
| char, std::__1::char_traits<char>, std::__1:: |
| allocator<char> > const&, bool) |
* taichi_core.so | 1408 | taichi::imwrite(std::__1::basic_string<char, |
| std::__1::char_traits<char>, std::__1::alloca |
| tor<char> > const&, unsigned long, int, int, |
| int) |
* taichi_core.so | 72 | void pybind11::cpp_function::initialize<void |
| (*&)(std::__1::basic_string<char, std::__1::c |
| har_traits<char>, std::__1::allocator<char> > |
| const&, unsigned long, int, int, int), void, |
| std::__1::basic_string<char, std::__1::char_ |
| traits<char>, std::__1::allocator<char> > con |
| st&, unsigned long, int, int, int, pybind11:: |
| name, pybind11::scope, pybind11::sibling>(voi |
| d (*&)(std::__1::basic_string<char, std::__1: |
| :char_traits<char>, std::__1::allocator<char> |
| > const&, unsigned long, int, int, int), voi |
| d (*)(std::__1::basic_string<char, std::__1:: |
| char_traits<char>, std::__1::allocator<char> |
| > const&, unsigned long, int, int, int), pybi |
| nd11::name const&, pybind11::scope const&, py |
| bind11::sibling const&)::'lambda'(pybind11::d |
| etail::function_call&)::operator()(pybind11:: |
| detail::function_call&) const |
* taichi_core.so | 3316 | pybind11::cpp_function::dispatcher(_object*, |
| _object*, _object*) |
* Python3 | 140 | (null) |
* Python3 | 372 | (null) |
* Python3 | 448 | (null) |
* Python3 | 23928 | (null) |
* Python3 | 120 | (null) |
* Python3 | 288 | (null) |
* Python3 | 23928 | (null) |
* Python3 | 120 | (null) |
* Python3 | 288 | (null) |
* Python3 | 23900 | (null) |
* Python3 | 3212 | (null) |
* Python3 | 60 | (null) |
* Python3 | 280 | (null) |
* Python3 | 248 | (null) |
* Python3 | 1624 | (null) |
* Python3 | 340 | (null) |
* Python3 | 40 | (null) |
* libdyld.dylib | 4 | (null) |
==========================================================================================
Internal error occurred. Check out this page for possible solutions:
https://docs.taichi.graphics/lang/articles/install
Traceback (most recent call last):
File "main.py", line 18, in <module>
scene.finish()
File "/Users/yuanming/repos/voxels/scene.py", line 175, in finish
ti.tools.image.imwrite(img, fname)
File "/Users/yuanming/Library/Python/3.8/lib/python/site-packages/taichi/tools/image.py", line 73, in imwrite
_ti_core.imwrite(filename, ptr, resx, resy, comp)
RuntimeError: [image_io.cpp:imwrite@30] Cannot write image file [screenshot-2022-04-18-145447.jpg]
Hello! The imwrite issue is a bit weird. Can you try using an absolute path instead of relative for the file? As for the CPU backend / GGUI compatibility issue, it seems to be a bug for a while, we are still trying to figure out why, sorry for that!
Using an absolute path works on my end! @neozhaoliang Can you simply use the absolute path for now (using os.path.join
etc.)?
import taichi as ti
import numpy as np
ti.init(arch=ti.vulkan) # If not initializing with vulkan the program works
img = np.zeros((16, 16, 3))
ti.tools.image.imwrite(img, 'a.jpg')
# ti.tools.image.imwrite(img, '/tmp/a.jpg')
# If using an absolute path, the program works
@imcom Updated the code by using the absolute path for imwrite. Could you please try the new code and see if the bug is fixed?
The problem still exists because ti.vulkan
initialization changes cwd on Mac for some reason: https://github.com/taichi-dev/taichi/issues/4811 We need to fix that in Taichi to systematically address this issue.
@imcom Updated the code by using the absolute path for imwrite. Could you please try the new code and see if the bug is fixed?
Sry for the late reply
Turned out that it did generate images ... as yuanming said ... the cwd
is not set properly ...
cuz once you print out the cwd
... I found this... lol
For a workaround, dirpath = os.path.dirname(os.path.abspath(__file__))
might be appropriate
This PR fixes the cwd
problem. Please build from source again and see if it's fixed?
Environment:
-> % python -V Python 3.9.12 taichi 1.0.0 numpy 1.22.3
Issue: Using the template to install and create the scene on my iMac (as above), the renderer works well but whenever I press
p
, there is no screenshots can be saved. I've got a minimum script to reproduce the issueWith this script, I noticed that if the
arch
is set toti.cpu
for instance, the img can be written to FS. But withti.vulkan
, there is no image written.P.S. If I change the
arch
to either cpu / gpu in thescene.py
. Then the script will crash. Attached the crash log as bellow.