973p8j - Minifig Torso with Town Vest with Pockets and Stiped Tie pattern

[Orion Pobursky]

https://www.ldraw.org/parts/official-par...tid=973p8j

Willy's part is great but I think the coloring is slightly wrong.

The shirt should be white. The small neck notch in white shouldn't be white although it hard to tell what it should be.

https://rebrickable.com/parts/973pr1192c...low-hands/

https://www.bricklink.com/v2/catalog/cat...D#T=C&C=11

Thoughts?

[Philippe Hurbain]

The shirt should be white. The small neck notch in white shouldn't be white although it hard to tell what it should be.

I think that both should be white. But black plastic color bleeds in...

[Orion Pobursky]

I think that both should be white. But black plastic color bleeds in...

No. It looks kind of like Flesh but all the sets this torso has been used in are Town sets. The LEGO supplied render on Rebrickable has it in yellow.

[N. W. Perry]

No. It looks kind of like Flesh but all the sets this torso has been used in are Town sets. The LEGO supplied render on Rebrickable has it in yellow.

Hmm…so the LEGO render tells us what it ideally represents: a white shirt, with a patch of the underlying "skin" color showing at the top. On the other hand, the known uses of the pattern, all of which appear to be printed on black, result in a shirt that appears light blue with a patch of white (or near-white) underneath, because of the transparency of the ink.

This reminds me of the discussion about the envelope parts, where the shadow color in the pattern depends on the underlying plastic color, or at least is informed by it. Perhaps there needs to be an agreed standard for how to model this real-world property?

I think I've read that, for patterns, it's desirable to aim toward representing the real-life version as closely as practical. On the other hand, some amount of "idealization" is beneficial to account for things like printing offsets or variations in color quality. At the same time, the effect of ink transparency on an underlying base color is doubtless part of TLG's quality control process—that is, "what it looks like" is almost certainly considered in production, alongside "what it's supposed to be".

In short, is the difference between the intended color and the apparent color a feature, or a bug?

[Orion Pobursky]

I think I've read that, for patterns, it's desirable to aim toward representing the real-life version as closely as practical.

I disagree with this. I think we should go with the intended color, not the color as it shows on a real part. Part of the appeal of LDraw is that you can use a part in a color that has never produced in real life. Trying to deal with the slight transparency of the ink is a nightmare waiting to happen.

Actually, I don't think this is "our" problem. An intrepid developer could, in fact, have this transparency in their renderer if they wanted and us doing anything other than the intended color would mess this up.

[N. W. Perry]

I disagree with this. I think we should go with the intended color, not the color as it shows on a real part. Part of the appeal of LDraw is that you can use a part in a color that has never produced in real life. Trying to deal with the slight transparency of the ink is a nightmare waiting to happen.

Yeah, I don't remember who opined that; it was somewhere in one of the various standards/guidleines/tutorials that exist out there… Suffice to say, the principle is out there somewhere, so it's guiding at least some people.

I would add, though, that another part of the appeal of LDraw (to me, at least) is that you can replicate the part as it looks in real life. And yet another part of the appeal is that it's comprehensible and flexible enough that you could, in fact, have both. So to me, it doesn't have to be an exclusive choice—the ideal solution would be one that allows both a faithful representation of the real part, and the ability to extend the palette.

Actually, I don't think this is "our" problem. An intrepid developer could, in fact, have this transparency in their renderer if they wanted and us doing anything other than the intended color would mess this up.

Yes, something just like that is what would probably be the ultimate solution. You'd encode the pattern with the intended color (assuming you could determine it), and then somebody would add a transparency parameter that governs how that color interacts with the underlying base color. I'll let others hash out who that somebody ought to be…I know that we do have some material definitions that include parameters (like speckle and transparent parts), but I also know that many of LDraw's most powerful extensions have been those brought in by developers.

[Travis Cobbs]

Actually, I don't think this is "our" problem. An intrepid developer could, in fact, have this transparency in their renderer if they wanted and us doing anything other than the intended color would mess this up.

