Developer Implementation Guide

dt encourages any interested software vendor to incorporate support of the dt nexus transmissive targets into their software, for evaluation of color quality or the creation of new color profiles (or both) this chapter provides technical information for software developers that wish to implement such support we strongly suggest reading the entire document prior to starting your work, as we flag most of the common issues you might otherwise run into if any questions arise, dt is glad to actively support such developers at no cost please https //heritage digitaltransitions com/contact us/ user interface the canonical name for these two targets can be found https //docs google com/spreadsheets/d/1 xqxr5rhknijvbeh7qfkvvhjc 3tgco4fmb9v7chbp0/edit?gid=0#gid=0 dt nexus transmissive profiling target or dt ntpt for short dt nexus transmissive validation target or dt ntvt for short measurement files (aka reference files) to use these targets to evaluate color quality or create a new color profile requires knowing the precise actual color of each patch every dt ntpt is individually measured using a nist traceable lab grade spectroradiometer those serial number specific measurements are provided via the docid\ chkwooxvm5rosnvrnevrx in the form of the qr code in the top corner of each target for example here are oqm ( docid\ rldb9v83zhs2ka uk0hhb which is a flavor of, and compatible with cgats) for the serial numbers tp24010 and tv24017 – these are the links that you would find in the qr code in the top right of those two targets https //targets digitaltransitions com/measurements?manufacturer=dt\&targettype=dtntpt\&targetid=tp24010 https //nexus digitaltransitions com/api/v1/measurements?manufacturer=dt\&targettype=dtntvt\&targetid=tv24017 for easy reference the zip below contains the files that were retrieved at these links feb 14, 2025 processing target identification the outer border is opaque metal so if properly masked (if surrounded by dark or opaque material to prevent light spilling around the edges and causing flare) the outer edge of the target may not be distinguishable from the rest of the capture the patch area is 4 35x3 35" (110 5x85 1 mm) including the 0 05" (1 3mm) margin around the patch area before the metal border sample area there can be very slight interaction between the mask and the patch also, the shape of the circle can vary slightly from patch to patch for these reasons we suggest using a circular sample area between \[half the diameter of the circle] and \[three quarters the diameter of the circle], centered on the detected patch area median or iqr mean patches have a slight texture, and a given target capture is likely to have meaningful dust, hair, scratches or other imperfections we suggest using a median or iqr mean rather than a naive total pixel average of the patch black point note that the opaque "patch" at a9 is useful as a flare check, either to flag excessive flare to the user in order to advise them not to proceed with a profile (but instead to correct the flare by cleaning their lens, better masking the target in the capture area, or using a higher quality capture system), or to offset the flare in the math of the profile orientation the intended orientation of the target is with the qr code in the top right and the serial number text right reading and below the qr code this is the orientation which matches the patch order of the measurement file however, it is expected that a user can place the target in any of the four cardinal directions and ideally your software should support detection or manual marque of the target in any orientation because the target is transparent and transmissive scanning is often done in dark environments it is plausible the target might be placed top side down such that the patch arrangement would be mirrored; this is not a supported orientation distinguishing between the dtntpt and dtntvt targets both targets share the same physical form factor and are only distinguished physically by the colors of the patches, the encoded content of the qr code of the openqualia label, the serial number (starting tv or tp ) printed under the qr code, and the text on the metal border the text on the metal border is typically not visible (or is very very dark) in a standard transmissive capture (since no meaningful light should be reaching the top of the target) so using the qr code or the color pattern of the patches are the obvious ways to distinguish between the two targets in an automated manner odds and ends to remember 0 index row labels the target patch names start at row 0 that is, the first row is row 0 and the second row is row 1 this was done for two reasons to comport with pythonic defaults of 0 indexed lists, and to keep the ten row design a single digit long some code libraries will mishandle this, either skipping row 0 , or placing it after row 9 no "patch m 0" on both targets there is no top right patch in the position that would otherwise be m 0 this is reserved for the openqualia label (qr code) some code libraries will mishandle this, either placing a white or black patch in that location in the absence of a patch value definition or place a 1 (second row first column) immediately at the end of the first row (row 0 ) black a9 (nt ntpt) on the profiling target the bottom left "patch" is totally opaque and therefore has no circular shape to detect if you base your code on detecting circles make sure the bottom left of the dt ntpt is excluded in addition to excluding the top right (what would be m 0 ) where the qr code is dashed patch names the target patch names use a dash between the letter based column and the digit based row some implementations would errantly read this as indicating a negative value; that is they would read b 3 as column b row 3 row major vs column major some libraries assume row major order and others assume column major order ideally you should implement patch name parsing so as to place patches by their explicit position rather than assuming the patch order having the docid\ won92qlqm8806a1nkqxac open during implementation coding can be helpful as a quick reminder of the layout and as a sanity check for loading the spectral data against all of the above potential issues example files you can test your development using these https //drive google com/open?id=1noxonlsd6sh 9w8rifnhwwcglrgvcq0 \&usp=drive fs please contact us if you need more or different files for testing