Disfigured/compressed images set as backgrounds, when not compressed.

JD_Mortal

I am trying to render a 1080p image as a background in a 1080p scene. The image is an uncompressed PNG, but that doesn't matter.

The end result is a horrible cubic deformed reproduction of the actual image. It looks like there are 8x8 or 12x12 blocks of some kind of compression, which are disfiguring/destroying the original image.

The effect I was going for, was to have the image show as a background. Thus, saving me a step in post-work and not having to deal with the incorrect alpha being saved in the models final renderings.

(The alpha is not rendering to the "color" of the model, it renders to "black", causing a black outline if not used on a black background. Which can not be set to any "color", except the default black. It should be rendering to the color of the models color, of that pixel... But, instead, it is blending the alpha of the color, to the unseen black background, and saving that "color" instead of the models rendered color.)

Fishtales

Are you using Window/Panes/Environment/Backdrop or putting it into the Dome? It wont work in the Dome but should be fine as a Background.

JD_Mortal

I use the "Environment" pane, backdrop->background->image, where it should just be replacing the "alpha" with the actual "unrendered" image/color that you set. (Unrendered, but stretched to the size of the rendering, obviously. Which is the same size as the original image, so no "stretching/deformation" should be happening.)

I would post the results, but the forum isn't uploading attachments...

JD_Mortal

Trying this image-host...

Original image sample. (4K PNG image was too large to "attach")

 

This is the output, when rendered... (No, this is NOT zoomed-in... This is the final pixle-pixel rendering. Looks like I am looking through a screen.)

 

I have added some noise to the original image, in an attempt to reduce the "boxing" deformity that it renders. It is still quite clear in the final render.

Again, this is an uncompressed PNG, 4K image, set as the "background" in a 4K rendering. Thus, there should be no image compression or alteration.

The "box pattern" is actually an odd "gradient" disfiguration. I forget what it actually measures at... but the top-right is darker and the bottom-left is slightly brighter than the original image colors, of each of those boxes, when overlapped and a "diff" comparison is made in paint-shop, as layers. Looks like horrible JPG compression or some other nasty PNG compression variant going-on. But within Daz3D, since it shouldn't be entering Nvidia/IRay at all... It is just a background that the IRay rendering should be stacked on top of.

Almost looks like it is scaling it down to 1/8th the size, then blowing it back up to 4K size... (That would be 720p resolution downscaling, then 720p -> 4K upscaling. Which makes no sense to do, going from 4K original to 4K rendering.)

DrNewcenstein

I think it's applying the background image to a low-poly environment sphere that you can't otherwise manipulate, and that's where the jagged shapes come from.

JD_Mortal

I found-out what it was, and I don't like it...

In the "advanced" settings, for rendering...

The background seems to be subject to "texture compression", though it should not be! (Daz has to fix that.)

I have to set the minimum and maximum values to the widest 4K resolution, to stop it from compressing the image. Great, now NONE of the objects images will get compressed, when needed. That should be depth-related, not a fixed value-set. (Depth related, as in, the relative "size" of the image on the object, in the final render.)

Fishtales

I just tested two of my images in the Backdrop, one 6688x4192 TIFF and a 1000x664 JPG in my normal render size of 1280x720 and there weren't any compression artifacts and as far as I know I have never changed any settings. I do run with the Texture Compression/High Threshold at 16384 and Medium at 512 all the time so that is where the difference might be.

JD_Mortal

Try rendering them at 4K resolution... 3840 × 2160

I assume that is why they never "saw the issue"... They never rendered higher than 1080p with a "backdrop image".

JD_Mortal

Default Medium is 512

Default High is 1024

Both had to be set to 4096, to stop compression. (I could have possibly used the actual width of 4K resolution, but I stuck with the "squares" rule.)

Fishtales

As expected the 6000 pixel TIFF rendered fine but the 1000 pixel JPG had artifacts because it had been resized to 3840 pixels. That would happen in any program as there is enough pixels in the 6000 TIFF but pixels had to be added to the 1000 JPG for them to fit in the 3840 pixel render space.

JD_Mortal

I'll have to see if I can drop that 4096 number down a bit then. I hate keeping it that high, but soon it will not matter much.

I am getting four "Titan V" cards, to replace my "Titan X" card.

Fishtales

The way I normally do it is to use an image at the same dimensions as the render which means there is no compression or re-sizing to make it fit. The Texture Compression/ High Threshold should also be the same or higher than the image used.

DrNewcenstein

JD_Mortal said:

I'll have to see if I can drop that 4096 number down a bit then. I hate keeping it that high, but soon it will not matter much.

I am getting four "Titan V" cards, to replace my "Titan X" card.

From what I'm seeing here, the Titan V won't be able to take advantage of Nvidia's NVLink, so you won't be able to combine the HBM2 VRAM (or whatever the heck it is that's supposed to support NVLink). At least not without a dedicated NVLink device like the Grid rack or a VCA. We were supposed to be able to get it via the SLI connector, last I heard. Guess that was too user-friendly and affordable.

But still, 4 Titan Vs is 4 Titan Vs, so congrats.