Is it possible to read Dicom (https://en.wikipedia.org/wiki/DICOM ) images (which are widely used in medical field) using D language?

Dicom specifications are given here: https://www.dicomstandard.org/current/

There is some discussion on this topic on this page but no details on this forum: https://forum.dlang.org/post/fsjefp$10sp$1@digitalmars.com

I do not think there are any specific d library for this purpose but there are many C libraries available, e.g. :

https://dicom.offis.de/dcmtk.php.en

and

https://github.com/dgobbi/vtk-dicom

There is some discussion here on using C for reading Dicom files on [this forum][3].

Can one of these libraries be used to read Dicom images in D language?

PS: Sample Dicom images are available here: https://www.dicomlibrary.com/

Wrapper for Imebra has been suggested here (https://stackoverflow.com/questions/56278268/reading-dicom-files-in-dlang ) but it is not working.

whats wrong with answer at SO?
https://stackoverflow.com/questions/56278268/reading-dicom-files-in-dlang

On Friday, 31 May 2019 at 11:20:15 UTC, KnightMare wrote:
> whats wrong with answer at SO?
> https://stackoverflow.com/questions/56278268/reading-dicom-files-in-dlang

dlang_wrapper.so file is created.

I try to access it with following file:

import imebra;
import imebra_im;

import core.stdc.stdio;
import core.stdc.stdlib;
import core.sys.posix.dlfcn;

extern (C) int ldl();

void main(){
	//auto loadedDataSet = CodecFactory.load("33141578.dcm") ;
	printf("+main()\n");

    void* lh = dlopen("libdlang_wrapper.so", RTLD_LAZY);
    if (!lh)   {
        fprintf(stderr, "dlopen error: %s\n", dlerror());
        exit(1);
    }
    printf("libdlang_wrapper.so is loaded\n");
}


But it gives following error:

$ rdmd rntestImebra.d
imebra.d(457): Error: function declaration without return type. (Note that constructors are always named this)
imebra.d(457): Error: found data when expecting )
imebra.d(457): Error: semicolon expected following function declaration
imebra.d(457): Error: declaration expected, not ,
imebra.d(459): Error: no identifier for declarator _a
imebra.d(459): Error: declaration expected, not =
imebra.d(460): Error: no identifier for declarator _b
imebra.d(460): Error: declaration expected, not =
imebra.d(464): Error: function declaration without return type. (Note that constructors are always named this)
imebra.d(731): Error: function declaration without return type. (Note that constructors are always named this)
imebra.d(731): Error: found other when expecting )
imebra.d(731): Error: semicolon expected following function declaration
imebra.d(731): Error: declaration expected, not )
imebra.d(733): Error: declaration expected, not if
imebra.d(734): Error: unrecognized declaration
imebra_im.d(51): Error: module `string` is in file 'std/c/string.d' which cannot be read
import path[0] = .
import path[1] = /usr/include/dmd/phobos
import path[2] = /usr/include/dmd/druntime/import
Failed: ["/usr/bin/dmd", "-v", "-o-", "rntestImebra.d", "-I."]

