almeida-a / imodec-dicoogle-plugin Goto Github PK

Is your feature request related to a problem? Please describe.
It is not very user friendly for the user to manually write the url to the images.

Describe the solution you'd like
Upon the encoding and storing of the image, log the url(s) that the user can click in order to view the image.

A first version of the storage plugin is due (allowing to encode dicom files with the recent compression formats).
Here is a checklist of what is needed to do in order to complete this plugin:

• Extract the image from the pixel data
• Encode the extracted image
• Rewrite the pixel data as well as other important attributes (transfer syntax, lossy compression flag, etc.)

If the <codec> tag of the settings xml file is empty or non-existent, don't encode dicom objects upon storing.

The plugin viewer should be able to display a multi-frame medical image in an animated loop (ultrasound cine loop like) form.

The code should be refactored in order to be possible, upon the store encoding, for the user to define some options for the process, such as:

• which encoder to be used (should override the default option present at the settings xml file from dicoogle);
• --quality or --distance for setting the level of quality loss;
• --effort or --speed for setting the level of speed of encoding / decoding.

And maybe others... but at least these for now.

The jetty plugin should show images even if encoded with the recent formats.

Will be using new/issue5 branch.

I must ensure that the images stored by the plugin don't lose any important features upon storing, using some kind of testing.

Perhaps it is not much viable to formally check encodec-decoded images, but at least losslessly compressed / uncompressed can be checked for equality, and thus, integrity.

Some more development needs to be carried out before being possible to solve this issue. That being said, will refer the issues that need to be solved first.

Right now, the decoding is done by the existing decoders in the user's operating system.

The codestreams in the pixel data of the stored dicom objects should be sent through the servlet response output stream to be decoded by the browser.

This feature should be employed when the following conditions are true:

• The browser supports the format decoding (verification of browser specifications must take place);
• The transfer syntax pertains to the formats covered by imodec.

Keep a lookout for java libraries that provide wrappers or native support for the codecs covered in this project.

TwelveMonkeys are in the process of developing this for JPEG XL and AVIF, where some work is being done at NightMonkeys. TwelveMonkeys already have support for decoding WebP.

The plugin set should have some degree of coverage.

I intend to follow the dicoogle project's approach for unit testing.

As of revision 0bb70e5, while we are still encoding by subprocess, I think the encoding (also perhaps decoding) command provider function is not made in the best way to be scalable regarding the addition of more parameters in the future (e.g.: --progressive option from the cjxl tool).

Thus, I think a refactor should take place for that operation in order to ease future enhancements of the sort.