I don't think that would be possible, due to the fact that there is nothing underneath the polygons representing patterned sections. There's no way for the renderer to know if a given polygon represents paint over top of the part's inherent color, or something else. There's also no way for it to know the opacity of the paint, which I am sure differs both based on the paint's color and based on the part's age. (I can't imagine that LEGO would avoid changing their paint formulation if they knew that a new formulation would be better. I assume that it has changed over the years.)

[Orion Pobursky]

I don't think that would be possible, due to the fact that there is nothing underneath the polygons representing patterned sections. There's no way for the renderer to know if a given polygon represents paint over top of the part's inherent color, or something else. There's also no way for it to know the opacity of the paint, which I am sure differs both based on the paint's color and based on the part's age. (I can't imagine that LEGO would avoid changing their paint formulation if they knew that a new formulation would be better. I assume that it has changed over the years.)

You could probably approximate it by assuming that all non-color 16 faces were printed and then using the base color to blend. I agree that this is a problem that doesn't need to be solved, can be solved easily, or is even practicably solvable.

[N. W. Perry]

You could probably approximate it by assuming that all non-color 16 faces were printed and then using the base color to blend. I agree that this is a problem that doesn't need to be solved, can be solved easily, or is even practicably solvable.

I had many paragraphs' worth of thoughts on this, but in the end, you're right—it all comes back in the end to whether the problem needs to be solved. For those users who need parts to have the correct apparent color, it doesn't; for those who need it to have the correct intended color, it does. We have a strong guiding principle of backwards compatibility—would that allow us to un-solve the one problem in order to solve the other?

I'm not convinced the stakes are quite that high, at this point. I think the bluish color was a fair judgment call on the part of the author; it's not perfect, but it "looks right". If the part ever officially comes out in other base colors, those stakes may well be higher, and perhaps then would be a time to re-visit the question?

[Willy Tschager]

https://www.ldraw.org/parts/official-par...tid=973p8j

Willy's part is great but I think the coloring is slightly wrong.

The shirt should be white. The small neck notch in white shouldn't be white although it hard to tell what it should be.

https://rebrickable.com/parts/973pr1192c...low-hands/

https://www.bricklink.com/v2/catalog/cat...D#T=C&C=11

Thoughts?

The pattern is based on this scan:

   

Hope this helps. If you wanna change it go ahead - I won't.

w.

[N. W. Perry]

The color changed version (matching the official render) is now, finally, on PT:
https://www.ldraw.org/cgi-bin/ptdetail.c...973p8j.dat

[Willy Tschager]

The color changed version (matching the official render) is now, finally, on PT:
https://www.ldraw.org/cgi-bin/ptdetail.c...973p8j.dat

Official render or not - there is no yellow involved. It is known that the virtual representation sometimes differs from the final part.

w.

[N. W. Perry]

Official render or not - there is no yellow involved. It is known that the virtual representation sometimes differs from the final part.

w.

That's right, yellow was chosen by the "what it's supposed to be" philosophy. If we decide to go with the actual, resultant colors that's OK too.

I think the final part (the one actually printed and sold) was meant to represent Light Flesh/Nougat (color 78). The first use of the torso in set 4855 was accompanied by hands and a head of this color. (Even then the "official" drawings showed this patch as yellow.)

Here's another nice real-life photo: https://images.brickset.com/news/68609_P1064630.JPG

[Magnus Forsberg]

Could it be 2 different prints?

set 10243 leads to this part:
https://brickset.com/sets/containing-part-6219624

while this print is more similar to this:
https://brickset.com/sets/containing-part-4275535

[Willy Tschager]

Could it be 2 different prints?

set 10243 leads to this part:
https://brickset.com/sets/containing-part-6219624

while this print is more similar to this:
https://brickset.com/sets/containing-part-4275535

Would explain a lot.

w.

[N. W. Perry]

Could it be 2 different prints?

set 10243 leads to this part:
https://brickset.com/sets/containing-part-6219624

That is indeed a different print, though not the one under discussion here.

If there are different prints of p8j, it would be a question of a yellow neck on one, and a flesh/nougat neck on the other. But so far, all photos and all official renders I've seen of p8j are identical in color.

Unfortunately, that color seems to be a very pale yellow, like 226 but lighter. It is neither obviously 14 nor 78. Here are RGB values sampled from a few random pixels of it in this image:
https://images.brickset.com/sets/Additio...gure_1.jpg
F0E9CA
F6E9BE
E9E5C9
E8E1C6

The closest matching LDraw colors by hue are 183 (Pearl White) and 329 (Glow-in-dark White). The closest solid color is probably 226, with 78 a close second.

[Orion Pobursky]

Based on all the photos I've seen, I think it's yellow with white bleed through just like the white looks bluish because of the black bleed through.

[N. W. Perry]

Based on all the photos I've seen, I think it's yellow with white bleed through just like the white looks bluish because of the black bleed through.

So here's another question, assuming that's true:
Does it make a difference that the bleed through of yellow on white comes from another layer of ink that will always be there, rather than from the base color of the part, which may change (as is the case with the white on black)?