Paint It Black!

Do they have a disallow-list of certain RGB/CYMK values that are "forbidden" from now on, or what ???

Yes, I understand that "Pantone" is more about certain standardized palettes of colors. But, ultimately, you pick an RGB (or CYMK) value.

From reading the article, I think this is incorrect. If I had to guess the implementation, there's probably a separate top layer in an indexed color space that specifies colors such as

0 = no color (use the result of the previous layers)
1 = black
2 = red 1
3 = shiny silver
4 = yellow 37
5 = hologram
etc.

Then when you send the file to the printer (or "RIP", whatever that is) the device has to decide whether to use a CMYK value or a Pantone value, and if it uses the latter it may translate it to a CMYK value and use the normal ink in a particular mixture (possibly in a proportion that can't be specified in CMYK given its bit depth), or it may apply it using a special method.

So in other words, it's not that PS now has forbidden RGB triplets that it replaces with (0, 0, 0), it's that it's displaying that Pantone layer as black, and if you try to print it, instead of sending the data as it exists on the disk, it filters it through a function like

1
2
3

Pantone turn_black(Pantone x){
    return x == Pantone::Transparent ? x : Pantone::Black;
}

and sends the result to the printer. I would assume it does nothing to the data on the disk.

Any image (BMP, JPEG, PNG, etc) or video (e.g. H.264) format that I ever worked with encodes "color" information as RGB or CYMK value. Sometimes RGB values are transformed into YCbCr, because it allows better compression (separation of "luma" and "chrome" information), but that's really just a different way of representing the RGB value; it can be transformed back and forth as needed.

Also, when "index colors" are used, the index is really just the index (row) of the color table. And, in that color table, the available colors are again stored as RGB values. So, something like color index #3 is really just a shorthand for, e.g., #C0C0C0 or rgb(192,192,192).

And it makes no different whether the color code #C0C0C0 was taken from some fancy "color book", or whether they call it "shiny silver", or whatever. In the end it's the same darn color that I can select from my stupid standard color picker in MSPaint 😏

For example:
https://www.w3schools.com/colors/colors_names.asp

Last edited on

Your confusion is in thinking that the palette index needs to be converted into a different color space in order to be used. If you're displaying it on the screen, sure, because the screen only works in RGB, so the only type of visual information you can display with it must be in the RGB color space. But a printer isn't limited to just using the standard CMYK colors. It can have any number of additional channels that software can potentially request, if it knows how to do it.

When I said "shiny silver" I wasn't referring to a combination of CMYK that looks silverish (so sort of gray). I was talking about a hypothetical pigment and process that when finished gives the paper a silverish shine. Like, imagine you're printing a picture of a cyborg and apply that "color" to the metal bits such that when you put the paper against the light it actually looks shiny like metal. You could not encode the instructions to do that with CMYK in any way, because CMYK just deals with subtractive pigments.

Or as a more likely example, imagine that you're printing an ad for lipstick and you want the lips to look intensely red, and using CMYK you notice that when you get really close up you can see the individual magenta and yellow dots that make up the color. Then you could use a Pantone color and your printer could interpret it to use the special Pantone Red ink for those pixels. Again, you could not encode these instruction for the printer using just CMYK, because the printer could not distinguish between the situations where you're actually printing CMYK red or pure red.

kigar64551 wrote:
So, it appears that in all Adobe products (PhotoShop, Illustrator, etc. pp.) certain so-called "Pantone" colors will be replaced by black from now on, even in existing files as old as 20 years — unless you pay an extra fee of $21 per month:

Adobe uses Pantone asserts that are IP of Pantone LLC and are required to pay royalties to use them. All Adobe are doing is giving you a way to pay less if you don't need Pantone in your workflow.

Your confusion is in thinking that the palette index needs to be converted into a different color space in order to be used. If you're displaying it on the screen, sure, because the screen only works in RGB, so the only type of visual information you can display with it must be in the RGB color space. But a printer isn't limited to just using the standard CMYK colors. It can have any number of additional channels that software can potentially request, if it knows how to do it.

When I said "shiny silver" I wasn't referring to a combination of CMYK that looks silverish (so sort of gray). I was talking about a hypothetical pigment and process that when finished gives the paper a silverish shine. Like, imagine you're printing a picture of a cyborg and apply that "color" to the metal bits such that when you put the paper against the light it actually looks shiny like metal. You could not encode the instructions to do that with CMYK in any way, because CMYK just deals with subtractive pigments.

Or as a more likely example, imagine that you're printing an ad for lipstick and you want the lips to look intensely red, and using CMYK you notice that when you get really close up you can see the individual magenta and yellow dots that make up the color. Then you could use a Pantone color and your printer could interpret it to use the special Pantone Red ink for those pixels. Again, you could not encode these instruction for the printer using just CMYK, because the printer could not distinguish between the situations where you're actually printing CMYK red or pure red.

In an image file, such as BMP, JPEG or PNG, colors are encoded as RGB triplet. Or, equivalently, as YCbCr triplet. At least TIFF files also support storing colors encoded as CMYK quadruple. Now, Indexed colors do not really change anything about this, except that we store an index into a table where the actual RGB (or CMYK) value is stored, rather than storing the RGB (or CMYK) value directly. This is simply a way of saving disk-space, for images that only need a small number of different colors. GIF files are an example of this.

Yes, the printer (driver) will need to figure out how a certain color value, which is to be printed, can be "recreated" from the available inks. In other words, the printer "translates" the given color value, usually encoded as RGB triplet, into a mixture (halftoning pattern) of the available inks. Normal printers, for consumers, only have Cyan, Magenta, Yellow and Black ink. Maybe some special printers have dedicated "shiny silver" or "intensely red" inks to better recreate those very specific colors. But that's all "internal" details of the printer.

The image file still only stores RGB/YCbCr or CMYK encoded color values. There is no way to know whether a specific color value that appears in your image file was taken form a fancy "Pantone" color book, or whether it came from an Average Joe's color picker, or whether it was chosen totally at random. A color value is a color value; it has no "passport" to prove its ancestry — unless Adobe stores some "meta information" in its own file formats, which records how exactly the color of each pixel in the image was picked by the user 🤣🤣🤣

Adobe uses Pantone asserts that are IP of Pantone LLC and are required to pay royalties to use them. All Adobe are doing is giving you a way to pay less if you don't need Pantone in your workflow.

No. If your image file contains certain colors, then those will now be replaced by black in Adobe's products — unless you pay an extra monthly fee to "unlock" those colors! Until very recently, those colors would show up normally in Adobe's products, without an extra fee. Of course, any other Photo editor on the planet (TTBOMK) also does not require users to pay extra money, just to "see" certain colors.

That is a form of blackmailing - no pun intended 🤣🤣🤣

Last edited on

https://ownersmag.com/adobe-drops-pantone/

Pantone official Marcie Foster responded and said Adobe and Pantone have been and will continue to be long-standing business partners.

But, the current implementation of the Pantone color system with Adobe’s Creative Cloud products is outdated, with many missing colors and inaccurate information. The two companies have decided to remove the obsolete libraries and continue to work together on better in-app features.
...

Bill Greenwood told Printweek that Pantone creates an Adobe Extension known as Pantone Connect, allowing users to access the Pantone libraries. I hope that Adobe integrates the Pantone Connect extension automatically. Otherwise, users can download it from another site (exchange.adobe.com).

Now, Indexed colors do not really change anything about this, except that we store an index into a table where the actual RGB (or CMYK) value is stored, rather than storing the RGB (or CMYK) value directly. This is simply a way of saving disk-space, for images that only need a small number of different colors.

There are in fact color spaces that are neither RGB nor CMYK nor luma-derived. Scientific images for example frequently contain data outside the visible spectrum. Given this, I think it's easy to conceive of a palette that's irreducible to RGB values.

But that's all "internal" details of the printer.

Unfounded assumption. Have you looked at the drivers of professional publishing printers in order to make this assertion?

The image file still only stores RGB/YCbCr or CMYK encoded color values.

Pantone is a separate color space that's not necessarily translatable to any of those.

The image file still only stores RGB/YCbCr or CMYK encoded color values. There is no way to know whether a specific color value that appears in your image file was taken form a fancy "Pantone" color book, or whether it came from an Average Joe's color picker, or whether it was chosen totally at random. A color value is a color value; it has no "passport" to prove its ancestry — unless Adobe stores some "meta information" in its own file formats, which records how exactly the color of each pixel in the image was picked by the user 🤣🤣🤣

No. You are wrong. I can easily show how it can be done:

class Pixel{};

class RgbPixel : Pixel{
    byte r, g, b;
};

class PantonePixel : Pixel{
    enum Value{
        Black, //equivalent to RGB(0,0,0)
        Red, //equivalent to RGB(255,0,0)
        ArbitraryColor1, //No RGB equivalent
        ArbitraryColor2, //No RGB equivalent
        Yellow37, //equivalent to RGB(255,237,0)
        //...
    };
    Value value;
}

Pixel bitmap[256*256];
bitmap[0] = RgbPixel(255, 0, 0);
bitmap[1] = PantonePixel(PantonePixel.Value.ArbitraryColor1);
//...

Pixel bitmap_to_print[256*256];
if (paying_for_pantone)
    //note that bitmap stays untouched
    bitmap_to_print[i] = bitmap[i] is PantonePixel ? RgbPixel(0, 0, 0) : bitmap[i]
else
    bitmap_to_print = bitmap;
printer.print(bitmap_to_print);
screen.display(bitmap_to_print);

Obviously I'm not saying the implementation actually does anything like this. What I'm getting at is that storing and using this "metainformation" as you put it is trivial. It's similar to a type system that besides storing the values of measurements it also stores the units that they're expressed in:

auto position = get_position(); //these developers decided to use feet
auto velocity = get_velocity(); //these ones decided to use meters
auto position_an_hour_from_now = position + velocity * (3600 * a_second); //type system handles conversions automatically
print(position_an_hour_from_now.convert_to(kilometers))

kigar64551 wrote:
unless Adobe stores some "meta information" in its own file formats

Yes, Adobe files store lots of additional information and application state.

You seem to have some knowledge of some image format and are erroneously extrapolating it out to all image formats.

Yes, I understand there are different color spaces. There is RGB, YCrCb, CMYK, HLS, HLV, XYZ and even more. There is not just one way to represent colors. But, those color spaces are just different ways to represent the same information! For example, there are formulars to transform RGB values into the equivalent HSV or CMYK values — and vice versa. Of course, this works with the other aforementioned color spaces just as well. Depending on what kind of processing you do, one color space may be more "convenient" than the other.

But the key point is: A specific color is still the same color, regardless in which color space it is represented in!

See here for an example: https://i.imgur.com/vAC1VoC.png

And yes, there are wave-lengths of light that the human eye can't perceive. In fact, the spectrum that we actually can perceive is extremely small! But, of course, we are talking about the visible spectrum (colors) here. Scientific images, recorded, e.g., in the "ultraviolet" or "infrared spectrum", are usually converted (shifted) into the "visible" spectrum, using pseudo-colors, so that we can actually see them.

Pantone is a separate color space that's not necessarily translatable to any of those.

If you pick a specific color — and yes, I mean a color in the normal "human visible" spectrum — put that color into your fancy color book and give it an elaborate name like "Pantone color #42", then that's simply yet another (obscure) way to refer to the same, plain old color! It's still the same color that — just as well — could be referred to by the equivalent RGB or equivalent HSV or equivalent CMYK value.

No. You are wrong. I can easily show how it can be done:

Sure, if you store an image using indexed colors, then — at least in theory — some of the colors in your color table may be defined by their RGB value, while others are defined by their CMYK, HSV, XYZ or whatever color space value. And, yes, some of the colors in your color table may even be defined by their fancy "Pantone" identifier. But: Why would anybody want to have this unnecessary over-complication? Why "mixing" different color spaces (or Pantone id's) in your color table? Keep in mind: All¹ the colors that you want to have in your color table can be transformed into the desired target color space (e.g. RGB) once. And then we only have to deal with a single color space.

In fact, this is what real-world image formats, such as PNG do: If indexed-colors are used, then each pixel in the PNG image is stored as a palette index (in the range from 0 to 255), and the palette itself is stored as a sequence of 256 RGB triplets (three bytes each).

¹ in the normal "human visible" spectrum of colors

Have you looked at the drivers of professional publishing printers in order to make this assertion?

No, I haven't. But I don't have to. I know that a "professional" printer probably is capable of reproducing the specified colors (in the source image file) much more accurately than my "$99" printer at home — because the "professional" printer is more accurately calibrated, has better/more inks available, and so on. Still: All this does not change the fact that the same color is still is the same color, regardless of what color space it is represented in, or what fancy name we assign to it! In the end, we send the color to be printed — encoded in one way or another — to the printer. And then it's up to the printer (driver) to reproduce that color in the best way that it is capable of.

Last edited on

Even color spaces designed for the visible spectrum can contain points that are not round-trip convertible to other color spaces.

Example 1: In HSV, infinitely-many points exist with minimum saturation and maximum value, but these all translate to RGB(255, 255, 255). If you translate them back you've lost information, because there's no way to reconstruct the hue component. That component may or may not contain information relevant to whoever encoded it, so it would be inappropriate to take a set of data specified in HSV and convert it to RGB because you think they're equivalent, simply because they cover the same perceptual space.

Example 2: CIELAB fully contains RGB, but not the other way around. As I recall, RGB is especially lacking in the green channel. Again, it would be inappropriate to take CIELAB data and convert it to RGB, at least without first checking if you might be losing data in the process.
Even taking this into consideration you could still be losing information, since RGB is supposed to be a device-dependent color space, while CIELAB is device-independent. Thus converting CIELAB data to RGB and copying the single RGB data to two separate devices could result in perceptually different images.

Likewise, it's inappropriate to take Pantone data as if it's equivalent to data in other color spaces without bothering to understand what it's encoding. In particular, this

give it an elaborate name like "Pantone color #42", then that's simply yet another (obscure) way to refer to the same, plain old color!

is yet another unfounded assumption. Have you worked in the publishing or printer business to know what is or isn't contained in the Pantone palette? How are you so sure that all its values are directly convertible to CMYK? I'm particularly bothered by the assumption that people are just stupid and are needlessly paying for just a table of colors. Maybe they are, maybe they aren't, I don't know, but I certainly don't assume either.

EDIT:

Why would anybody want to have this unnecessary over-complication? Why "mixing" different color spaces (or Pantone id's) in your color table? Keep in mind: All† the colors that you want to have in your color table can be transformed into the desired target color space (e.g. RGB) once

As I've already said time and again, because this is not necessarily true either mathematically, or in practice when you send the data to the output device.

Last edited on

Duthomhas (13200)

@kigar64551

You are working on bad assumptions.

If you have an image file where the data is direct indices into a Pantone color swatch, then you SOL.

Fortunately, most image file formats work over RGB-encoded data. The problem is that RGB is not sufficient across media.

Enter a translation layer, which takes the RGB-encoded data and transforms it to another color space. If the EXIF data for your image indicates a Pantone color swatch or palette, or even if it doesn’t and your software is just doing its job to manage colors across devices, there is a translation layer to adjust colors for the intended output device.

For Adobe software, which uses Pantone color spaces extensively, this produces a problem. Look through your settings/options/whatever your Adobe product calls it for the Color Management options and either turn it off or change it to something other than Pantone. Make sure to tell it to straight-up ignore it even when a file says “use my embedded Pantone color profile.”

I do not use Adobe software, so you will have to look through the documentation yourself.

Understanding Color Management is essential when dealing with professional image data. There is a whole lot to learn, but you cannot skip this step if you plan to play with big boy’s and girl’s image data.

kigar64551 wrote:
But the key point is: A specific color is still the same color, regardless in which color space it is represented in!

The problem with this statement is that a specific colour might not be representable in a different colour space. There is not a one-to-one correlation between different colour spaces. There is also some glossing over about the difference between a colour space and colour model.

A colour space is just a way of organising colours. Is supports reproducible representations of colour with colour profiling by various physical devices. Pantone is an arbitrary colour space, it uses physical swatches and names to represent a specific colour. Other colour spaces are more mathematically structured such as sRGB.

A colour space is useful for determining the capabilities of a device or file and tells you a bit about the colour model it uses. This in turn gives you an idea of the range of colours, its gamut, that the device can reproduce. The range of colours that a CMYK colour model device can reproduce are not the same as the range of colours a RGB colour model device can reproduce.

A colour model is an abstract mathematical method of describing a colour with tuples of numbers, eg RGB, CMYK, etc. but it requires some sort of mapping function to an absolute colour space, like CIEXYZ, to be unambiguous. This then leads you to sRGB, Adobe RGB, etc.

The colour models can only produce a subset of the full CIEXYZ gamut. It is entirely feasible to have a colour in the Pantone colour space that is not able to be reproduced on any RGB or CMYK colour model devices. If I remember correctly, Pantone has something like ten base colours to mix from.

The other thing to remember is that not all printing is CMYK, there is also the extended gamut of CMYKOGV. CMYK covers something like 55% of the Pantone Spot colours and ECG printing covers about 90%. Then you have using the files to do colour separations to create print plates for offset printing, or silk screen and using custom mixed inks.

Duthomhas (13200)

Recent video update on Pantone and Adobe
https://youtu.be/qMWAY8Cdsz0

Recent video update on Pantone and Adobe
https://youtu.be/qMWAY8Cdsz0

Yeah, so their only real selling point is that two parties can agree on a specific "real-word" color, even if they don't have properly calibrated screens for reasons only god knowns, by falling back to "Pantone" color books (aka "medieval ages style" calibration" 😂).

If both sides were working with properly calibrated screens, then, for example, sRGB would be perfectly sufficient in 99.9% of all cases.

(Yes, and properly calibrated printers too, of course)

BTW: If the OLEDs in your screen are subject to aging, you can simply re-calibrate. No need to buy a new screen every couple of months, like you are supposed to do with those "Pantone" books. "Pantone" is a good example of how to not implement sustainability.

Last edited on