Daz Question about image quality in Renpy (Daz)

[Niteowl]

If I make art for a game using DAZ, should I match the default renpy format
HD 720 16:9 1280x720
or go better and make images in Full HD 1080 1920x1080

What's the standard for most games? I Know the 1080 would look better, but it would also use more memory and make the file bigger if I use a lot of images

Any thoughts?

 

[mickydoo]

1920x1080 is the best, I render them at 3200 x 1800 and scale them down to 1920x1080. Save them as a jpg in photoshop or something at about 8 - 10 quality, don't use the DAZ default .png as they are huge.

 

[anne O'nymous]

If I make art for a game using DAZ, should I match the default renpy format
HD 720 16:9 1280x720
or go better and make images in Full HD 1080 1920x1080

1280x720 is just the generic format used by the SDK. But at anytime you can edit gui.rpy to replace gui.init(1920, 1080) by the resolution of your choice. And you don't need to worry about the screen resolution of the player, Ren'py will automatically scale everything to fit it if it's smaller than the game resolution.

 

[redknight00]

Just to add on what others already said, WEBP is a good format for space-saving, there's virtually no quality loss for 90%+ compression and for that, it's the most used format for crunched versions in f95. Also, remember to keep the original images as they are exported from Daz and a back up to be sure, even if you publish lower res and in a different format, you never know when you might need the originals (and they make good bonus rewards for patrons).

 

[anne O'nymous]

Also, remember to keep the original images as they are exported from Daz [...]

Talking about this. Generally game authors make their low-sized version by (over) compressing the images. But it's also possible to do it by resizing them. You've the high-quality version at 3200 x 1800, the regular version at 1920x1080 and the low-size at 1280x720. Just resize the images and change the value of gui.init according to the version, and it's done.
The automatic scaling of Ren'py works in both way. So, you can have a game configured at 1280x720 and see it in full screen at 1920x1080. And generally a 1280x720 image resized to 1920x1080 loose less in quality than a 1920x1080 image compressed to reach the same size.

 

[Niteowl]

Thanks for the replies guys....
But now a couple of questions come to mind...
1 ok renpy can be customized in many ways...so many formats are possible.... but which one would you recommend. The best possible images 3200x1800 seems overkill since they will be compressed or resized....1920x1080 seems sufficient.

2 someone mentioned saving the files with photos hop or other programs.... not sure how that would work. I usually just save the image with Daz as a jpeg or png file.... I guess I'd have to export the file before saving it.

 

[mickydoo]

The idea behind rendering at 3200x1800 and resizing to 1920x1080 is this. 3200x1800 is what, half as much again. If it takes 10 minutes to render out as 1920x1080, in theory, it should take 15 minutes to render out as 3200x1800, but it doesn't, only takes 12 minutes, but the thing is you can render it for 8 minutes and sizing it down removes any imperfections. That is the theory anyway. The 1920x1080 my be sufficient for you, I have been doing it my way for ages so it's just what I do.

Saving the file in DAZ as a PNG is massive, 5 to 8 MB are my last ones, saved as a JPG in photoshop they are 500KB to under a MB. I have never saved a JPG out of DAZ but they still would be bigger than photshops JPG.

Most of my files go via photoshop anyway for post-work, even it's just to brighten it or adjust levels.

 

[Niteowl]

The idea behind rendering at 3200x1800 and resizing to 1920x1080 is this. 3200x1800 is what, half as much again. If it takes 10 minutes to render out as 1920x1080, in theory, it should take 15 minutes to render out as 3200x1800, but it doesn't, only takes 12 minutes, but the thing is you can render it for 8 minutes and sizing it down removes any imperfections. That is the theory anyway. The 1920x1080 my be sufficient for you, I have been doing it my way for ages so it's just what I do.

Saving the file in DAZ as a PNG is massive, 5 to 8 MB are my last ones, saved as a JPG in photoshop they are 500KB to under a MB. I have never saved a JPG out of DAZ but they still would be bigger than photshops JPG.

Most of my files go via photoshop anyway for post-work, even it's just to brighten it or adjust levels.

Very interesting. Thank you for the explanation. One problem for me is that I don't have photoshop atm

 

[mickydoo]

Gimp is free, it's very similar, I just have never really used it.

 

[Niteowl]

Gimp is free, it's very similar, I just have never really used it.

I hate to bother you but I have one last question (probably a stupid one but I'm a writer by trade rather than a graphic artist...although I've been dabbling with DAZ for a while now)

I downloaded GIMP (and I have a free version of Photoshop somewhere)....
but I don't understand what you mean by "saving the file in PS/whatev instead of saving it in DAZ"
I thought any render done with DAZ has to be saved with DAZ first..... Do you mean you save it, then open it in PS and re-save it I mean, I made a render in DAZ, just for testing, maybe I"m stupid but I really don't see any way to move the file to other programs before saving it.

I'm really sorry if it's a stupid question but yeah, I have a lot to learn

 

[mickydoo]

DAZ by default saves it as a PNG I think (it should), PNG is the best quality you will get, in render settings/general you will see image name and there is file type drop-down next to it, you can check it. And yes, open it in gimp and just save it again as a JPG.

Thats for a final scene with background and everything, if its just a model you want to show off in here or something you can just leave it as is.

 

[Saki_Sliz]

I find if you save as .png, and then use Gimp to export as a different .png, it's compression algorithm can do a fine job competing with .jpg.

I have also seen other posts on this site talking about using websites and programs to further compress images, but I have found that few can compete with Gimp's compression algorithm.

 

[Rich]

With JPG, you have options for how much you want the image compressed - JPEG has a size/quality trade-off capability. You can have DAZ save directly as JPEG, however it saves at a very high quality level - more than usually necessary in a game. Not as big as PNG, but still... So opening in another program (like GIMP) and re-saving allows you to compress more, at the cost of a small loss of image quality. (Usually not noticeable.) Usually the programs have options to allow you to make the size/quality tradeoff.

Personally, I use ImageMagick to recompress the files, since it allows you to do things in batch. But I'm an old command-line guy, so it might not be for everybody.

 

[IdarksoulsI]

Talking about this. Generally game authors make their low-sized version by (over) compressing the images. But it's also possible to do it by resizing them. You've the high-quality version at 3200 x 1800, the regular version at 1920x1080 and the low-size at 1280x720. Just resize the images and change the value of gui.init according to the version, and it's done.
The automatic scaling of Ren'py works in both way. So, you can have a game configured at 1280x720 and see it in full screen at 1920x1080. And generally a 1280x720 image resized to 1920x1080 loose less in quality than a 1920x1080 image compressed to reach the same size.

Just to make sure I understand you correctly, you say downscaling has better results than upscaling in Renpy?
Also, one other question on the same topic. I'm currently working on a mod for a game where the image resolution is 1000x720 but the art files in layer gimp format are 2000x1440 pixels. Can I use both of them (and renpy scales them automatically) or do I have to use the smaller ones so all are the same size?

 

[anne O'nymous]

Just to make sure I understand you correctly, you say downscaling has better results than upscaling in Renpy?

Not exactly. I say that with the same quality factor, an image with a smaller resolution is, obviously, also smaller in size, this while keeping a better quality level than a compressed version of the same image.

Lets say that you have a 3200x1800 image that need 1Mo, and that down scaling it to 1920x1080 reduce the size to 500 Ko ; which is a reasonable premise (at least in the ratio). Globally you'll remove 1 pixel every 3 pixels, which is enough to reduce the level of noise, but will still keep all the details visible. And by doing this, you've reduced the size by 50%.
But if you try to achieve the same size reduction by compressing the original 3200x1800 images, the compression will start to blur the image, and so imply a loose of quality.
Now, when you configure Ren'py to works at 1920x1080, and fill it with CG at a 1920x1080 resolution. The size of this distribution will obviously be smaller than the "high quality" distribution (3200x1800 configuration and CGs). Then, if the player manually upscale the windows to fit his 3200x1800 screen, Ren'py will automatically scales the images. For this, every 2 pixels it will add a pixel based on an interpolation of the surrounding pixels. The result will soften the details, but be near enough to the original color of this pixel to not blur the said details ; therefore the quality will be lowered, but less than by the compression approach.
So in the end, you have a game that need less size, like a compressed version, while still having a better visual quality than the said compressed version.

Obviously, using this way you can't compete against super crunched version of the game, that can reach a 90% reduction rate. But you should be able to reach a reduction rate between 35% and 45%.
Even if the ratio is smaller from 1920x1080 to 1280x720, a game like Ecchi Sensei, which need 16.6 Go, could have had an official "low size" version sized at 1280x720 that would have kept a good quality, but still have a size around 12 Go, which would already be a good save.

Also, one other question on the same topic. I'm currently working on a mod for a game where the image resolution is 1000x720 but the art files in layer gimp format are 2000x1440 pixels. Can I use both of them (and renpy scales them automatically) or do I have to use the smaller ones so all are the same size?

Ren'py only scales the images when explicitly asked (by using the

You must be registered to see the links

displayable by example), or when the game windows is resized (either automatically to fit the screen resolution, or manually).
So if you directly use 2000x1440 images in the game, Ren'py will display them at full size on a 1000x720 windows, which will lead to half of the image being not seen.

 

[IdarksoulsI]

Not exactly. I say that with the same quality factor, an image with a smaller resolution is, obviously, also smaller in size, this while keeping a better quality level than a compressed version of the same image.

Lets say that you have a 3200x1800 image that need 1Mo, and that down scaling it to 1920x1080 reduce the size to 500 Ko ; which is a reasonable premise (at least in the ratio). Globally you'll remove 1 pixel every 3 pixels, which is enough to reduce the level of noise, but will still keep all the details visible. And by doing this, you've reduced the size by 50%.
But if you try to achieve the same size reduction by compressing the original 3200x1800 images, the compression will start to blur the image, and so imply a loose of quality.
Now, when you configure Ren'py to works at 1920x1080, and fill it with CG at a 1920x1080 resolution. The size of this distribution will obviously be smaller than the "high quality" distribution (3200x1800 configuration and CGs). Then, if the player manually upscale the windows to fit his 3200x1800 screen, Ren'py will automatically scales the images. For this, every 2 pixels it will add a pixel based on an interpolation of the surrounding pixels. The result will soften the details, but be near enough to the original color of this pixel to not blur the said details ; therefore the quality will be lowered, but less than by the compression approach.
So in the end, you have a game that need less size, like a compressed version, while still having a better visual quality than the said compressed version.

Obviously, using this way you can't compete against super crunched version of the game, that can reach a 90% reduction rate. But you should be able to reach a reduction rate between 35% and 45%.
Even if the ratio is smaller from 1920x1080 to 1280x720, a game like Ecchi Sensei, which need 16.6 Go, could have had an official "low size" version sized at 1280x720 that would have kept a good quality, but still have a size around 12 Go, which would already be a good save.




Ren'py only scales the images when explicitly asked (by using the

You must be registered to see the links

displayable by example), or when the game windows is resized (either automatically to fit the screen resolution, or manually).
So if you directly use 2000x1440 images in the game, Ren'py will display them at full size on a 1000x720 windows, which will lead to half of the image being not seen.

Ok, got you now, thx.

 

[Rich]

"Render bigger and shorter and then size-reduce the image afterwards" has been a very common piece of advice for dealing with the noise that iRay sometimes generates. I have to say that my own experiments on this have been pretty mixed.

The theory goes: Let's suppose you want an image at 1920x1080. If you render directly at the resolution, you may have to render a lot of iterations before the "fireflies" (random unconverged pixels that typically are much brighter than the surrounding area) are eliminated. So, instead, what you do is render at twice that that resolution - 3240x2160. Normally, you would expect to take as much as 4 times as long (since you're rendering 4 times as many pixels), but that's only if you render to the same quality level. Instead, you render for less time than you would have had to at 1920x1080. This will leave noise in the image, however one characteristic of iRay noise is that it usually (not always) is random isolated pixels, not large continuous areas. So when you then reduce the big image back to 1920x1080, that one bad pixel gets averaged with three other pixels next to it (since you have 1/4 the number of pixels in the final output), and thus the amount of noise in the final pixel is 1/4 of what it was in the original larger render. (Actually, it's frequently even better than that, because the "image shrinking" algorithms in GIMP and Photoshop are smarter than just "average each 2x2 pixel group into one pixel."

