Some basics:
CMYK testcharts such as the ECI2002, IT8.7/4, etc. do not have "target" values per se. The charts simply have reference CMYK values....there's no L*a*b* aim values unless you're speaking of a specific "dataset" or "characterization data". For example, GRACoL2006_Coated1 represents a dataset that uses the IT8.7/4 CMYK format.....for each CMYK value, there's an associated L*a*b* value.....but the IT8.7/4 does not have any L*a*b* data associated with it until it's populated with actual measurement data taken from a press, an inkjet printer or some other CMYK device. So, again, testcharts themselves do not have any measuerment data associated with them at all....if they did, they cross over to being referred to as *characterization data*.
IT8.7/2 reflective and transmissive "charts" are different. These represent a physical target (a print or transparency/slide) that have been measured using a spectro and DO have L*a*b* (or XYZ) measurement values associated with each patch....but there's no DEVICE values like in the case of an RGB or CMYK testchart.....we scan or photograph the target to see what device values the camera or scanner produces in response to the L*a*b* measurements of the chart itself.
Or to put it all another way.....
OUTPUT targets like the ECI2002, IT8.7/4, et al........We print/output the specific device values (CMYK in this case) in the testchart file (probably a TIFF or PDF) and then measure the result to see how are device responds to those specific CMYK values.....from that combined data (CMYK+L*a*b*), we can then use it to build an ICC profile of that device. In other words, we have NO IDEA about the L*a*b* of this device until we ask it to print some CMYK values that we give it.....what comes out or prints is measured and then used to create a profile.
INPUT targets like the IT8.7/2 and Hutchcolor HCT targets are just the opposite.....we're actually STARTING with a physical (printed photographically usually) target of known L*a*b* values and then either scanning or photographing it to find out what RGB values the device in question (scanner/camera) produces. From this data (L*a*b* + RGB) we can then build a profile that characterizes this capture device.
For example how they came up with the reference lab value for 100% yellow or red M100% Y100%?
Generally, there is no particular expectation of what 100% Yellow or Red should produce when printed and measured. You print that value, then measure and say "Ah hah! That's what color 100% Yellow is on this device!".
The exception to this is if we're being asked to print to a specific colorimetry such as GRACoL, SWOP or FOGRA xx. Then we already know how 100% Yellow should print...and the reason we know that is probably because someone's already characterized a press to those printing conditions. But for inkjet printers for example, we rarely know...or even care...what a particular CMYK value should measure ahead of time; we're only interested in how it happens to be behaving now so we can profile/characterize it.
I'm sure this does not clear things up 100% but I'll wait for your next question before I go further.....and by the way, this is a very common source of confusion with color management newbies....you'll often here questions such as "I printed my profiling testchart...what should it measure?". Unless you're talking about a specific "standard", the answer is there is no answer! It prints how it prints and that's about it....we then make a profile of the printed result to characterize the device and to use that profile elsewhere in our color-managed workflow. The only thing that matters at this point is that the device prints CONSISTENTLY...if it doesn't, then you'll either need to profile it frequently to chase this variation or find some method to control the device ("calibration") to keep it consistent.
Anway, next question?
Terry
