[R] Linking to C type short?

[Duncan Murdoch]

On 12-07-26 9:06 PM, Spencer Graves wrote:
> On 7/26/2012 4:51 PM, Duncan Murdoch wrote:
>> On 12-07-26 4:22 PM, Spencer Graves wrote:
>>> Hello, All:
>>>
>>>
>>>          What references exist on how to link to C?
>>>
>>>
>>>          I'm familiar with sections 5.2 and 5.6 of the "Writing R
>>> Extension" manual plus chapter 6 of Venables and Ripley (2000) S
>>> Programming (Springer).  From these, I get the following:
>>>
>>>
>>> R storage mode   C type
>>> logical          int *
>>> integer          int *
>>> double           double *
>>> complex          Rcomplex *
>>> character        char **
>>> raw              unsigned char *
>>> list             SEXP *
>>> R object         SEXP
>>>
>>>
>>>          "integer" and "int" are 32 bits.  If I understand correctly,
>>> "short" has only 16 bits = 2 bytes.
>>
>> I imagine that depends on the platform and compiler.
>>
>>>
>>>
>>>          Should I define any "short" vector in C as a matrix with 2 rows
>>> of type either "raw" or "char"?
>>
>> What do you want to do with it in R?  If you want to use .C() and just
>> want it to be an opaque blob, then a raw vector is probably best.
>> Have one C function that figures out the size in bytes of the blob,
>> then allocate a raw vector of that size, and call a different function
>> to fill it in (or the same function with different arguments...). If
>> you actually want to work with the short values, then you'll need to
>> convert them to a type that R understands, most likely int (but double
>> would work too).
>
>
>         I have DICOM (.dcm) files from Computed Tomography (CT scans).
> It sounds like readDICOMFile{oro.dicom} should be able to read this.
> Unfortunately, it won't, because my particular DICOM files have images
> stored as lossless JPEG, which is not readable by the current version of
> oro.dicom.  I'm working to fix this deficiency with Brandon Whichter,
> project admin for oro.dicom and related packages.
>
>
>         An example of such an image file is available from the R-Forge
> version of oro.dicom:
>
>
> install.packages("oro.dicom", repos= c("http://R-Forge.R-project.org",
> getOption("repos")))
> library(oro.dicom)
> jpgIn.dcmFile <- system.file('jpeg/cervicalKyphosis.dcm',
>                               package='oro.dicom')
> str(dcm <- readDICOMFile(jpgIn.dcmFile))
>
>
>         dcm$hdr provides information needed to decode the data in the
> rest of the file, returned as dcm$img in this developmental version of
> oro.dicom.  Row 39 tells us the data type:
>
>
>   > dcm$hdr[39,]
>      group element                  name code length
> 39  0008    2111 DerivationDescription   ST     36
>                                     value sequence
> 39 2:1 JPEGLOSSLESSPROCFIRSTORDERREDICT
>
>
>         Brandon Whichter said that the information required to decode
> this type of dcm file is available in Kongji Huang and Brian Smith
> (1994) "Lossless JPEG Codec", v. 1.0 <URL:
> ftp://ftp.cs.cornell.edu/pub/multimed/ljpg.tar.Z>.  One way to use this
> might be to install this software so it is accessible from a commands
> prompt as "ljpgtopnm foo.ljpg foo.ppm", where "foo.ljpg" is an image
> file in lossless JPEG format and foo.ppm is a name for the desired
> decompressed output file.
>
>
>         However, rather than try to invoke a systems command from within
> R, I though it might be better to study the algorithm more carefully.
> This identified a function DecodeImage in C++ or C, which takes an
> argument of class DecompressInfo.  I thought I would try to create this
> DecompressInfo argument from the information available in dcm$hdr, then
> call DecodeImage (compiled C++ or C) from R.

There are a couple of functions called "read.jpeg" on CRAN.  I'd try 
them first rather than writing it myself.

>         I don't know if it's better to use .Call or .C.

.Call generally leads to more efficient code, but it requires you to 
know more about R internals.

Duncan Murdoch

>
>
>         Thanks,
>         Spencer
>
>>
>> If you want to use the .Call interface, there are some other choices,
>> e.g. external pointers.
>>
>> Duncan Murdoch
>>
>>>
>>>
>>>          Thanks,
>>>          Spencer
>>>
>>>
>>> p.s.  I need this to link to lossless JPEG code obtained from
>>> "ftp.cs.cornell.edu/pub/multimed/ljpg.tar.Z"
>>>