4c770587e2
QImage's bytes are aligned to memory words per column of pixels. That means that one of these columns contains 99% valid image data, but with several bytes of unassigned noise at the end. How many of these padding bytes there are would depend on the image size, i.e. Cura's window size. In the end, the total number of bytes in the image ends up slightly more than w*h*3. As a result, Cura would crash because it couldn't reshape the image. Reshaping was completely unnecessary anyway, but this random noise was giving false positives also. But how do you then get only the actual pixels from each column of data? We can't just go iterating over this array, as that would be an iteration of thousands of columns which is prohibitively slow in Python. No, we're going to do some Numpy magic. We're going to create a class that pretends to be a Numpy array. Give this class some data and say that this data has a certain pixel size but also a certain STRIDE LENGTH. This stride length can be the length of the actual pixel data. As a result when Numpy sees this object it will read out the data using these strides, all done efficiently within the C code of Numpy. Framerate is fantastic on my computer. No problems at all. Pretty powerful computer though. But also a big 5k screen. Still no problem for Numpy. Seems to be decently efficient. Took me quite a while to figure all of this out. Contributes to issue CURA-7262. |
||
|---|---|---|
| .github | ||
| cmake | ||
| cura | ||
| docker | ||
| docs | ||
| icons | ||
| plugins | ||
| resources | ||
| scripts | ||
| tests | ||
| .dockerignore | ||
| .gitignore | ||
| .pylintrc | ||
| build.sh | ||
| CMakeLists.txt | ||
| contributing.md | ||
| cura.appdata.xml | ||
| cura.desktop.in | ||
| cura.sharedmimeinfo | ||
| cura_app.py | ||
| Dockerfile | ||
| Jenkinsfile | ||
| LICENSE | ||
| pytest.ini | ||
| README.md | ||
| requirements.txt | ||
| run_coverage.py | ||
| run_in_docker.sh | ||
| run_mypy.py | ||
| test-in-docker.sh | ||
Cura
This is the new, shiny frontend for Cura. Check daid/LegacyCura for the legacy Cura that everyone knows and loves/hates. We re-worked the whole GUI code at Ultimaker, because the old code started to become unmaintainable.
Logging Issues
For crashes and similar issues, please attach the following information:
- (On Windows) The log as produced by dxdiag (start -> run -> dxdiag -> save output)
- The Cura GUI log file, located at
%APPDATA%\cura\<Cura version>\cura.log(Windows), or usuallyC:\Users\\<your username>\AppData\Roaming\cura\<Cura version>\cura.log$USER/Library/Application Support/cura/<Cura version>/cura.log(OSX)$USER/.local/share/cura/<Cura version>/cura.log(Ubuntu/Linux)
If the Cura user interface still starts, you can also reach this directory from the application menu in Help -> Show settings folder
For additional support, you could also ask in the #cura channel on FreeNode IRC. For help with development, there is also the #cura-dev channel.
Dependencies
- Uranium Cura is built on top of the Uranium framework.
- CuraEngine This will be needed at runtime to perform the actual slicing.
- fdm_materials Required to load a printer that has swappable material profiles.
- PySerial Only required for USB printing support.
- python-zeroconf Only required to detect mDNS-enabled printers.
Build scripts
Please checkout cura-build for detailed building instructions.
Running from Source
Please check our Wiki page for details about running Cura from source.
Plugins
Please check our Wiki page for details about creating and using plugins.
Supported printers
Please check our Wiki page for guidelines about adding support for new machines.
Configuring Cura
Please check out Wiki page about configuration options for developers.
Translating Cura
Please check out Wiki page about how to translate Cura into other languages.
License
Cura is released under the terms of the LGPLv3 or higher. A copy of this license should be included with the software.