-
Notifications
You must be signed in to change notification settings - Fork 291
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(color): Fix RGB inconsistencies #829
Changes from 9 commits
0084489
0409f4a
d4739ff
7810290
02b2117
b6c8838
f133ace
c252514
274c609
30304fb
a60d973
bf9a8c2
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,24 @@ | ||
/** | ||
* This function checks color space conversion data requirements before | ||
* apply them. This function was created to solve problems like the one | ||
sedghi marked this conversation as resolved.
Show resolved
Hide resolved
|
||
* discussed in here https://discourse.orthanc-server.org/t/orthanc-convert-ybr-to-rgb-but-does-not-change-metadata/3533/17 | ||
sedghi marked this conversation as resolved.
Show resolved
Hide resolved
|
||
* In this case, Orthanc server convertes the pixel data from YBR to RGB, but maintain | ||
* the photometricInterpretation dicom tag in YBR | ||
* @param imageFrame | ||
* @param RGBA | ||
* @returns | ||
*/ | ||
export default function isColorConversionRequirementsFulfilled( | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @wayfarer3130 Can you please look at this function? Thanks There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I will limit the checks to only YBR_FULL_422 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Limitting the checks to the types ending in _420 or _422 is sufficient, but I would also add an override to allow forcing the issue to return RGB if a flag is set and it starts with YBR - that will then automagically include things like: There are a few other retired PMI values such as HSV and CMYK, but I doubt you will ever see those. |
||
imageFrame, | ||
RGBA | ||
) { | ||
if (imageFrame === undefined) { | ||
return false; | ||
} | ||
const { rows, columns } = imageFrame; | ||
if (imageFrame.photometricInterpretation === 'YBR_FULL_422') { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You can check endsWith 422 or endsWIth 420 to support all the test values we can check. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. as we talked to Bill for ybr_Full_422
-> 3 * ceil(cols/2) + florr(cols/2) * ceil(rows/2) + cols * floor(rows/2) number of ybr y ybr y ybr y elements ybr full 420
for ybr_420 if it is /3 -> convert as RGB There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
That is: Note the parenthesis around the first expression. That breaks down into: |
||
return imageFrame.pixelDataLength === 2 * rows * columns && rows % 2 === 0; | ||
} else { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Add a settable flag allowing coercion to RGB if the response is uncompressed, and the original is YBR of some flavour. That flag could go in cornerstone settings, and maybe be triggered based on the URL prefix (eg url.startsWith), or a regular expression match. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can you please add more to this? I don't understand There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If the photometric interpretation is YBR_FULL_422, BUT the length is 3rowscolumns, then assume it is the configurable value of either RGB or YBR_FULL. That is invalid data, but is common enough that we see it regularly as a "bug" fix request. Then, have the above function return the PMI to use for the given image. const {ForceColorEncoding = WrongLength, UncompressedColorEncoding = RGB} = dataSourceConfiguration; if( pixel length === 3 * rows * columns && pmi ==='YBR_FULL_422 && forceColorEncoding===WrongLength ) { indicating that this image needs decompression handling, in the specified color encoding. |
||
return true; | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add a comment here that the length is divisible by 2 because for 4 pixels (a 2x2 array), there are 4 y and 2 b and 2 r values, so 4+2+2 / 4 = 2 bytes per pixel