For certain images, this probably works. The trick is really knowing where to stop the big image rendering, since you rarely have any idea how long it will take for the original-size image to converge. (At least, I don't.) But there are people who swear by this technique. Personally, I do most of my rendering overnight using the batch rendering plugin from Renderosity, so it rarely matters to me how long the image is going to take. (Granted, I also have a hotter machine than many folks.) I tend to be rate limited by the amount of time it takes to prepare the scene (i.e. how many I can do in an evening) not by the rendering time. The one exception is animations, and since in those cases you'll have consecutive frames kind of "averaged together" by the video compression, I just usually dial down the quality level a bit and end up doing fine.

You mileage, of course, may vary widely...

 

[mickydoo]

"Render bigger and shorter and then size-reduce the image afterwards" has been a very common piece of advice for dealing with the noise that iRay sometimes generates. I have to say that my own experiments on this have been pretty mixed.

The theory goes: Let's suppose you want an image at 1920x1080. If you render directly at the resolution, you may have to render a lot of iterations before the "fireflies" (random unconverged pixels that typically are much brighter than the surrounding area) are eliminated. So, instead, what you do is render at twice that that resolution - 3240x2160. Normally, you would expect to take as much as 4 times as long (since you're rendering 4 times as many pixels), but that's only if you render to the same quality level. Instead, you render for less time than you would have had to at 1920x1080. This will leave noise in the image, however one characteristic of iRay noise is that it usually (not always) is random isolated pixels, not large continuous areas. So when you then reduce the big image back to 1920x1080, that one bad pixel gets averaged with three other pixels next to it (since you have 1/4 the number of pixels in the final output), and thus the amount of noise in the final pixel is 1/4 of what it was in the original larger render. (Actually, it's frequently even better than that, because the "image shrinking" algorithms in GIMP and Photoshop are smarter than just "average each 2x2 pixel group into one pixel."

