KarlSjostrand on master
Update README.md (compare)
KarlSjostrand on master
Update README.md (compare)
KarlSjostrand on develop
Update README.md (compare)
KarlSjostrand on develop
Prepare for release 2.0.2 Post release version bump (compare)
KarlSjostrand on v2.0.2
KarlSjostrand on master
Post release version bump Updated deps Prepare for release 2.0.2 (compare)
KarlSjostrand on develop
Updated deps (compare)
KarlSjostrand on v1.6.1
KarlSjostrand on v1.6.1
Backport of S3 bulk delete bug … (compare)
KarlSjostrand on develop
Prepare for release 2.0.1 Post release version bump (compare)
KarlSjostrand on v2.0.1
KarlSjostrand on master
Post release version bump Added explicit lengths to anon … Fixed bulk delete. Map only cre… and 7 more (compare)
KarlSjostrand on develop
Fixed tests (compare)
KarlSjostrand on develop
Another fix for flat series ord… (compare)
KarlSjostrand on develop
Another fix for flat series ord… (compare)
KarlSjostrand on develop
Fix for flatSeries id problem (compare)
KarlSjostrand on develop
Updated deps. Fixed foreign key… (compare)
KarlSjostrand on 328-bulk-delete
KarlSjostrand on develop
Fixed bulk delete. Map only cre… Merge pull request #329 from sl… (compare)
attributes.get(Tag1)
and get the corresponding DicomAttribute
(wrapped in a monadic type like Try
or Option
)?
1.4.1
I am getting a DicomStreamException
due to a unsupported presentation context.
akka-streams
and dicom-streams
(tagCondition: TagPath => Boolean, stopCondition: TagPath => Boolean, maxBufferSize: Int)
where tagCondition
as you can see is based on tag paths, not Int
s. The thinking was that the simplified case would be only for attributes in the root dataset. Type safety is always nice though so a Tag
class might make sense. What do you think?
TagPath
would not work here? Afterall, it's a wrapper type over the actual tag value as Int
according to the content of the trait. So operation likes Set[Int].max
used to find the maximum tag in the input set for collectAttributesFlow
should work with a Set[TagPath]
, assuming the latter implements the necessary ordering functionality, no?
Tag
class is that it's already taken by dcm4che
so you'd be in risk of introducing conflicts to the compiler, I suppose?
import org.dcm4che.data.{Tag => CheTag}
but I'm hoping that dicom-streams will work without dcm4che in many situations going forward.
Tag
and TagPath
then?
Tag
class provides a list of tag numbers defined as constants. If you think of a DICOM dataset as a tree of elements with data elements at the leaves and sequence elements elsewhere, then the TagPath
data structure describes a path from the root into this tree. You can specify which items of sequences to go into, and also specify "all items" which means that a TagPath can point to multiple branches at once. One example of where this is useful is when modifying attributes. The tag path (0101,0202)[*].(0010,0010) would point to the (0010,0010) tag in all items of the (0101,0202) sequence - if that is what you wish to modify.
newcomer
issue label. Looking at the Akka repo, they have labels good first issue
and small
. Do you prefer one of these?
slicebox
code base
Source[ByteString, NotUsed]
which could then be plugged to an integration pipeline.
Sink[ByteString, Future[Done]]
Directory.ls
from alpakka
)
FileIO.fromPath(Paths.get(path))
.via(validateFlow) // Validate the flow as DICOM.
.via(parseFlow) // Parse the flow to DICOM parts.
.via(blacklistFilter(Set(TagPath.fromTag(Tag.PixelData))))
.via(attributeFlow)
.via(groupLengthDiscardFilter)
.via(modifyFlow(
TagModification.endsWith(TagPath.fromTag(Tag.InstitutionName), _ => updateInstitution, insert = true),
))
.via(fmiGroupLengthFlow)
.runForeach {
case DicomAttribute(h, v) if h.tag == Tag.InstitutionName => println(h, v)
case other => ()
}
(DicomHeader (0008,0080) LO length = 8 value length = 0 ByteString(8, 0, -128, 0, 76, 79, 0, 0),List())
updateInstitution
val updateInstitution: ByteString = padToEvenLength(ByteString("My Institution"), VR.LO)
.via(attributeFlow)
which groups each header and its value chunks into a single object. The modifyFlow does not modify these combined objects. As a side note, attributeFlow
is mostly used as preparation for creating a dcm4che Attributes
but I never liked this pattern. This is improved in the dicom-streams repo which will soon be released.