Jump to content
  • 0

herekaya
 Share

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

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

Question

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? ddd_018.thumb.jpg.8bdd2ae27b6a9b35985192b11d75832f.jpgddd_024.jpg.56687a5d5043f6d4e477f98c58e0f470.jpgddd_019.jpg.0bb82d139d9fb323da32f8363cd6d725.jpg

Link to comment
Share on other sites

14 answers to this question

Recommended Posts

  • 0
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? ddd_018.thumb.jpg.8bdd2ae27b6a9b35985192b11d75832f.jpgddd_024.jpg.56687a5d5043f6d4e477f98c58e0f470.jpgddd_019.jpg.0bb82d139d9fb323da32f8363cd6d725.jpg

 

Link to comment
Share on other sites

  • 0

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 by Nalates Urriah
Link to comment
Share on other sites

  • 0
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.

  • Haha 1
Link to comment
Share on other sites

  • 0
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 by Jenna Huntsman
  • Haha 1
Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0
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 by Jenna Huntsman
  • Haha 1
Link to comment
Share on other sites

  • 0

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.

 

 

Link to comment
Share on other sites

  • 0
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 by Madelaine McMasters
  • Thanks 1
Link to comment
Share on other sites

  • 0
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 by Jenna Huntsman
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 270 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
 Share

×
×
  • Create New...