For certain images, this probably works. The trick is really knowing where to stop the big image rendering, since you rarely have any idea how long it will take for the original-size image to converge. (At least, I don't.) But there are people who swear by this technique. Personally, I do most of my rendering overnight using the batch rendering plugin from Renderosity, so it rarely matters to me how long the image is going to take. (Granted, I also have a hotter machine than many folks.) I tend to be rate limited by the amount of time it takes to prepare the scene (i.e. how many I can do in an evening) not by the rendering time. The one exception is animations, and since in those cases you'll have consecutive frames kind of "averaged together" by the video compression, I just usually dial down the quality level a bit and end up doing fine.

You mileage, of course, may vary widely...

I render mine at the 3200x1800 until it is completed so technically scaling it down does nothing, BUT, I am not sure if the overall image quality is sharper, but I have convinced myself it is.

 

[Rich]

I render mine at the 3200x1800 until it is completed so technically scaling it down does nothing, BUT, I am not sure if the overall image quality is sharper, but I have convinced myself it is.

It is possible that it is. It's also worth noting that, by default, Daz applies a filter to its output that has an ever-so-slight blur effect. I suspect this is to cut down on "jaggies," although I don't know that for sure. Some people on the Daz forum have complained about it, however.

You'll find it on the Render settings tab, under Filtering >> Pixel. The default is a gaussian filter with a 1.5 pixel radius, but you can adjust either the type of filter, the radius or both.

There are a number of threads on the Daz forums discussing alternate settings. Here's one:

You must be registered to see the links

The mitchell filter seems to be a favorite for people that like tiny details.

So one thing you might consider trying is going back to your "original" resolution and tweaking the filtering a bit and see if you get the results you want without having to do postwork.

(Of course, if you then turn around and convert to JPEG, all that extra detail might get lost...)

 

[Deleted member 1121028]

The mitchell filter seems to be a favorite for people that like tiny details.

My lazy method: use mitchell as pixel filter and adjust radius from 1.2 to 2.0 depending how far/close the camera is.