Targa is "lossless" and has fixed, heavier file sizes. PNG has some loss in quality due to compression out of the gate, but much smaller file sizes which can vary on how much data are in your rgb channels (file sizes can be especially low if the textures are grayscale etc).
PNG's compression may not be too much of a problem, as textures receive compression/downrezing in engine anyway, but tga is nice as you can confidently go to a higher rez in engine without issues (if you imported in 4k that is).
Targa is "lossless" and has fixed, heavier file sizes. PNG has some loss in quality due to compression out of the gate, but much smaller file sizes which can vary on how much data are in your rgb channels (file sizes can be especially low if the textures are grayscale etc).
PNG's compression may not be too much of a problem, as textures receive compression/downrezing in engine anyway, but tga is nice as you can confidently go to a higher rez in engine without issues (if you imported in 4k that is).
afaik compression on PNG isn't modifying the pixel data to reduce the file size, it's compression like zip compression. You don't lose quality, you lose time/cpu because from unpacking the compression. at the least you can set it to lossless just like tga, but with better files sizes but crap photoshop reading of alpha channels.
PNG compression is absolutely not destructive, that's just misinformation. It's painfully slow to write out though.
To the OP : TGA is very fast to write, and rock solid overall. You might just need to use a different format for high bit depth if needed/required (EXR) but that's probably not something you should concern yourself about at this point given your current question.
You might just need to use a different format for high bit depth if needed/required (EXR)
Also yeah, worth mentioning that bit-depth is huge for normal maps especially. lots of banding issues may be rectified by simply baking out as psd/png, and rendering with 16 bit png (tga's can only use 8bit)
Well the point is that you can save over a PNG as many time as you want and you won't get any loss of signal. But of course it will be saved at the indicated bit depth, that's a bit of a given My overall point is that claiming that PNG is destructive will only confuse the OP given his current knowledge, and that wouldn't be helpful. I understand that it may sound like splitting hairs (and of course it is destructive if the source has a higher bit depth than what the format carries), but misunderstandings can stick for a while so might as well be clear. And in all fairness, I wasn't the clearest myself
To the OP : beyond the obvious (ie not using a highly destructive format to store your data) there is some part of subjectivity here. For instance some people with a very high level of tolerance for slow workflows may suggest you to use PNGs as an export format ; yet if you start using batch exports out of Photoshop (for instance to export out ten 4k textures out of a master PSD) then you'll quickly see that PNGs are just a pain given how taxing they can be on save at high resolutions, whereas TGAs write out instantly even at huge sizes.
In short : just keep things simple and stick to TGAs for now. Also don't bother trying to store a transparency pass as an alpha channel in the texture file itself, this is really not needed except for some very specific cases (materials with poor flexibility of inputs) and will only make your workflow more complicated than it needs to be - especially since some exporters may actually attempt to cull out the data behind the alpha as "not needed" (I've been on projects doing just that and it is a *huge* pain). Better rely on saving out explicit RGB passes, and writing out more files for extra channels if so needed.
I've been using .tga for a quite some time, especially with personal work because I want to, and it's been a solid all-around format for final 8-bit textures. Of course I originally work with 16-bit source (.psd bakes from Marmoset). Even though Marmoset is able to bake 32-bit, I find it overkill already. 16-bit is fine.
Still wondering about Gimp's .tga export settings what's the best to use, because I'm using Gimp 2.10 series' dithering tools instead of Substance Painter's one (exporting 16-bit out of SP for Gimp). And SP only dithers normal maps, and I'd like to dither all of them, for the sake of consistency. Another reason I'm using Gimp is for handling non-SP-workflow assets, like character's hair. Usually needs third party softwares for that, like FiberShop:
But what final format would you use for 16-bit with some cases, like super glossy surfaces (cornea, glass, laquered wood etc.) without banding or noise from 8-bit? I've used TIFF so far, but it's confusing because the extension can be either .tiff or .tif. You mentioned .exr, how's that different? Quality vs. file size. Trying to avoid .psd, since it's Adobe's format, and I'm using Gimp as an additional help tool for certain tasks.
Heya - well, my experience with .EXR was with a specific pipeline relying on the normalmap bakes to be written out that way by the baker, and then converted on import . I can't quite recall what the final output was (whether or not the engine used some kind of high bit depth for the normals or not) but indeed EXR was picked as the best intermediate at the time, at the very least to store the sources. That was a few years ago though.
That said that wouldn't quite solve the issue of banding on the surfaces you describe - in such cases, might as well make the geo do the heavy lifting ... I suppose ?
Replies
PNG has some loss in quality due to compression out of the gate, but much smaller file sizes which can vary on how much data are in your rgb channels (file sizes can be especially low if the textures are grayscale etc).
PNG's compression may not be too much of a problem, as textures receive compression/downrezing in engine anyway, but tga is nice as you can confidently go to a higher rez in engine without issues (if you imported in 4k that is).
afaik compression on PNG isn't modifying the pixel data to reduce the file size, it's compression like zip compression. You don't lose quality, you lose time/cpu because from unpacking the compression. at the least you can set it to lossless just like tga, but with better files sizes but crap photoshop reading of alpha channels.
It's painfully slow to write out though.
To the OP : TGA is very fast to write, and rock solid overall. You might just need to use a different format for high bit depth if needed/required (EXR) but that's probably not something you should concern yourself about at this point given your current question.
Also yeah, worth mentioning that bit-depth is huge for normal maps especially. lots of banding issues may be rectified by simply baking out as psd/png, and rendering with 16 bit png (tga's can only use 8bit)
It supports a range of bit depths which is really cool, from 1-bit, all the way up to 64-bit (16-bit per channel, that's 65536 values per).
We use it for the main collage on the front of our wiki, in lower bit depth, with IIRC a 4bit alpha (16 values). Super efficient!
To the OP : beyond the obvious (ie not using a highly destructive format to store your data) there is some part of subjectivity here. For instance some people with a very high level of tolerance for slow workflows may suggest you to use PNGs as an export format ; yet if you start using batch exports out of Photoshop (for instance to export out ten 4k textures out of a master PSD) then you'll quickly see that PNGs are just a pain given how taxing they can be on save at high resolutions, whereas TGAs write out instantly even at huge sizes.
In short : just keep things simple and stick to TGAs for now. Also don't bother trying to store a transparency pass as an alpha channel in the texture file itself, this is really not needed except for some very specific cases (materials with poor flexibility of inputs) and will only make your workflow more complicated than it needs to be - especially since some exporters may actually attempt to cull out the data behind the alpha as "not needed" (I've been on projects doing just that and it is a *huge* pain). Better rely on saving out explicit RGB passes, and writing out more files for extra channels if so needed.
That said that wouldn't quite solve the issue of banding on the surfaces you describe - in such cases, might as well make the geo do the heavy lifting ... I suppose ?