Analyses & Output – INI settings – Chart Definition Files – Chart Definition Utility – Video Analysis
Introduction
Before Imatest’s Arbitrary Charts module can analyze an image of a test chart (possibly of your own design), it needs to know exactly what the chart’s design is.
This requires information about the chart’s features (the elements present on the chart that aren’t just its background color; e.g., color patches, slanted squares, registration marks, etc). The information required includes both layout parameters so features can be located correctly and the regions of interest (ROIs) generated from them; reference-value information about the features in some cases, such as the true LAB or RGB value of a color patch, is also required information.
Chart definitions come in the form of JSON-formatted text files, which describe the properties of the chart and its features. These files can be created by hand or by a user-defined automated process if you are so inclined to create one.
In our experience so far, the process has been as follows:
- Design a chart comprised of the allowed features in a graphics editing program, such as Inkscape or Adobe Illustrator.
- Measure or record the positions and sizes of all the features and convert them to normalized units (see below) as well as the other reference values (color values, etc).
- Create a JSON file by hand with the required fields describing the chart, as described below.
The Chart Definition Utility can aid in this process by checking user JSON files for correctness, displaying an illustration of the chart defined by a JSON, and displaying sample ROI from a real image of the chart.
Example JSON files
If you have installed Imatest 5.0 or newer, you already have some example chart definition files installed on your system. These can be found in the chart_design subdirectory the Resources Directory installed in the same location as the default Imatest INI folder.
The easiest way to find this folder location on your system is to select the “Open INI file folder” entry in the File drop-down of the main Imatest window.
JSON Setup
To analyze a chart, Imatest needs to have a definition of that chart. The following describes the necessary information that Imatest needs to analyze observed images of that chart.
Arbitrary Charts are defined as follows:
- A rectangular field with normalized (x,y) coordinates from 0-1.
- The origin in the upper left (“image style”).
- A defined background color.
- An identifying name (e.g., “SFR Plus 5×7”).
- A set of features to be analyzed from the set below.
JSON definition files require a field that defines each chart property, such as background color, encoding, and aspect ratio. The field also defines an array of features drawn on the chart. Each chart feature is listed as a JSON object, with its own set of required fields to define its properties. Below is an illustration of the correct JSON structure:
JSON Structure
General Chart Properties
- The entire width and height of an Arbitrary Chart is interpreted as the background area for uniformity analysis that excludes areas designated as features or keep-out areas.
- All fields are required unless marked explicitly as “(Optional)”. Additional fields may be included in feature definitions, but will be ignored.
- For JSON number types, decimals with values less than one must have a leading zero e.g., 0.25, not .25.
Field Name |
JSON Value Type | Description |
bgEncoding | string | Valid encoding type string |
bgValue | array of numbers | Valid encoding value depending on “encoding” field entry |
name | string | Name of the chart e.g., “SFRplus_5x7” Note: Chart names must consist only of alphanumeric characters or underscores, (no spaces) as they will serve as a basis for results file names. |
aspectRatio | number | The overall width divided by the overall height, e.g., 1.750. *Note, this number is unit-less. |
Features
After the background area has been defined, features can be placed on the chart. The Test Charts Module can be used to generate chart features. The following is a set of allowed features that can be analyzed by Arbitrary Charts.
Shared Feature Properties
- Each feature type has its own set of indices, which must start with a value of 1.
- The rotation of each feature is assumed applied to the feature after it is placed and sized.
- The following properties are shared among all Arbitrary feature types:
Field Name |
JSON Value Type | Description |
featureType | string | Indicates the type of feature; e.g., “SlantedSquareFeature” |
center | array of 2 numbers | Position of the center of the feature [x,y] in normalized coordinates |
ind | number | Integer identifying index of feature. *Note, the index starts at 1 for each family of features |
height | number | Height ranging from 0-1 of normalized y-dimension |
width | number | Width ranging from 0-1 of normalized x-dimension |
rotation | number | (Optional) Rotation in degrees – clockwise |
“SlantedSquareFeature”
Field Name | JSON Value Type | Description |
featureType | string | “SlantedSquareFeature” |
encoding | string | Valid encoding type string |
value | array of numbers | Valid encoding value depending on “encoding” field entry |
“SlantedEdgeFeature”
Field Name | JSON Value Type | Description |
featureType | string | “SlantedEdgeFeature” |
encoding | string | Valid encoding type string |
darkValue | array of numbers | Valid encoding value depending on “encoding” field entry |
lightValue | array of numbers | Valid encoding value depending on “encoding” field entry |
slantAngle | number | Slant in degrees—clockwise from horizontal |
“RegMarkFeature”
Note: Registration marks on the corners of cross-correlation texture patterns count as part of part of the RandomFieldFeature, not registration marks. They should not have separate entries or count toward the indices of RegMarkFeatures.
Field Name | JSON Value Type | Description |
featureType | string | “RegMarkFeature” |
“CircleFeature”
Introduced in Imatest 5.1.
Note: CircleFeatures are used for chart registration for legacy targets and used only for registration (they are not analyzed for results). Use of RegMarkFeatures instead is recommended when possible. CircleFeatures are assumed black, on top of a lighter background.
Field Name | JSON Value Type | Description |
featureType | string | “CircleFeature” |
“ColorPatchFeature”
Note: When the optional “useForNoisePSD” is marked true, the noise Power Spectral Density (PSD) is calculated for texture-direct analysis. Typically, a neutral gray color patch of 18% reflectivity would be used for this purpose. Otherwise, this can be left as false by default.
Field Name | JSON Value Type | Description |
featureType | string | “ColorPatchFeature” |
encoding | string | Valid encoding type string |
value | array of numbers | Valid encoding value depending on “encoding” field entry |
useForNoisePSD | boolean | (Optional) Flag to indicate use for noise PSD subtraction for direct e.g., true, false |
“RandomFieldFeature”
Notes:
- Registration marks on the corners of cross-correlation texture patterns count as part of the RandomFieldFeature, not registration marks. They should not have separate entries or count toward the indices of RegMarkFeatures. The Test Charts Module can be used to generate random patterns.
- In order for a Random Direct analysis to be performed, one grayscale color patch in the chart definition needs to be identified for calculation of the noise power spectral density (PSD) for subtraction from the random signal PSD, which can be done with the “useForNoisePSD” field.
Field Name | JSON Value Type | Description |
featureType | string | “RandomFieldFeature” |
randomType | string | Random field design e.g., “Direct_gray”, “Direct_color”, “Cross_gray”, “Cross_color”, “DXO_direct_gray”, “IE_cross_color” |
“StarFeature”
JSON Value Type | Description | |
featureType | string | “StarFeature” |
centerMarkFraction | number | Central registration mark diameter as a portion of the whole Star Feature’s diameter. Must be greater than zero and less than 1 |
Notes:
- Imatest 5.2 supports sinusoidal star patterns only, not “bar star” patterns.
- The definition of the Star only indicates the “active region” of the star which is the center mark and sinusoidal pattern, not any outer “rind” portion.
- Only Star patterns with a registration mark at the center are supported. The width of this mark relative to the whole Star width is to be indicated by the centerMarkFraction value.
- No other features (such as grayscale OECF patches) are considered part of this feature.
- The registration mark in the center of the Star pattern counts as part of the StarFeature, not the set of RegistrationMark features. It should not have separate entries or count towards the indices of RegMarkFeatures.
“WedgeFeature”
Field Name | JSON Value Type | Description |
featureType | string | “WedgeFeature” |
Notes:
- The natural orientation of the wedge is as shown above: horizontal with the wide end on the left. Keep this in mind when defining the WedgeFeatures in your ChartDesign in other orientations. For example, a vertically oriented wedge with the wide end pointed down would require a 270-degree rotation.
- At this time it is not necessary to define the number of bars in the wedge or end points’ line widths per chart height.
“KeepoutArea”
Field Name | JSON Value Type | Description |
featureType | string | “KeepoutArea” |
Notes: Keep-out areas are regions of the chart where there may be other graphical features that aren’t defined for analysis by other chart features on this page, but need to be known by the system to avoid incorrectly using the area for uniformity analysis from the background area. This includes graphics, text, framing markers, etc. that should not be included in uniformity analysis. The center, width, and height of keep-out areas are defined like any other Arbitrary Charts feature.
Keep-out areas can overlap with other defined chart features with no negative consequence.
Notes
Chart Registration Points
Arbitrary Charts module requires at least three (preferably four) points of registration to be able to align a chart design in an image of the chart. They can come from any mix of the following:
- RegMarkFeatures contribute one registration point.
- CircleFeatures contribute one registration point.
- RandomFieldFeatures may contribute two or four (or zero) registration points, depending on the type.
Color Encodings
Many chart features require entry of color values in their definitions, including ColorPatchFeatures, SlantedSquareFeatures, and the chart background itself.
Reference color values can be indicated by the combination of a value (usually a 3-long vector of numbers) and a string which indicates an encoding which defines how to interpret the numbers. The following table indicates the allowed encoding types and what their associated value entries must be.
Encoding | “encoding” string | Values description |
---|---|---|
Standard RGB color spaces | “srgb”, “adobe_rgb” | Entry should be a 3-long numeric array of [r, g, b] values, scaled as a standard 8-bit representation of these color spaces (i.e., range [0, 255] values, gamma encoded). |
CIELAB | “lab” | Entry should be a 3-long numeric array of [L*, a*, b*] values (D50 white point). The L* value must be constrained to the range [0, 100]. |
Intensity values | “density”, “intensity”, “intensity_8bit”, “intensity_16bit” | Intensity values relative to a maximum of 1 after normalization. “intensity” input values are already normalized, and should be in range [0, 1]. “intensity_8bit” and “intensity_16bit” normalize based on a maximum of 255 and 2^16-1, respectively. “density” values are exponent values of the scheme 10^(-density). All value entries should be a single numeric value. |
Comments
Unfortunately, JSON files do not allow you to have comments in the file that are ignored by the parser. If you are writing a JSON file and want to leave a comment documenting something for future users, you cannot do so by simply including escape characters (such as “%” or “//”) that are often found in most programming languages.
However, if you need to comment your JSON file, you are free to add extra fields to any object in the file, for example with the name “comment” and a string value. Only required fields in a chart definition are checked for by Imatest—any extra fields are ignored.
Design & Printing
In most cases, chart-definitions are tied to both layout and media. After an Arbitrary Chart has been designed as a vector graphic (typically in Inkscape or Adobe Illustrator), the specific substrate and print medium needs to be considered (e.g, reflective and transmissive media will need two different .jsons, because the values of the color patches will be different). The Test Charts Module can be used to generate some vector graphics which can be used to compose a custom chart.
As with all test charts, it is important to consider your imaging distance and minimum print resolution. Imatest offers professional printing services in a wide variety of substrates and sizes. For specific queries about creating a custom chart design, please contact support@imatest.com. We also offer consulting services for creating chart definition files, if required.