In order to save CT data I would like to create a DicomImage from scratch, similar like this can be done using DRTImageIOD. However, DicomImage does not have a default constructor. From the documentation it looks like the constructor can only load existing data. Is it possible to use DicomImage directly, or is going low-level through DcmFileFormat the only viable approach? (I am using Dcmtk 3.6.1)
As you can read in the documentation, the purpose of the DicomImage class is visualization (i.e. rendering) of DICOM images, not creating CT image objects (or instances of any other DICOM image IOD).
Since you are using the latest (?) DCMTK snapshot, you might want to have a look at the dcmiod module, which provides a higher-level API than dcmdata.
Related
I'm trying to define a custom QT Slot/Signal for passing a QImage.
I'm using qt_widgets crate which has many predefined slot types like SlotOfQIcon. However it doesn't have one for QImage. I've looked at the source code which is generated with this tool: https://github.com/rust-qt/ritual.
Is it possible to do this in regular Rust project without running complex multistage build involving code generation?
List of implemented slots for reference:
https://docs.rs/qt_widgets/0.3.0/x86_64-pc-windows-msvc/qt_widgets/
I've tried to copy paste generated code for other widgets and modify it, but it doesn't look like a right approach. I don't want to regenerate the whole library just for this case. Are there any simpler options?
I have an R package that makes technical schematics for geology purposes (StratigrapheR on https://cran.r-project.org/web/packages/StratigrapheR/index.html). The idea is to automate the generation of specific graphics as the one below (modified from Humblet and Boulvain 2000 for reference).
It needs a lot of symbols that I would like the user to easily find and use into R. My basic idea is to import SVG files into different "collections", ideally making these collections open-source, and allowing easy access via GitHub repositories or R packages. But also, each user should be able to make their own symbology easily accessible, or propose their own collection online.
What would be the best way to make collections of SVG available into R while allowing other users to add their own collections ?
I am trying to read simple AEC data such as Level and components etc,
I came across .rvt files supports extraction AEC data as explained here :https://forge.autodesk.com/blog/consume-aec-data-which-are-model-derivative-api,
I am trying to achieve similar results with IFC files any idea if its possible,
Or if there is another better way to do it?
No, the Forge translation does not generate AEC data when translating an IFC file.
There is a reason for this: Forge IFC translation goes via NavisWorks, not Revit.
Just like Forge itself, NavisWorks is a generic model vieer, and not AEC specific.
Therefore, AEC specific data is not generated or extracted from the models it processes.
One option to handle your requirement would be to use Forge Design Automation to launch Revit, import the IFC file, and then generate the required AEC specific information there.
Poco supports HMACEngine with different hash functions. For example to create a HMAC-SHA1 function I can use HMACEngine<SHA1Engine> hmca_sha1("secret");
This works well with DigestEngine like SHA1Engine and MD5Engine that have a constructor without argument.
Is it possible to use HMACEngine with hash functions from OpenSSL as they are provided by Poco::Crypto::DigestEngine?
The problem is that these functions take a string parameter in their constructor that specifies which hashing algorithm to use. This means HMACEngine<Poco::Crypto:DigestEngine> hmca_xxx("secret"); wouldn't work.
Any idea how to do this?
I think it will require some coding on Poco side. HMAC is accepting any class as template argument, and hoping it is a Digest class ans using methods like digest() that may not even exist. The HMACEngine that instantiates the class as template, so you can´t passa anything to its constructor as it is. In fact I don´t think that is a good use of templates, while I´m not very familiar with using this C++ resource yet, I think one should not expect anything to be available from templated class.
Probably a new HMACEngine for the Crypto module (instead of Foundation module) would be good. But looks like an approach more like the Poco::Crypto::RSADigestEngine would be better than the current template based one. I´ve recently modified Poco::Crypto::RSADigestEngine to be based on Poco::Crypto::DigestEngine instead off old Foundation Poco::DigestEngine, and therefore for next release it will also support all hashes that OpenSSL support. Basically RSADigestEngine creates an instance of a Poco::Crypto::DigestEngine as base and uses it.
I could help on a patch proposal if you create one at github. Poco::Crypto does need some updates :)
Plone Dexterity supports the definition of the content-type schema either through an interface (using zope.schema for the definition) or through an XML file. What is the preferred/recommended way?
In addition: is there documentation of the XML dialect used for defining a schema (models/mytype.xml) ?
This presentation appears close but not complete.
I personally much prefer the zope.schema route; I can, if I really wanted to, vary the interface attributes dynamically with python, while the XML definition is of course static.
Also, note that to register adapters and views against an XML-defined schema, you need to pull it into python code anyway:
from plone.dexterity import api
class IMyXMLDefinedType(api.Schema):
api.model('my_xml_defined_type.xml')
The XML dialect is part of plone.supermodel package; I was not able to locate any documentation beyond the source code.
I prefer an interface over an xml model. Partly that is because I prefer Python over XML. Partly it is because you cannot do some things with the XML. For example, if you want to register a field as searchable, with collective.dexteritytextindexer, you (currently) cannot set this in the Plone interface, so you will have to use Python code and therefore an interface. But Martijn shows in his answer that you can use api.model in an interface to refer to an xml file, so maybe that would be a way around it if you really want to.
I'm going to contribute to the mess by saying there is no hard and fast answer.
With simpler content types, or early in the development of more complex ones, I'm often oriented towards the supermodel XML because of how closely it works with the dexterity TTW editor. It allows me to work with a client with very rapid feedback on what they want from their content type.
Sometimes I'll even move into file system development of some features while still having the fields defined in the FTI via supermodel.
However, with more complex content types, you're nearly certainly going to hit something you can't do via supermodel alone. At that point, I usually translate to schema — and that's typically pretty easy to do.
Ideally, if you're doing a lot of dexterity development, you should probably be able to shift pretty easily back and forth. They're just different ways of representing the same objects and attributes.