Bad quality BoM tattoos

[herekaya]

Hey! I need help!

I just started creating tattoos for myself but the Tattoo get kinda blurry and lost the quality when i add to my body, I think the photos will give you guys an idea what I'm talking about. 

Anyone with tattoo creation skills can help me? 

[Rowan Amore]

31 minutes ago, herekaya said:

Hey! I need help!

I just started creating tattoos for myself but the Tattoo get kinda blurry and lost the quality when i add to my body, I think the photos will give you guys an idea what I'm talking about. 

Anyone with tattoo creation skills can help me? 

 

[Taygothackedd]

I did my own tattoo and the omega way was easier for me 

[Jerilyn Acajou]

this is mine,  the quality of tattoo is depend on quality of tattoo texture.  if the lines in the texture is not sharp or smooth enough, line width, line color intensity 

[Nalates Urriah]

You may be running in the texture-quality issue Jerilyn brings up.

Since tats usually have transparent parts the uploaded images must be PNG or TGA. TGA has issues that are avoided by using PNG, so I recommend PNG.

The next big factor in quality is the image size. In 3D model rendering the size of the texture is related to the number of pixels used on screen... meaning how many pixels does the image really have to cover on screen. For instance fingernails use very few until they are zoomed in on. So pros use smaller images.

In SL most people used 512x512 textures because that is all the server side bake engine would produce. That was upgraded with the introduction of BOM to 1024x1024. Tats will bake as they are system layers. Applier tats do not bake. So they could always be 1024's. The result is old system stuff is not as clear as new stuff.

GIMP, PAINT.NET, and Photoshop all do a better job of scaling images than the SL engines do. Any image larger than 1024x1024 is resized at up load and stored in JPG2000 format. JPG2000 requires power of 2 dimensions, so 32, 64, 128, 256, 512, 1024... While images do NOT have to be square they must use a power-of-2 dimension; 32x128 or 512x1024 or similar. Anything else will be resized and lose quality. Do size in your image editor before uploading.

You goal in making a texture for a tat is to have the SL engine, Kakado, make as few changes to your upload as possible.

AFAIK, only Firestorm and the Linden default viewers use the Kakado engine. All other viewers use an open source alternative. Regardless of which viewer you prefer, use only either of those for texture uploads. Other viewers with the open source version do a decent job, but those images can have changes that would not appear if Kakado were used. It actually depends on the individual image. Some images will encode and decode perfectly with any engine's image formatting. Others won't. Fortunately, the majority of images work well regardless of engine used.

Edited April 15, 2021 by Nalates Urriah

[Jenna Huntsman]

3 hours ago, Nalates Urriah said:

Since tats usually have transparent parts the uploaded images must be PNG or TGA. TGA has issues that are avoided by using PNG, so I recommend PNG.

Interesting, didn't know about Kakado.