Line 457 of part of this code:

  struct Range {
    private __vector(ushort) _outer;
    private size_t _a, _b;

    this(vector(ushort) data, size_t a, size_t b) {   // <<<<<<<< line 457
      _outer = data;
      _a = a;
      _b = b;
    }

>   struct Range {
>     private __vector(ushort) _outer;
>     private size_t _a, _b;
>
>     this(vector(ushort) data, size_t a, size_t b) {   // <<<<<<<< line 457
>       _outer = data;
>       _a = a;
>       _b = b;
>     }

imo problem is in string
private __vector(ushort)_outer;
it looks like template(vector!ushort) or function or this is vector from core.simd
and replacing it to private long _outer; fix the problem
paste code imebra.d and imebra_im.d to someplace

On Friday, 31 May 2019 at 13:49:02 UTC, KnightMare wrote:
>>   struct Range {
>>     private __vector(ushort) _outer;
>>     private size_t _a, _b;
>>
>>     this(vector(ushort) data, size_t a, size_t b) {   // <<<<<<<< line 457
>>       _outer = data;
>>       _a = a;
>>       _b = b;
>>     }
>
> imo problem is in string
> private __vector(ushort)_outer;
> it looks like template(vector!ushort) or function or this is vector from core.simd
> and replacing it to private long _outer; fix the problem
> paste code imebra.d and imebra_im.d to someplace

Best to download it from https://imebra.com/get-it/ so that all files are available to you.

On Friday, 31 May 2019 at 16:43:28 UTC, rnd wrote:
> On Friday, 31 May 2019 at 13:49:02 UTC, KnightMare wrote:
>>>   struct Range {
>>>     private __vector(ushort) _outer;
>>>     private size_t _a, _b;
>>>
>>>     this(vector(ushort) data, size_t a, size_t b) {   // <<<<<<<< line 457
>>>       _outer = data;
>>>       _a = a;
>>>       _b = b;
>>>     }
>>
>> imo problem is in string
>> private __vector(ushort)_outer;
>> it looks like template(vector!ushort) or function or this is vector from core.simd
>> and replacing it to private long _outer; fix the problem
>> paste code imebra.d and imebra_im.d to someplace
>
> Best to download it from https://imebra.com/get-it/ so that all files are available to you.

I am still waiting for someone to help me with this.

Can we directly call C functions from D without going through swig?

On Monday, 3 June 2019 at 14:19:40 UTC, Rnd wrote:
> On Friday, 31 May 2019 at 16:43:28 UTC, rnd wrote:
>> On Friday, 31 May 2019 at 13:49:02 UTC, KnightMare wrote:
>>>>   struct Range {
>>>>     private __vector(ushort) _outer;
>>>>     private size_t _a, _b;
>>>>
>>>>     this(vector(ushort) data, size_t a, size_t b) {   // <<<<<<<< line 457
>>>>       _outer = data;
>>>>       _a = a;
>>>>       _b = b;
>>>>     }
>>>
>>> imo problem is in string
>>> private __vector(ushort)_outer;
>>> it looks like template(vector!ushort) or function or this is vector from core.simd
>>> and replacing it to private long _outer; fix the problem
>>> paste code imebra.d and imebra_im.d to someplace
>>
>> Best to download it from https://imebra.com/get-it/ so that all files are available to you.
>
> I am still waiting for someone to help me with this.
>
> Can we directly call C functions from D without going through swig?

We can call C functions directly from D. First, the functions must be declared in D, as D's syntax is different from C's.

There exists tools to help us with that :
- dstep, https://code.dlang.org/packages/dstep
- dpp, https://code.dlang.org/packages/dpp
The latter, dpp, acts like a preprocessor to allow inclusion with `#include` as would be done with C header files.

The swig D module is quite old and I would presume it is outdated - but I may be wrong.

Note that the standard C library is available in the `core.stdc` modules.

Sometimes, these tools manage to translate 95% of header files properly, but some manual tweaking is necessary to handle the remaining 5%. The following page in the D documentation explains how to interface with C: https://dlang.org/spec/interfaceToC.html .
Looking at the output generally gives a good inspiration of what code pattern to use to fix the issues.

C++ is a different matter. The binding tool ecosystem gives more mixed results than with C:
- dstep does not generate declarations for C++;
- dpp is still a work in progress; the last time I looked at its commits, I saw some unit tests checking the binding of simple classes - but I wouldn't expect it to work with much of the STL;
- There exist Binderoo: https://github.com/GooberMan/binderoo which is a mean to script C++ game using D, less active than the first two, but could be helpful, I haven't researched it much. The author gave a presentation during DConf 2017: https://www.youtube.com/watch?v=2B0-jukh4TU .

The following page of the D documentation explains how to interface with C++: https://dlang.org/spec/cpp_interface.html .

Interfacing with C is much easier than with C++. I was once in need of a C++ library without any C API; I wrote a wrapper for it:
- some C++ function within an `extern "C" {}` declaration,
    - with helper function to create and delete my C++ class instances,
    - the main C++ methods I wanted to expose,
- a D binding declaration, exposing the previous function to D,
- a higher level D mirroring the C++ classes,
- exception were caught in the C++ `extern "C" {}` function: I returned a special Result struct containing a boolean status, the result or null, and a possible error message. I would then throw a D exception to let the user code handle the error.

Nowadays, D's C++ support is better. If you can restrict to just a subset of the library, writing a wrapper might be feasible, but would include wrapping part of the STL not yet in the `core.stdcpp` modules (for libraries using the STL).

On Monday, 3 June 2019 at 15:56:00 UTC, Rémy Mouëza wrote:
> On Monday, 3 June 2019 at 14:19:40 UTC, Rnd wrote:
>> [...]
>
> We can call C functions directly from D. First, the functions must be declared in D, as D's syntax is different from C's.
>
> [...]


Thanks for a very comprehensive answer.