Jump to content

Emissive Masking with Paint Tool Sai-- is it possible?


You are about to reply to a thread that has been inactive for 186 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

1 hour ago, Wulfie Reanimator said:

The black layer is disabled, it does not get saved with the picture. Doesn't the green-and-blue gradient count as a "landscape picture?" That layer is enabled, it's just 1% opacity. There's nothing there besides the red pattern. The left-side screenshot in my previous picture had the black background for clarity of what the pattern was. The right-side screenshot is the one I exported.

Here I've done the same process in Photoshop, making the sky emissive:

4ed3363c43.png

The mountains are 1% opacity, with the ones in the background increasing from 30%, 50%, 70%, to 100% for the main sky.

Again, I saved the images as PNG with the absolute default settings. (Yes, it's obviously a 32-bit PNG.)

811d57db4a.png

The point I'm trying to make here is -- don't paint the unwanted areas black or white.. ignore the color and make them transparent.

Same in Paint Tool SAI finally, it even specifically asks which type of PNG to save:

b63d0f0f3a.png

Although it looks like the background is solid white -- it isn't. It's trasparent except for the glowy bits, and the background is 1% opaque.

5398ef603f.png

Though, curiously the wall looks nothing like the original texture I used. It looks extremely harshly saturated, the color levels are all over the place. I think we're onto something now. Merging the two layers before saving didn't help at all, so this might actually be a problem with SAI rather than anything @LilithServil could've messed up.

I just followed along with the SAI example there and...

R26ow8C.png

ei5SoRD.png

vXTWvmc.png

KgA6at2.png

Still pitch black with texture getting eaten. ;-;

I'm definitely starting to think it's a SAI problem. I'll probably have to just install a new program if I want to mess with emissive stuff at all, because SAI just doesn't handle these properly for whatever reason :s

Link to post
Share on other sites
7 hours ago, Wulfie Reanimator said:

Again, I saved the images as PNG with the absolute default settings. (Yes, it's obviously a 32-bit PNG.

From the wiki about png file format

Alpha storage can be "associated" ("premultiplied") or "unassociated", but PNG standardized[26] on "unassociated" ("non-premultiplied") alpha, which means that imagery is not alpha encoded; the emissions represented in RGB are not the emissions at the pixel level. This means that the over operation will multiply the RGB emissions by the alpha, and cannot represent emission and occlusion properly. 

https://en.m.wikipedia.org/wiki/Portable_Network_Graphics

Now, let's not confuse the support of per channel bit depth with the need of an 8 bit per channel over 4 channels. I'm fully aware that png can support 8,16 and 32 bit per channel, but that's not how it works, using 32 per channel you're turning a regular image into a sort of hdri. That is why you got the background oversaturated. Conversely your attempt in photoshop, which defines bitdepth separately in a menu, that didn't happen so harshly like it did in SAI, but this doesn't mean that your process is color- safe. Reimporting that same image into PS and looking at the channels, the alpha you wisely crafted won't show up, leaving you with rgb only, and the alpha is written in the pixels within the other 3 channels. This is the culprit and why I was saying to use tga. With an 8 bit per channel based image, adding an alpha would total up to 32 bit and that's what PS ask when exporting tga: use 24 or 32 bit to represent the channels? Basically asking how many channels to include. The dialog box would ask the same even when I work on height maps at 16bit depth, the channel data is represented as a list of 8 bit entries to know how many channels to export/are included. 

Your examples were too simplistic in terms of color data, reason why it looked like it worked. But as soon as you turned to a quite saturated background that raised issues. Probably there is a separate control in Sai for bit depth, I don't know. What I know for sure is that if you want to include extra linear data in an image, safeguarding colors 100%,png is too prone to errors and/or degraded color and/or quality, and the way to go is tga. 

Link to post
Share on other sites
3 hours ago, OptimoMaximo said:

I'm fully aware that png can support 8,16 and 32 bit per channel, but that's not how it works, using 32 per channel you're turning a regular image into a sort of hdri. That is why you got the background oversaturated.

This is where I get lost. As far as I understand, I'm not using 32 bits per channel in any of my examples.. I'm not even sure how that would work. All I know is RGB/RGBA (8 bits per channel, or lower), not what would happen with 4x the amount of color data (or after reading that wiki page, maybe it's not explicitly color data, but indices to color data?). I guess I'm vaguely aware of 16-bit channels (true color?) but even that I couldn't talk about.

Both images -- the sky and the wall -- are marked as having "bit depth: 32" according to the file details in Windows. I assume this means 4x8 bits, not 4x32. One of them works as expected in SL, one doesn't.

 

  • "PNG standardized on "unassociated" ("non-premultiplied") alpha, which means that imagery is not alpha encoded; the emissions represented in RGB are not the emissions at the pixel level. This means that the over operation will multiply the RGB emissions by the alpha, and cannot represent emission and occlusion properly."

There are a few new terms/contexts for me here, but one thing I can't get over is "over operation." What does that even mean? In layman's terms I'd reword this as:

  • "The color data and alpha is separate. The color data does not represent the final color, because the alpha will be added before output."

How far off is that?

 

3 hours ago, OptimoMaximo said:

Reimporting that same image into PS and looking at the channels, the alpha you wisely crafted won't show up, leaving you with rgb only, and the alpha is written in the pixels within the other 3 channels.

As it does for all images I've created over the course of this thread, even during the process of creating the original image. I've never touched the alpha channel.

Sky: (works)
680663fbc1.png

Wall: (doesn't)
581a5e7380.png

3 hours ago, OptimoMaximo said:

Your examples were too simplistic in terms of color data, reason why it looked like it worked. But as soon as you turned to a quite saturated background that raised issues.

The landscape image I used for the sky example was way more saturated than this simple brick wall.

Wall #2: (made in Photoshop this time)
ccd4c216cc.png
84d027fda1.png

I get it, TGA can be a solution, but clearly this is easily doable with PNG as well, so I would consider switching file types a clutch -- a solution to a problem you (general you, including me) don't understand. But from what I can gleam from "TGA vs PNG" discussions elsewhere, TGA's separate alpha channel is what allows you to have fully transparent pixels that still hold color value, unlike PNG which requires this 0.1% or 1% opacity. (TGA below, the alpha channel doesn't work if I save as PNG)

4b3f51fb34.png

What I'm trying to wrap my head around is why would SAI mess up? In fact, the problem disappears if the background texture is at 4% opacity. At 3% the colors start degrading. This could literally just be a bug in the way SAI encodes color data with high alpha. And of course, 4% background is too much, as the whole wall becomes noticeably brighter with emissive mode.

Here's progressive steps from 1% to 4%:

0a2d744b3a.png

Edited by Wulfie Reanimator
Link to post
Share on other sites
4 hours ago, Wulfie Reanimator said:

There are a few new terms/contexts for me here, but one thing I can't get over is "over operation." What does that even mean?

That means that the rgb value will be multiplied against the alpha value when rendered, so the pixel color emission as well as occlusion will not correspond to the rgb value that's stored. This is what non premultiplied means. Indeed, that definition says that the values aren't alpha encoded, and that's why the best method is to use a format that has a dedicated alpha channel, you can use it to multiply whatever attribute at a later time without confusion about the actual rgb value of a pixel. 

Evn though the non premultiplied method may ensure color data retention, it's not ideal because, as you have seen, different values of alpha may be required depending on the software used, while also feeding a value to a rendering process for something that actually should get 0. In the case of emission, also the non emissive areas get some of it, even if it may be imperceptible, it is there. 

4 hours ago, Wulfie Reanimator said:

This is where I get lost. As far as I understand, I'm not using 32 bits per channel in any of my examples.. I'm not even sure how that would work. All I know is RGB/RGBA (8 bits per channel, or lower), not what would happen with 4x the amount of color data (or after reading that wiki page, maybe it's not explicitly color data, but indices to color data?). I guess I'm vaguely aware of 16-bit channels (true color?) but even that I couldn't talk about.

Both images -- the sky and the wall -- are marked as having "bit depth: 32" according to the file details in Windows. I assume this means 4x8 bits, not 4x32. One of them works as expected in SL, one doesn't

In photoshop, if you set the image mode from 8 to 32 bit and try to export, png disappears from the list. This happens because the max number of bit it can store is 24,8 per channel, or 16 for gray scale in one single channel. Tga on the other hand can be set as 32 bit because the format supports it, but it must have only 1 channel, gray scale. Tga as 16 bit can contain 2 channels. There are other formats, like exr, that can store 32 bit per channel, with virtually unlimited layers (reason why it's used in movie productions, all render passes get saved in a single frame image that contains all, color data images as rgb layers and grey scale images such ao, shadows and z depth as multiple single channel images and unpacked later for composting in Nuke). 

Believe me it's just easier to work with a dedicated alpha channel. If you change your mind, you can go back and darken or lighten an area, while this wouldn't be possible on a png. Alpha in a png basically removes the original pixels with no way to retrieve them. 

  • Haha 1
Link to post
Share on other sites
2 hours ago, OptimoMaximo said:

In the case of emission, also the non emissive areas get some of it, even if it may be imperceptible, it is there.

...

Believe me it's just easier to work with a dedicated alpha channel. If you change your mind, you can go back and darken or lighten an area, while this wouldn't be possible on a png. Alpha in a png basically removes the original pixels with no way to retrieve them. 

Yes, this I'm aware of, and those are two objective reasons why TGA is better. That's not what I'm wondering about though.

2 hours ago, OptimoMaximo said:

In photoshop, if you set the image mode from 8 to 32 bit and try to export, png disappears from the list. This happens because the max number of bit it can store is 24,8 per channel, or 16 for gray scale in one single channel.

I understand the 8-bit per channel limit, but why does Windows claim the PNGs as 32-bit?

The wiki page you linked also says (under Pixel Format) that "TrueColor and alpha" uses 32 bits (4 channels, 8 each) per pixel. This would actually be the ARGB format I'm familiar with and what my understanding keeps falling back to.

  • Color Depth / True Color wiki: "24 bits almost always use 8 bits each of R, G, and B. As of 2018, 24-bit color depth is used by virtually every computer and phone display[citation needed] and the vast majority of image storage formats. Almost all cases of 32 bits per pixel assigns 24 bits to the color, and the remaining 8 are the alpha channel or unused."
  • PNG wiki: "Pixels in PNG images are numbers that may be either indices of sample data in the palette or the sample data itself."
    • For example, the bits would be set as: aaaaaaaa-rrrrrrrr-gggggggg-bbbbbbbb or 255-255-255-255

This would all fit all 16777216 colors with 256 levels of alpha into a single int and it's the format I use for graphical rendering. Very easy, very efficient, and although "the way I do it (because it's how most systems do it)" isn't necessarily how PNG works, the wiki page doesn't seem to explicitly disagree with what I know and have demonstrated.. and that simplicity is almost certainly the main reason the convention is so wide-spread. It would not make sense to store the alpha somewhere else when you have exactly the needed amount of unused bits.

The more I read and think about all of this, the more it seems like it's you who's misunderstanding the PNG formats. Yes, the color-depth is 24-bit. But that still fits 8 bits for the alpha, giving us a bit-depth of 32.

TGA is no different. From the wiki about it:

  • "For a pixel depth of 24 bits, each pixel is stored with 8 bits per color. A 32-bit pixel depth defines an additional 8-bit alpha channel."

Why Photoshop isn't able to save a PNG while an alpha-layer is being used without transparency in the pixels, I might never know. The solution on the user-side is to use the alpha layer as a selection and remove it from the color channels, but that's obviously just a dumb workaround. Photoshop should be able to take the layer into account and do it properly, as it does with TGA. It's just a simple matter of processing the data that exists into the proper format.

Edited by Wulfie Reanimator
  • Thanks 1
Link to post
Share on other sites
9 hours ago, Wulfie Reanimator said:

There are a few new terms/contexts for me here, but one thing I can't get over is "over operation." What does that even mean? In layman's terms I'd reword this as:

  • "The color data and alpha is separate. The color data does not represent the final color, because the alpha will be added before output."

How far off is that?

Premultiplying is a math-saving step for storing images with partial transparency that are meant to be displayed on top of others.

Here's an easy example. Say you have a pure orange pixel that's almost clear -- let's say, only 10% opaque. That pixel's original, unmultiplied RGB values are 255,128,0. But if you want to draw it on top of another pixel you'll only need 10% of those numbers since it's only 10% visible. So one thing you can do when you write that image file is to save that pixel's RGB values as 25,12,0 in the first place. Now your rendering program has less math to work out, and it'll run faster. (Plus other, more esoteric benefits.)

Whether your exporter pre-multiplies depends on your image editor. Whether you WANT to pre-multiply depends on the program that'll be using the image, and how. If you're using the alpha channel as an emission mask, you do NOT want to pre-multiply.

Oh, and the "over" operation is the basic "drawing an (alpha-having) image over another" task. https://en.wikipedia.org/wiki/Alpha_compositing

  

9 hours ago, Wulfie Reanimator said:

What I'm trying to wrap my head around is why would SAI mess up? In fact, the problem disappears if the background texture is at 4% opacity. At 3% the colors start degrading. This could literally just be a bug in the way SAI encodes color data with high alpha.

I wouldn't be surprised. I just installed SAI and tried progressively erasing a pure color area until it was gone. (Orange, by the way... 255,128,0.) The red value stayed at 255 all the way up to the end but the green wobbled unpredictably between 128 and 127, then dropped into the 20s and 30s when I got below 10% or so and hit 0 at 1%. Then it went pure black at 0% (which is the OP's original problem).

Edited by Quarrel Kukulcan
  • Thanks 1
Link to post
Share on other sites
15 hours ago, Wulfie Reanimator said:

The more I read and think about all of this, the more it seems like it's you who's misunderstanding the PNG formats. Yes, the color-depth is 24-bit. But that still fits 8 bits for the alpha, giving us a bit-depth of 32.

Yes you're right. Alpha is still there, and by convention that is interpreted as an opacity value for pngs in graphic programs as you can see. Hooking up the alpha output in a rendering node works exactly as intended (Maya, Max, Modo, c4d... If blender doesn't or does something differently it's no proof that this isn't an industry standard), the transparency information gets processed and displayed as intended. As I said in a previous comment, alpha is definetly stored, but it is stored in the color itself. By the way, if you want to use an alpha channel with png, just use a mask, although this would premultiply the image on the screen and may lead to inaccurate preview of the final output. So, while the file may also be a 32 bit, as you can see it doesn't behave like so. If it did, you could set the alpha to 0 and still preserve the color data, but it doesn't. Because the primary goal of a png, afaik, was to enable transparency on images for network streaming, and it's alpha use has been always interpreted for that use in mind. It's efficient and store lossless images at a lower memory footprint, I use it all the time for that. But unfortunately its alpha channel can't be reliably used for anything but transparency. If you need extra data along with colors, there must be a dedicated alpha channel, period. This is my misunderstanding of png. 

Link to post
Share on other sites
6 hours ago, OptimoMaximo said:

As I said in a previous comment, alpha is definetly stored, but it is stored in the color itself. By the way, if you want to use an alpha channel with png, just use a mask, although this would premultiply the image on the screen and may lead to inaccurate preview of the final output. So, while the file may also be a 32 bit, as you can see it doesn't behave like so. If it did, you could set the alpha to 0 and still preserve the color data, but it doesn't.

Okay, but...

We've already established that the PNG formats are not pre-multiplied, according to your original wiki page. So, besides the implementation details of specific programs like Photoshop or SAI, the PNG format is effectively the same as TGA, the biggest difference being that TGA is an uncompressed format (faster to process in higher resolutions), while PNG is a losslessly compressed format (which makes sense for networking). Here's an official specification page.

  • "Alpha channels can be included with images that have either 8 or 16 bits per sample, but not with images that have fewer than 8 bits per sample."
  • "The alpha sample for each pixel is stored immediately following the grayscale or RGB samples of the pixel."
  • "The color values stored for a pixel are not affected by the alpha value assigned to the pixel. This rule is sometimes called "unassociated" or "non-premultiplied" alpha. (Another common technique is to store sample values premultiplied by the alpha fraction; in effect, such an image is already composited against a black background. PNG does not use premultiplied alpha.)"

From the above, we can conclude that I was right about the representation layout, though it's RGBA, not ARGB.

What you're saying couldn't even make sense. You can't premultiply alpha into the color data, as that would just make everything opaque and lose the alpha information. Never mind that even if the alpha is still stored somewhere else, now you'd have transparent pixels that are all the wrong color. Nobody would design an image format like this. You have to choose one (associated or unassociated), not both.

Here's a StackOverflow question asking how to preserve color data about fully transparent pixels in Photoshop.

  • "Yes, the PNG format itself does contain RGB data even for fully-transparent pixels. This is a problem with Photoshop, not PNG."

The accepted answer is a link to a Photoshop plugin called SuperPNG by Fnord, which adds support for not cleaning the color data from 100% transparent pixels. So again, provably not a PNG limitation. Same as to why you can't use a mask for PNG in Photoshop. It's badly coded and doesn't take the mask into account while creating the PNG.

Edited by Wulfie Reanimator
Link to post
Share on other sites

To bring this back to the OP's problem: it looks like SAI is the culprit. It doesn't preserve color data for fully transparent pixels in either PNG or TGA. (That's not unheard-of. It also seems to degrade color data for very-close-to-transparent pixels but preserve everything else, which is very weird and probably a bug.)

I know GIMP offers the option of preserving fully transparent colors with every export, and it sounds like Photoshop offers a plugin to do that. I'm not familiar with any other editing software.

  • Like 1
Link to post
Share on other sites
16 hours ago, Wulfie Reanimator said:

What you're saying couldn't even make sense. You can't premultiply alpha into the color data, as that would just make everything opaque and lose the alpha information. Never mind that even if the alpha is still stored somewhere else, now you'd have transparent pixels that are all the wrong color.

I wasn't saying it does make sense, what I was saying is that that's the observed reality when I said it can even be 32 bit, but it doesn't behave like so. 

 

16 hours ago, Wulfie Reanimator said:

called SuperPNG by Fnord, which adds support for not cleaning the color data from 100% transparent pixels

Goo to know. At this point I might check the Substance outputs both from Designer and Painter to see if that holds true in those two softwares as well. Image format output coding is prior to the acquisition by Adobe, perhaps they haven't lined up with photoshop. 

Link to post
Share on other sites
9 hours ago, Quarrel Kukulcan said:

I know GIMP offers the option of preserving fully transparent colors with every export, and it sounds like Photoshop offers a plugin to do that. I'm not familiar with any other editing software.

Paint.net has some limited support for it although it's not a well known or well documented feature. It's limited in the sense that it's easy to define a color for the full transparent parts of an image but if you want different colors for different parts, you really have your work cut out for you and are better off exporting  the image to GIMP to do the task.

Link to post
Share on other sites
3 hours ago, OptimoMaximo said:

I wasn't saying it does make sense, what I was saying is that that's the observed reality when I said it can even be 32 bit, but it doesn't behave like so.

[insert standard joke about SL vs making sense]

Link to post
Share on other sites
You are about to reply to a thread that has been inactive for 186 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...