Conversation
- New command mrcolour, for applying a colour map to an image without invoking mrview: - Import additional test data, and add tests. - Support reading and writing of PNG images through standard image I/O: - Greyscale, greyscale + alpha, RGB, and RGBA are supported (handled as up to four volumes in a 4D image). - Square-bracket notation is supported, which will treat each individual PNG file as a slice (i.e. axis 2). - If the size along axis 2 is greater than 1 and square-bracket notation is not used, but either axis 0 or 1 has size 1, automatically configure so that the single output file will write that slice. - Support is only included if libpng is detected during configure script. - Include a couple of simple CI tests via mrconvert. - Fix 'gray' colourmap C++ function not clamping amplitudes. - Fix min_max() algorithm issuing compilation warning due to ignoring input arguments.
Closed
Member
Author
|
Quick demonstration of how this might be used for e.g. QA compilations:
|
Conflicts: testing/data testing/tests/mrconvert
It appears as though environment variable PNG_Z_DEFAULT_COMPRESSION is not defined in all libraries; make use of Z_DEFAULT_COMPRESSION instead.
- Issue info-level notice about the intensity scaling used when writing floating-point data to PNG; while automiatically scaling to fit the minimum & maximum intensities of the image data into the output integer representation may be possible, it would not be ideal from the perspective of generating output images of quantitative data, and the former can be achieved through explicit scaling. - Prevent warnings regarding voxel sizes and transforms as much as possible. - When reading image data using [] notation, identify any image axis with unity size, and concatenate data along that axis, only performing concatenation along a new additional dimension if no such axis exists; this was working previously, but in merging PNG support development with changes in 'dev' branch related to [] notation handling, reading of stacks of RGB images was no longer working.
Due to changing in e165a01 code relevant to the identification of appropriate axes along which to concatenate multiple input images, the order of loops when there are multiple present was erroneously reversed.
Conflicts: docs/reference/commands_list.rst
While this discrepancy typically arises due to generation of documentation on a Windows machine, in this case both the source and the CI machine are Linux, suggesting that the behaviour of the Unix sort command itself may have changed in an update.
Lestropie
added a commit
that referenced
this pull request
Sep 19, 2019
Support for PNG images was added in #1541, and support for that particular image handler will only be added during compilation if the relevant environment variable is set by the configure script. However instructions to install the relevant library package in order to enable this functionality had not yet been added.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Even though it's not strictly necessary for RC4, I was not far from finishing it off, so we'll see if we can get it included, and I can hopefully get
libpngout of my head to go focus on other requirements.I regularly use a clumsy > 5-year-old command for exporting slice data directly to 2D image file in my own figure generation. The approach implemented here makes it far more convenient, supports numbered multi-file, and particularly when combined with
mrcolourmeans that e.g. quantitative images generated during the course of an experiment can be exported with choice of applied colour map & intensity scaling directly to PNG file(s) at the native resolution of the underlying image; even if ssh'ing to computing hardware.The included PNG CI tests are only simple, but I have tested read & write of PngSuite, and the only differences are the variable gamma images. Though obviously these test data are all only 2D (plus colour channels).
There are some peculiarities that may necessitate some documentation... I don't have a proper sense of how intuitive these might be for others to figure out. Independent testing welcomed.
Some more details in commit message of 5afcfc2.
Closes #4.
While this could be used to justify closing #8 based on its title, there may nevertheless still be merit in pursuing what's described in the description of that issue, i.e. implementing format & I/O handling to be able to interpret matrix data in text files as images.
Maybe one day this will also contribute toward some kind of image summary compilation QA akin to FSL's
slicesdir, which has been raised on the forum a couple of times but doesn't yet have its own issue listing on GitHub.