But r.e. TGAs, I can't say I've ever had issues, in fact my (personal) experience has lead me to use TGAs exclusively for SL (as SL's texture compression often introduces compression artifacts when compressing to JPEG2000 - on top of an already compressed PNG), as well as TGAs being vastly easier to use when it comes to working with alphas (especially when you intend to use the texture as an alpha mask).

I also don't use Firestorm as my regular viewer, so that may have something to do with that. I use CoolVL as my daily driver (which I think uses the absolute most up-to-date version of open-source JPEG2000 decoder / encoder), so it's possible the TGA issues got fixed in later versions.

[Madelaine McMasters]

3 minutes ago, Jenna Huntsman said:

SL's texture compression often introduces compression artifacts when compressing to JPEG2000 - on top of an already compressed PNG

Both PNG and TGA allow/support lossless compression. Neither supports lossy compression.

[Jenna Huntsman]

17 minutes ago, Madelaine McMasters said:

Both PNG and TGA allow/support lossless compression. Neither supports lossy compression.

PNG *does* support lossy compression via preprocessing (which can easily be seen used in Photoshop when saving a PNG).

Maybe my experience was caused by a bug in how PNGs are handled. Who knows (not me!).

Edit: Seems like a quick google search can answer that, see here on the Unity forums:

http://answers.unity.com/answers/1791622/view.html

Seems like the issues I had with PNGs relate to how PNGs are compressed (transparent pixels have their colour information discarded) which means that if the alpha data is modified in *any* way, you may be able to see the areas where the colour information was discarded (referred to as 'bleeding')

Edited April 15, 2021 by Jenna Huntsman

[Madelaine McMasters]

5 minutes ago, Jenna Huntsman said:

PNG *does* support lossy compression via preprocessing (which can easily be seen used in Photoshop when saving a PNG).

Maybe my experience was caused by a bug in how PNGs are handled. Who knows (not me!).

Nothing stops someone from compressing an image before encoding it in a lossless format. That does not mean that the image format supports lossy compression.

If you decompress a PNG or TGA image, you will get back, bit-for-bit, the original image. Because those standards only support lossless compression, you'll end up with larger file sizes than for lossy formats like JPG or HEIC.

I suppose it's possible that the SL viewer handles PNG and TGA images differently, applying different kinds or amounts of lossy compression when converting to the internal JPEG2000 format.

[Jenna Huntsman]

7 minutes ago, Madelaine McMasters said:

Nothing stops someone from compressing an image before encoding it in a lossless format. That does not mean that the image format supports lossy compression.

If you decompress a PNG or TGA image, you will get back, bit-for-bit, the original image. Because those standards only support lossless compression, you'll end up with larger file sizes than for lossy formats like JPG or HEIC.

I suppose it's possible that the SL viewer handles PNG and TGA images differently, applying different kinds or amounts of lossy compression when converting to the internal JPEG2000 format.

Sorry, see my above edit.

TLDR; PNG isn't a *truly* lossless format in most cases, as the colour information is discarded in completely transparent pixels. I assume that when compressing to JPEG2000, the alpha data loses some of the information it contains, which leads to some bleeding of some areas in the texture.

TGA on the other hand is an uncompressed format, hence no colour information is lost even if the pixels are transparent, meaning the compression to JPEG2000 doesn't result in colour bleeding (or, at least it is not noticeable as the colour information was not discarded as it would be in PNGs)

Edited April 15, 2021 by Jenna Huntsman

[Love Zhaoying]

31 minutes ago, Madelaine McMasters said:

JPEG2000 format.

I'm-a wait for the JPEG2020+ format. 2000 is so last century.

[Nalates Urriah]

A bit more on PNG: https://www.howtogeek.com/203979/is-the-png-format-lossless-since-it-has-a-compression-parameter/

In SL we used to have horrible halos/bleeding in TGA images with transparency. It was a rite of passage for noobies to learn how to use TGA in SL. We had to take special steps to avoid problems. (Ref - forum archive -- Ref - Robin Wood) There was a plugin we needed to make it easy, Flaming Pair. Which is why I moved away from TGA. This was 2008 to 2010. I stopped using TGA with SL in that time frame and haven't bothered with it since.

Kakadu has been upgraded numerous times since then as has Photoshop. It may have changed how TGA works with SL.

Looking at info available now, it seems most of our image problem may have been with PS.

PS now and I think always has saved TGA with a color resolution depth; 16, 24, & 32. And offers a RLE compression. As I recall I had to be sure to use 32 and no compression plus some gymnastics to get color and transparency correct while avoiding bleeds. Robin provides a step-by-step tutorial of what we were doing. I found PNG easier, faster, and less of a problem.

 

 

[Madelaine McMasters]

5 hours ago, Jenna Huntsman said:

Sorry, see my above edit.

TLDR; PNG isn't a *truly* lossless format in most cases, as the colour information is discarded in completely transparent pixels. I assume that when compressing to JPEG2000, the alpha data loses some of the information it contains, which leads to some bleeding of some areas in the texture.

TGA on the other hand is an uncompressed format, hence no colour information is lost even if the pixels are transparent, meaning the compression to JPEG2000 doesn't result in colour bleeding (or, at least it is not noticeable as the colour information was not discarded as it would be in PNGs)

PNG supports full RGBA (Truecolor+Alpha). It may be that your graphics program has been told to store the image in Indexed mode, which bins the original image into a palette of colors that can include transparency, and necessarily loses image information during the conversion. That is not an issue with PNG.

TGA supports lossless run-length-encoded compression and the same RGBA pixel formatting as PNG. It also supports indexed (color mapped) data.

It's also possible that the SL JPEG2000 importer handles PNG and/or TGA differently. I don't know why they'd do this for potentially identical data, but we are talking about SL here.

I think any differences you are seeing between PNG and TGA format imagines are due to the way your graphics program exports to those two formats. Done properly, there should be no visible difference.

https://en.wikipedia.org/wiki/Portable_Network_Graphics#Pixel_format
https://en.wikipedia.org/wiki/Truevision_TGA

ETA: It's only a vague, faded memory now, but I do recall having issues with 32-bit TGA imports years ago, which were resolved by importing 32-bit PNG. that sounds opposite your experience, but similar to Nalates'.

Edited April 16, 2021 by Madelaine McMasters

[Jenna Huntsman]

12 minutes ago, Madelaine McMasters said:

PNG supports full RGBA (Truecolor+Alpha). It may be that your graphics program has been told to store the image in Indexed mode, which bins the original image into a palette of colors that can include transparency, and necessarily loses image information during the conversion. That is not an issue with PNG.

TGA supports lossless run-length-encoded compression and the same RGBA pixel formatting as PNG. It also supports indexed (color mapped) data.

It's also possible that the SL JPEG2000 importer handles PNG and/or TGA incorrectly.

I think any differences you are seeing between PNG and TGA format imagines are due to the way your graphics program exports to those two formats. Done properly, there should be no visible difference.

https://en.wikipedia.org/wiki/Portable_Network_Graphics#Pixel_format
https://en.wikipedia.org/wiki/Truevision_TGA

I'm using Photoshop CC 2021. Maybe PS doesn't like PNGs now. If what @Nalates Urriah says is correct, that could be entirely possible if another format was borked in the past. Or, as you say, SL's importer could be doing something silly.

Edit: Could be that Kakadu handles PNGs better than the open-source JPEG2000 handler, but the open-source one handles TGAs better. Not a viewer dev (probably for the best), so couldn't say, but that also seems like a possibility.

Edited April 16, 2021 by Jenna Huntsman

[Lindal Kidd]

"Infinite are the arguments of mages"