When reading Implicit Transfer Syntax:
Which VR should the VR Dictionary return, when there are multiple allowed in DICOM part 11? Like in the case of:
(0028,1101) Red Palette Color Lookup Table Descriptor - allowed vrs: US or SS.
Palette Color Lookup Table Descriptor (0028, 1101-1104) Attributes are multi-valued and the first and third values are always interpreted as unsigned. The second value should be interpreted according to Pixel Representation (0028, 0103). In case of Explicit VR Transfer Syntax, value representation (US or SS) should be consistent with Pixel Representation (0028, 0103).
Definition from the DICOM Data Structures and Encoding
Data Elements (0028,1101), (0028,1102),(0028,1103) Red, Green, Blue Palette Lookup
Table Descriptor have the Value Representation SS or US (depending on rules specified
in the IOD in PS 3.3), and shall be encoded in Big Endian. The first and third values are
always interpreted as unsigned, regardless of the Value Representation.
Related
RBG values are 0-255 integers, so why was float4 chosen as the vector data type?
Seems to me that byte would be the ideal data type for a color in Fuse.
RGB values are only 1-byte (0-255) values in some contexts. There are numerous color spaces in common use which use more or less than 1 byte to repesent colors (such as compact 8bit and 16bit colorspaces, or HDR colorspaces using 16 or even 32 bits per channel). These aren't just theoretical uses, when dealing with images and GL textures they are used.
What's important is that each of these represent a range of values, from 0, no intensity, to 1, full intensity, for that channel. This is why float is used: it's the correct semantic type to represent a normalized range. It's also happens to be what OpenGL, the default graphic backend for Fuse, uses to represent colors.
float has the advantage of being a continuous value, unlike a byte which has discrete increments. This is important for interpolation. Consider animation between two colors, having a linear gradient, changing the opacity, or decreasing saturation; all of these need to be done on a continuous value range, such as float.
float also allows values to go about 1, and below 0. While these cannot be reflected in the final display they play a role during calculations. If you're doing many color operations in sequence you don't want to prematurely clamp your values.
Don't worry about things like memory bandwidth or storage space. Actual stored color values are a miniscule fraction of what occupies memory.
Also, the common hex syntaxes for color notation are supported in Fuse. You can use a simple #FAA for a light red, or #AB74FD80 for a more precise half-transparent color.
First I'm going to assume that by float you mean a 4-byte value.
Four floats take up 4 times as much memory. This is important not just for the space but the amount of time it takes to move the memory around since memory bandwidth is limited.
You can't use bit mask operators and shift on floats (well, you can, but it's not common).
Most display tech is limited to 16M colors, which is 24-bit RGB. Even if you have a 12-bit or 16-bit/channel display tech, floats still take at least twice as much memory.
Not all platforms even have native support for floating point operations.
I could probably keep going but you get the idea.
I'm working with DICOM CT images to segment bones. I was wondering if I can use DICOM attribute information to determine the range of bone pixel values.
You should never rely on Type 3 attributes. In your specific case (CT) it is just as trivial as reading the Rescale Slope and Rescale Intercept. Those attributes allow to transform the pixel values to HU or other units, as specified in the attribute Rescale Type.
For CT images, the unit should be HU (Hounsfield). So after the transformation you can then lookup the well know values for bones:
http://en.wikipedia.org/wiki/Hounsfield_scale#The_HU_of_common_substances
Chapter 3, Annex A.3 of the DICOM standard [1] specifies the IOD for the CT dataset. It consists, among others, of the Image Pixel Module (C.7.6.3). The Pixel Module has two attributes "Smallest Image Pixel Value" (0028,0106) and "Largest Image Pixel Value" (0028,0107). However, these are Type 3 attributes and might not be present in your dataset.
[1] http://medical.nema.org/medical/dicom/current/output/pdf/part03.pdf
In some programming languages, colors are represented by hexadecimal values. For example, using CSS, to change the text color of a header to maroon-ish, you could type:
h1 {
color: #8B1C62;
}
I'm wondering what the reason is for using a base-16 numeral system to represent colors. You could hypothetically use any numeral system to represent the same values, no?
When did this convention start? Does anybody know where I can read about the history of this phenomenon?
The primary use of hexadecimal notation is a human-friendly representation of binary-coded values in computing and digital electronics.
each hexadecimal digit represent 4 bits. half the byte.
a byte value can be in range of 0 to 255 in decimal but it is more easier to read it as 2 Hexadecimal digit from 00 to FF.
a 6 digit color code hold 256X256X256 combination of red, green and blue ! (8-Bit RGB)
read more about color, color spaces and hexadecimal :
http://www.smashingmagazine.com/2012/10/04/the-code-side-of-color/
http://en.wikipedia.org/wiki/Hexadecimal
http://en.wikipedia.org/wiki/RGB_color_model
You can certainly represent colors in any numeral system. Here's what your maroon-ish color looks like in various different systems:
Binary: 10001011 00011100 01100010
8 bits each for red, green, and blue. That's nice, but who wants to type all those numbers?
Decimal: 9116770
Fewer numbers to type, but how do you manipulate R, G, and B individually? And it feels kind of weird to refer to a color as nine million, one hundred sixteen thousand, seven hundred seventy.
Hexadecimal: 8B 1C 62
Even fewer numbers to type, and we can manipulate R, G, and B easily. Seems like a good candidate for representing colors, but let's try one more.
Base-256: ï [^\] b
Nice: we only have to type one character per color component. But I can never remember what number comes after ï or before the file separator control code, so I'd have to whip out the ASCII table every time I write or read a color. But what if we wrote the components in decimal instead?
Base-256, redux: 139,28,98
Much nicer. Not too many characters to type, and it's very clear which numbers represent R, G, and B.
Thus...
The two common ways to represent color values are hexadecimal and base-256-ish, because... it's easy!
This is related to CSS color codes:
For hexcode we can represent 16,777,216 colors from #000000 to #FFFFFF
According to W3C Specs, Valid RGB percentages fit in a range from (0.0% to 100.0%) essentially giving you 1,003,003,001 color combinations. (1001^3)
According to the specs:
Values outside the device gamut should be clipped or mapped into the gamut when the gamut is
known: the red, green, and blue values must be changed to fall within the range supported by
the device. Users agents may perform higher quality mapping of colors from one gamut to
another. For a typical CRT monitor, whose device gamut is the same as sRGB, the four rules
below are equivalent:
I'm doubtful if browsers actually can render all these values. (but if they do please tell me and ignore the rest of this post)
Im assuming there's some mapping from rgb(percentage) to hex. (but again Im not really sure how this works)
Ideally I'd like to find out the function rgb(percentage)->HEX
If I had to guess it would probably be one of these 3.
1) Round to the nearest HEX
2) CEIL to the nearest HEX
3) FLOOR to the nearest HEX
Problem is I need to be accurate on the mapping and I have no idea where to search.
There's no way my eyes can differentiate color at that level, but maybe there's some clever way to test each of these 3.
It might also be browser dependent. Can this be tested?
EDIT:
Firefox seems to round from empirical testing.
EDIT:
I'm looking through Firefox's source code right now,
nsColor.h
// A color is a 32 bit unsigned integer with four components: R, G, B
// and A.
typedef PRUint32 nscolor;
It seems Fiefox only has room for 255 values for each R,G and B. Hinting that rounding might be the answer, but maybe somethings being done with the alpha channel.
I think I found a solution for Firefox anyways, thought you might like a follow up:
Looking through the source code I found a file:
nsCSSParser.cpp
For each rgb percentages it does the following:
It takes the percentage component multiplies it by 255.0f
Stores it in a float
Passes it into a function NSToIntRound
The result of NSToIntRound is stored into an 8 bit integer datatype,
before it is combined with the other 2 components and an alpha
channel
Looking for more detail on NSToIntRound:
nsCoord.h
inline PRInt32 NSToIntRound(float aValue)
{
return NS_lroundf(aValue);
}
NSToIntRound is a wrapper function for NS_lroundf
nsMathUtils.h
inline NS_HIDDEN_(PRInt32) NS_lroundf(float x)
{
return x >= 0.0f ? PRInt32(x + 0.5f) : PRInt32(x - 0.5f);
}
This function is actually very clever, took me a while to decipher (I don't really have a good C++ background).
Assuming x is positive
It adds 0.5f to x and then casts to an integer
If the fractional part of x was less than 0.5, adding 0.5 won't change the integer and the fractional part is truncated,
Otherwise the integer value is bumped by 1 and the fractional part is truncated.
So each component's percentage is first multiplied by 255.0f
Then Rounded and cast into a 32bit Integer
And then Cast again into an 8 bit Integer
I agree with most of you that say this appears to be a browser dependent issue, so I will do some further research on other browsers.
Thanks a bunch!
According to W3C Specs, Valid RGB percentages fit in a range from (0.0% to 100.0%) essentially giving you 1,003,003,001 color combinations. (1001^3)
No, more than that, because the precision is not limited to one decimal place. For example, this is valid syntax:
rgb(23.456% 78.90123456% 0%)
The reason for this is that, while 8 bits per component is common (hence hex codes) newer hardware supports 10 or 12 bits per component; and wider gamut colorspaces need more bits to avoid banding.
This bit-depth agnosticism is also why newer CSS color specifications use a 0 to 1 float range.
Having said which, the CSS Object Model still requires color values to be serialized at 8 bits per component. This is going to change, but the higher-precision replacement is still being discussed in the CSS working group. So for now, browsers don't let you get more than 8 bits per component of precision.
If you are converting a float or percentage form to hex (or to 0 - 255 integer) the correct method is rounding. Floor or ceiling will not spec the values evenly at the top or bottom of the range.
The CSS3 spec only specifies that:
The format of an HSLA color value in the functional notation is ‘hsla(’ followed by the hue in degrees, saturation and lightness as a percentage, and an , followed by ‘)’.
So am I to understand that these values would be interpreted not as integers but as floats? Example:
hsla(200.2, 90.5%, 10.2%, .2)
That would dramatically expand the otherwise small (relative to RGB) range of colors covered by HSL.
It seems to render fine in Chrome, though I don't know if they simply parse it as an INT value or what.
HSL values are converted to hexadecimal RGB values before they are handed off to the system. It's up to the device to clip any resulting RGB value that is outside the "device gamut" - the range of colors that can be displayed - to a displayable value. RGB values are denoted in Hexadecimal. This is the specified algorithm for browsers to convert HSL values to RGB values. Rounding behavior is not specified by the standard - and there are multiple ways of doing rounding since there doesn't appear to be a built-in rounding function in either C or C++.
HOW TO RETURN hsl.to.rgb(h, s, l):
SELECT:
l<=0.5: PUT l*(s+1) IN m2
ELSE: PUT l+s-l*s IN m2
PUT l*2-m2 IN m1
PUT hue.to.rgb(m1, m2, h+1/3) IN r
PUT hue.to.rgb(m1, m2, h ) IN g
PUT hue.to.rgb(m1, m2, h-1/3) IN b
RETURN (r, g, b)
From the proposed recommendation
In other words, you should be able to represent the exact same range of colors in HSLA as you can represent in RGB using fractional values for HSLA.
AFAIK, every browser casts them to INTs. Maybe. If I'm wrong you won't be able to tell the difference anyway. If it really matters, why not just go take screenshots an open them in photoshop or use an on-screen color meter. Nobody here is going to have a definitive answer without testing it, and it takes 2 minutes to test... so...
I wouldn't know exactly, but it makes sense to just put in some floating numbers and see if it works? it takes two seconds to try with a decimal, and without..