Texture compression, still don't get it

SnowSultanSnowSultan Posts: 3,643

I've asked about this before and searched up and down for more precise answers, but this render option still confuses me. Does anyone know exactly at what distance and/or why the Medium and High Threshold values are applied to textures?

I did some testing yesterday of a fairly close-up render of Kayleyss' Behemoth using two sets of values; Medium 512, High 1024 and Medium 2048, High 4096, and let them both run for 2000 iterations. There is virtually no difference between them, and I was swapping directly between them using Irfanview to check for differences. Another test I did of a more complex scene with both values set to 4096 took an hour compared to 14 minutes at 1024, and again, there was no difference in quality or texture detail.

What on earth triggers this compression and are the differences ever noticable?

Comments

  • kenshaw011267kenshaw011267 Posts: 3,805

    It's lossless compression as far as I know so there should be no difference in quality. The idea is to swap clock cycles decompressing the textures when needed in order to save VRAM. IIRC, I have a render running and don't want to shut it down just to check, the value represents how big a tecture needs to be before it is compressed. So higher values should result in fewer textures being compressed/decompressed during the render and therefore a faster render.

  • MattymanxMattymanx Posts: 6,954

    In short, if your texture compression is set to 16k, the highest value, any texture that is less than 16K will not be compressed.  If you set it 512, it mean any texture over 512x512 WILL be compressed.

    The purpose of this is to save vram.  I personally set my texture compression to 512 for both med and high.  Texture compression in Daz Studio 4.11 is far better than it was in 4.10

    To give you a comparrison of how much difference it will make, please read over the info I have listed in my promos here - https://www.daz3d.com/resource-saver-shaders-collection-for-iray - Please note that all the info listed was from Daz Studio 4.10 and its the info that Iray lists in the DS info window and not the Windows task manager.

  • SnowSultanSnowSultan Posts: 3,643

    Aeon Soul posted an image on Twitter where they recommended setting the compression to 4096 to avoid having the stitching detail on one of their outfits from rendering blurry, but as I said, I am unable to find any differences between renders using different values. Kenshaw, are you saying that there's basically no quality changes, it will just take longer to render because of the compressing/decompressing?

    Matty, thanks for that information. Why are there both medium and high settings though if one value determines whether a texture is compressed or not? I guess that's what I'm not getting; what factors into determining whether a texture is compressed at the medium value or the high one (and is there any difference in quality when it does occur)?

  • kenshaw011267kenshaw011267 Posts: 3,805

    Aeon Soul posted an image on Twitter where they recommended setting the compression to 4096 to avoid having the stitching detail on one of their outfits from rendering blurry, but as I said, I am unable to find any differences between renders using different values. Kenshaw, are you saying that there's basically no quality changes, it will just take longer to render because of the compressing/decompressing?

    If its lossless compression, which I'm almost positive it is, then there should be no loss in quality just a cost in time.

  • algovincianalgovincian Posts: 2,636

    It's lossless compression as far as I know so there should be no difference in quality. The idea is to swap clock cycles decompressing the textures when needed in order to save VRAM. IIRC, I have a render running and don't want to shut it down just to check, the value represents how big a tecture needs to be before it is compressed. So higher values should result in fewer textures being compressed/decompressed during the render and therefore a faster render.

    Where are you getting the info that it's lossless? I'm almost certain that it's not:

    https://blog.irayrender.com/post/54506874080/saving-on-texture-memory

    - Greg

  • TaozTaoz Posts: 9,979

    It's lossless compression as far as I know so there should be no difference in quality. The idea is to swap clock cycles decompressing the textures when needed in order to save VRAM. IIRC, I have a render running and don't want to shut it down just to check, the value represents how big a tecture needs to be before it is compressed. So higher values should result in fewer textures being compressed/decompressed during the render and therefore a faster render.

    Where are you getting the info that it's lossless? I'm almost certain that it's not:

    https://blog.irayrender.com/post/54506874080/saving-on-texture-memory

    - Greg

    Yes, jpg files can hardly be compressed anymore, and png usually very little, unless using lossy compression.

  • algovincianalgovincian Posts: 2,636
    Taoz said:

    It's lossless compression as far as I know so there should be no difference in quality. The idea is to swap clock cycles decompressing the textures when needed in order to save VRAM. IIRC, I have a render running and don't want to shut it down just to check, the value represents how big a tecture needs to be before it is compressed. So higher values should result in fewer textures being compressed/decompressed during the render and therefore a faster render.

    Where are you getting the info that it's lossless? I'm almost certain that it's not:

    https://blog.irayrender.com/post/54506874080/saving-on-texture-memory

    - Greg

    Yes, jpg files can hardly be compressed anymore, and png usually very little, unless using lossy compression.

    We're talking about once loaded into RAM/VRAM - file format on disk has no bearing.

    - Greg

  • HavosHavos Posts: 5,400
    Taoz said:

    It's lossless compression as far as I know so there should be no difference in quality. The idea is to swap clock cycles decompressing the textures when needed in order to save VRAM. IIRC, I have a render running and don't want to shut it down just to check, the value represents how big a tecture needs to be before it is compressed. So higher values should result in fewer textures being compressed/decompressed during the render and therefore a faster render.

    Where are you getting the info that it's lossless? I'm almost certain that it's not:

    https://blog.irayrender.com/post/54506874080/saving-on-texture-memory

    - Greg

    Yes, jpg files can hardly be compressed anymore, and png usually very little, unless using lossy compression.

    Remember the format that the image files are held in inside the GPU is neither jpg or png, but some internal format used by the renderer. Holding the data in jpg would make the performance terrible, as it would need to decode each time in order to get the RGB value at a particular pixel location. I suspect the format is some kind of compressed bmp format. 

  • Richard HaseltineRichard Haseltine Posts: 102,669

    Yes, it's lossy - that's why it can introduce artefacts.

  • SnowSultanSnowSultan Posts: 3,643

    So yeah, uh about my original question...does anyone know what determines whether a texture is compressed at Medium or High values? I still don't understand the purpose of this entire set of options because I can't get any actual data about differences in render times or in rendered texture quality.

     

  • HavosHavos Posts: 5,400

    Another reason you may not be seeing the compression artifacts depends on the size of your GPU. If the render easily fits into the GPU VRAM, then little or no compression would take place. Thus even if your Medium/High values are set quite high, you would not see the difference if there was no need to compress. To see the difference you would need to ensure the render got close to the VRAM limits, thus forcing the renderer to apply the compression more harshly. I am fairly certain that the compression rates vary as I have rendered the same scene on a 4GB card and also on an 11GB card, and the latter used a lot more VRAM for the same scene.

  • SnowSultanSnowSultan Posts: 3,643

    OK, that actually makes a lot of sense now that I think about it (and I feel dumb for not thinking about it now, haha). I have a 980ti with 6 gig of VRAM and for some reason, I kept assuming that texture maps were always being compressed based on the values I entered in that panel. Thank you very much for pointing that out.

    Following that logic then, do you think the Medium and High values are the compression amounts used based on the remaining available VRAM? (so if my values were 1024 medium, 2048 high, it would start compressing them to 2048 at around 4 gig used, then to 1024 at 5 gig used, etc, something like that?).

  • HavosHavos Posts: 5,400

    OK, that actually makes a lot of sense now that I think about it (and I feel dumb for not thinking about it now, haha). I have a 980ti with 6 gig of VRAM and for some reason, I kept assuming that texture maps were always being compressed based on the values I entered in that panel. Thank you very much for pointing that out.

    Following that logic then, do you think the Medium and High values are the compression amounts used based on the remaining available VRAM? (so if my values were 1024 medium, 2048 high, it would start compressing them to 2048 at around 4 gig used, then to 1024 at 5 gig used, etc, something like that?).

    I am not sure how the algorithm works, but I guess that if the renderer believes that available VRAM will be tight (ie at risk of going over the limit), then images above 2048 would get a high level of compression, whilst those over 1024 would get a lesser amount of compression. I would assume that all textures over 1024 would be subject to the compression the moment it feels it needs to, and the high and medium represents the level of compression rather than the priority, but I can not be sure.

  • Richard HaseltineRichard Haseltine Posts: 102,669

    As far as I know images are compressed solely on the basis of their size.

  • SnowSultanSnowSultan Posts: 3,643

    So are we right to assume that when video memory runs low, textures with a size equal to the value set in the Medium setting will be compressed somewhat and textures with a size equal to the value set in the High setting will be compressed heavily? I understand the reasoning for the compression now, but still not sure as to what the differences are between Medium and Heavy and how the textures are degraded based on those two values.

  • outrider42outrider42 Posts: 3,679

    I don't think it compresses based on available GPU memory, but more on the settings used and the size of the images as Richard said.

    Set it too high and you may see the texture bleed as you were told. Once you reach a certain point to where the image does not bleed or artifact, then you hit the sweet spot. But this sweet spot depends entirely on the textures being used and can be different from scene to scene. Just keep it high until you find a scene where you need to change it. I suppose if you batch render a lot, then it would be logical to set it around 4096 to be sure all the images are covered. But if you render one at a time, you can keep it higher for max speed and only change it when you believe you need to.

    It is hard to get a straight answer, because the answer can be different for each scene. So one person might see obvious differences with the specific textures they use, but somebody else may see no difference. You can experiment a bit with something you typically do and see if you can spot a difference.

  • AlienRendersAlienRenders Posts: 793

    Texture compression tends to use DXT3 or DXT5 (or DXT1 if it has no transparency). They compress at a 4:1 (6:1 for DXT1) ratio from the uncompressed version. IOW, they are one quarter the uncompressed size. The file format like JPG, PNG, etc. don't mean anything as the image is decompressed before being recompressed into DXT3 or DXT5. So they may end up being larger than their file format counterpart (such as JPG) even with compression. This kind of compression (DXT) takes 4x4 blocks of pixels and compresses them into 128 bits (64 bits for DXT1). It is a lossy compression. The settings you use for high threshold means that if the texture size is larger than what you specified, it will compress them if needed. The setting for medium threshold means that any texture between that setting and the high threshold MAY be compressed at the program's discretion if DAZ Studio still needs to use less video RAM. Smaller textures are not compressed.

    In short, the high threshold specifies the size of the textures that get compressed first if needed. (Note I'm not certain if DAZ Studio always compresses textures larger than the high threshold or not. I would think it would only do it if necessary.)

    Texture compression isn't useful only for saving on video card memory. It's also useful to speed up the start of the render as it has 75% (83% for DXT1) less data to transfer. This is somewhat offset if the textures aren't already compressed in main memory.

    There is no heavy or light compression. A texture is either compressed or it isn't. The compression ratio is always the same (except for DXT1, but that's based on lack of transparency).

    https://en.wikipedia.org/wiki/S3_Texture_Compression

    I've programmed many 3D engines using texture compression. Colour bleeding tends to happen mostly with overlapping textures that don't align on a 4 pixel boundary (as colours are compressed in 4x4 blocks). Transparent texture can have their alphas have artifacting. Opaque textures should rarely have artifacting. You can get artifacting on opaque textures if you have very high frequency data (checkerboard patterns with many colours, alternating colours, colour strips, etc.), but for the most part, this should not be an issue.

     

  • FishtalesFishtales Posts: 6,162

    I have no idea how it works but I have Medium Threshold at 4096 and High Threshold at 16384, the highest it will go, I also have the Environment Lighting Resolution set at 16500 as that is the highest that HDRI come in, and everything seems to work fine on my laptop which is CPU only. Renders can take anything from minutes to days to render but I have no idea if that is normal or not as I have never had a Nvidia card to see the difference :)

  • SnowSultanSnowSultan Posts: 3,643

    Alienrenders, thanks for that detailed explanation. Assuming most of my textures max out at 4096, would it be sensible to set the values at something like Medium 1024 and High 4096 in order to not compress anything under 1024 but keep 4096 whenever possiblbe?

    Fishtales, those sound like really extreme numbers, haha. You must have one mighty laptop if you can render CPU only and with numbers that will pretty much guarantee your textures will never get compressed.  ;)

  • FishtalesFishtales Posts: 6,162

    Laptop specs in my signature. Nothing special.

  • Digging-up and older topic, because the explanation is perfect and the topic keeps coming up. A handy (?), in Daz, next to the option, would be nice. As well as mentioning that this setting does NOT get saved with render settings, and it remains across all renders, once set. I also don't see the option to set them to default values... I believe the default values are 512 and 1024, which makes all these new HD 4096x4096 textures, feel kind-of pointless. The default settings decimate them into being highly compressed.

    You can easily see the results if you create a simple "primitive plane", and add a texture to it. Add a simple JPG and set it up to render in the same resolution as the actual image. I think I see it ALSO do this if you set an image to a background image... But, honestly, that is the most rediculous option to have in a rendering program. (Because it compresses the image, which shouldn't actually be "rendered", just "applied" as the background.)

    Use a 4096x4096 image as your JPG and also do a PNG sample. (The results will not be the same.)

    Try making a checkerboard grid and try a line-grid, in both formats.

    Try making a color gradient pallet. One that looks like a color-picker box, with nice solid gradient blends.

    Try setting values (both the same), to 256, 512, 1024, 2048 and ultimately 4096. Rendering each for comparison as a 4096x4096 rendering.

    You will clearly see how the images get compressed and how distorted they get. Most notably, you will see "cubing" which looks like repeating cubes that have a darker top left corner and a brighter bottom right corner. You will also see color-bleeding, blurring, and "banding" of gradients, like a horrible JPG or GIF compression setting.

    These values come into play when artists have created massive UV-maps which harbor crazy details that aren't needed, in most cases. Like having eyes with 4096x4096 UV-maps, or finger-nails... Pushing into more crazy, non-standard {non-square} values that have sizes of 68000x68000, for something like landscapes, HDRI images and skyboxes. (Now you know why many of your HDRI backdrops look like garbage, the default is 1024 for the high threshold, but most HDRI images are 4096x4096, or larger.)

    Unfortunately, this compression ALSO alters normal-maps and bump-maps, creating more distortions. Since it alters the colors, it changes the "normal" values, as well as "bump" values. Essentially erasing and deforming the details they should be adding to the rendering. Those are two other things, besides backdrops and HDRI images, which should be excluded from compression, or have a seperate compression thresholds, so they are a last resort compression, or devoid of any compression.

  • At one point normal maps were excluded from compression.

  • LeatherGryphonLeatherGryphon Posts: 11,666
    edited September 2021

    Hmmm..., back in the old days they used to have lots of accurate, up-to-date official documentation for this type of thing, s'plainin' in detail how such decisions are made by the program.  I miss the old days.  sad  But admittedly, bears in the cave were a bit of a problem.indecision

    Post edited by LeatherGryphon on
Sign In or Register to comment.