Best render settings for web use?

A few of my renders look great in Daz Studio and Photoshop, but when I put them online, I see lots of artifacting. Particularly in gradient or shadow areas. Is there a way to render that looks best for web use?

Comments

  • Richard HaseltineRichard Haseltine Posts: 102,907

    Are you resaving them for web use? Do the tonal values look the same?

  • Those ThingsThose Things Posts: 1,134

    Are you resaving them for web use? Do the tonal values look the same?

    No, just rendering as jpegs right out of iray.

  • Richard HaseltineRichard Haseltine Posts: 102,907

    I'm not sure then - can you get a similar effect in Photoshop by moving the middle, grey triangle in Levels?

  • prixatprixat Posts: 1,590

    You could post one of the images to this thread and see if other users see the same thing.

  • ToborTobor Posts: 2,300

    It could be the online tool that "ingests" the image for whatever Web platform you're using (such as Wordpress). There are a couple things you can do:

    1. Daz Studio does not add DPI metadata to the files it saves. *Most* tools assume 72 or 96 DPI, but others, who knows. So before you upload, bring the file into Photoshop or other graphics program, and reset the resulution to 72 DPI. Don't reample. The pixel dimensions must remain the same, or else you'll enlarge or reduce unnecessarily.

    2. If your renders are very large, the online tool may not apply a nice downsampler. So do it yourself before you upload. Here, choose to resample the image at the destination size you want.

    3. You might get into the habit of saving master files in TIF or PNG format, both of which are lossless. That way when you maniulate and resave them, you won't compound the lossy artifacts that can occur with JPEG.

    4. Watch your file size (in megabytes). If the online tool has to resample, it may choose to apply a drastic quality setting for JPEG. Upload files that are already reasonable in size, to avoid the tool from going overboard.

    For all of the above, save the image to your local computer and look at its dimensions and file size. How do they compare with what you uploaded?

    If your uploads aren't being converted, then I don't know what to say, other than perhaps what you're seeing is the result of your browser doing a poor job displaying the image. This would be especially true if the image on the server is very large or very small, and is being fit for the display.

  • Those ThingsThose Things Posts: 1,134
    Tobor said:

    It could be the online tool that "ingests" the image for whatever Web platform you're using (such as Wordpress). There are a couple things you can do:

    1. Daz Studio does not add DPI metadata to the files it saves. *Most* tools assume 72 or 96 DPI, but others, who knows. So before you upload, bring the file into Photoshop or other graphics program, and reset the resulution to 72 DPI. Don't reample. The pixel dimensions must remain the same, or else you'll enlarge or reduce unnecessarily.

    2. If your renders are very large, the online tool may not apply a nice downsampler. So do it yourself before you upload. Here, choose to resample the image at the destination size you want.

    3. You might get into the habit of saving master files in TIF or PNG format, both of which are lossless. That way when you maniulate and resave them, you won't compound the lossy artifacts that can occur with JPEG.

    4. Watch your file size (in megabytes). If the online tool has to resample, it may choose to apply a drastic quality setting for JPEG. Upload files that are already reasonable in size, to avoid the tool from going overboard.

    For all of the above, save the image to your local computer and look at its dimensions and file size. How do they compare with what you uploaded?

    If your uploads aren't being converted, then I don't know what to say, other than perhaps what you're seeing is the result of your browser doing a poor job displaying the image. This would be especially true if the image on the server is very large or very small, and is being fit for the display.

    Great advice, just what I needed, thank you!!

  • Roman_K2Roman_K2 Posts: 1,253
    edited May 2017
    Tobor said:
    *Most* tools assume 72 or 96 DPI, but others, who knows.

    Ha, interesting information, thanks.  I'm reminded of the business rotating an image in Windows' picture viewer, which if I'm not mistaken is gives a lossy result if you save to disk.

    They say Wordpress is the most popular software, ever.

    I mostly save pictures destined for the web to about 1,024 pixels wide - so far no complaints and I think I'm being generous because (to me) most web pictures seem to be less than 100 kb, while most of mine I think are 150 kb or larger. In my major center there have been ads of recent for "4k UHD monitors! Curved format!! Immersive depth experience!!!" etc. but I think for an awful lot of people "the web" is a smart phone (800 pixels wide?) or a cheap tablet. Another trendicator may be that most people do not have/do not author for, 1920 x 1080 screen displays; indeed, many Wordpress templates have two thin columns on the sides, a large center column, and a lot of wasted space in my opinion. smiley

    A big issue for me is people "stealing" imagery. To make T-shirts and posters a size of roughly 5,000 pixels wide, 300 dpi (like if you are starting with vector graphics for type, say) is a good starting point, and then you want to scale any DAZ images to suit. In my mind I'm thinking if I'm giving them less at the outset then there's less for them to try and repurpose.

    I'm reminded of how, in art school ("Mad Men" style, early 1970's), we used to play a game where we would try to find "stolen" stuff, in commercial illustrations. I think the all time winner was some background doodles one of the teachers had done just out of his head, some SF like Martian walkers or something IIRC. We actually found this material repurposed, not once but TWICE! Ergo artist <BLINK>#3</BLINK> had blithely used the 2nd generation version of the walkers, for his reference! The cheek!!!

    Another tell-all is these DVD's and program discs floating around... not all of them are legit... just as an example Symantec's Ghost program was killed off at around version 15.0, and then revived as something else. If I'm not mistaken a lot of people complained and one of the last versions is now a free download... I've seen people selling this stuff (free software) while implying that it is the real deal - they put really nice labels on the DVD-R disc, and they print up the materials real good. Some people...!

    Sorry to wax on about piracy but it's arguably one of the issues when discussing artwork and the web, and JPEG compression values and so on.

    It escapes me (again)... how do you turn on the nice chiron ("DAZ Studio Render") for direct renders?

    Post edited by Roman_K2 on
  • FishtalesFishtales Posts: 6,162

    You don't have to set the ppi for web viewing, it is used by printer drivers to work out the dpi for printing size. Have a read at this, it is about scanning but is just as relevant for any image.

    http://www.scantips.com/no72dpi.html

    I save all my images for the web at 1000 pixels wide at 0 ppi if I am using Irfanview, or 1 ppi if using Photoshop as it doesn't allow zero :)

     If your images are being compressed by the browsers then there is something else wrong.

  • Roman_K2Roman_K2 Posts: 1,253
    edited May 2017

    That's an interesting page, scantips.com

    I guess I tend to pick "1024" as my main size as it seems to be a good middle choice (sort of) for various displays - again smart phone users will have a smaller screen, and most people don't demand 1920 x 1080 "HD" images to be a de facto standard on everything 24/7. Ok, for desktop wallpaper it's a "maybe" but for most things it's moot.

    For various reasons -- unless you are one of those people who posts every image they've ever taken FULL SIZE to a single Wordpress page, in one big long list of pictures, *sigh* -- most things are actually posted a lot smaller. And a tip of the hat to folks with low vision - my friend is legally blind and make no mistake, I'm trying to be *very* sensitive to her needs and the needs of people like her.

    Also, to me it seems logical that if I want the best pixel arrangements and smooth anti-aliasing for these abovementioned small web objects, I want the computation for the end result to be based, in most cases, on the LARGEST source data that can be conveniently created and stored on my equipment.

    I usually render in DS at about 2,222 or 3,333 pixels wide just because those are easy numbers to type. I then save the cropped and brightened/dodged etc., and resized-to-1024-pixels-wide, web-destined versions of those pictures at 72 dpi which I think is one of the default settings in Photoshop - larger densities mean bigger file sizes after all.  It is when I turn up the compression in my image editor (for example Paint Shop Pro) that I see artifacts. I'm with Prixat above - the user ought to post some specific samples, perhaps with text annotations as to where exactly in an image the artifacts seem to be showing up.

    I used to save things to print on a Xante imagesetter [a fancy laser printer] and for this (and making T-shirts on Cafepress.com or Spreadshirt.com) large file sizes are important. Bottom line in a fashion image, say, the number of pixels that remain in the final result that combine to make up the model's glossy eyes, say, is important. You don't want to muddy that up with too few pixels and too much compression.

    In this sample Iray render of G3F (I have actually never rendered G3F before, go figure. This here took all night on my computer) the plane of the forehead is what, 300 pixels across. When you get down to the nitty gritty the white dots that represent the reflection of the studio light, in the pupils are at most FOUR PIXELS ACROSS!  The standing figure would have to be over 1,000 pixels high any way you slice it or it cannot be displayed properly - this is the dilemma that everyone faces at the... moment of publishing if I may use that expression. Is it enough for a web illustration (or a book cover?) - probably. A billboard? Nope! An advertisement for a new mascara? Don't think so. What to do?

    The only thing you can do is be careful with any compression and... you can start to re-size. If the latter then turn up the contrast and/or levels and/or saturation and vibrance to keep those dots as punchy as possible. Remember, it's only four pixels that you have to play with; if you're going to take it down to two (so that the standing figure isn't as tall?) then you want the remaining two pixels to be well-defined.

    If it's a mascara ad in a magazine then you're going to have to re-think your layout, going back to something like 5,555 pixels wide or larger for the source image, then increase the density to 300 or 600 dpi in an image editor AND THEN turn up the contrast and add a bit of sharpness to the lashes after carefully lasso'ing them. And you're only going to be able to show one eye. laugh

    It's all relative.

    g3f-eyes.jpg
    300 x 250 - 67K
    Post edited by Roman_K2 on
  • FishtalesFishtales Posts: 6,162

    Print size is based on pixel size and dpi required. For most printing anything from 230 to 300 ppi is fine although some printers require 600 ppi for fine print setups.

    For the size of print required at the desired print density there has to be the right number of pixels in the image for the printer to achieve that.

    For a 12x20 print at 300dpi then the image has to be 3600x6000 pixels or greater, it can't be smaller unless you print it at a smaller ppi, say 250, or at a smaller print size say 6x5. Printing the above image at 6x5 inches would allow the image to be printed at 600 ppi but to have it printed at the 12x20 inch size it would have to be 7200x12000 pixels, to print this at 300ppi would give you an image of 24x40 inches.

    The 24x40 inch print would be a huge size but it doesn't need to be printed at 300 dpi as it will be viewed from a greater distance by the viewer so the dot density can be lower. Look at a 40 foot billboard close up and you will se all the dots that make up the image as they can be printed as low as 4 ppi. Viewed from a distance the viewer doesn't see the dots because our brain 'sees' a complete image.

  • Roman_K2Roman_K2 Posts: 1,253
    Fishtales said:

    For a 12x20 print at 300dpi then the image has to be 3600x6000 pixels or greater...

    Very interesting, to think of it in terms of a general "scale", and minimum values etc., for "small, medium, or large".

    It shows you how many billboards I print because I never really thought of the dot distribution and resolution that way. Even though for years I used pass an actual billboard at a distance of two or three feet!  It was hung on the wall of a building, quite low to the ground. So thanks for that.

    So hopefully there's a lesson here - keep it big at the outset so that you will have something to process down to the size (in pixel width) you'll be using for the web.

    And by the way my sample render was 3,333 pixels wide. Here's a screenshot of my (transparent) TIFF file after about 250 iterations.

    g3f-screenshot-actual-tiff-wb3333-pixels-wide.jpg
    1024 x 576 - 240K
  • ToborTobor Posts: 2,300
    Fishtales said:

    You don't have to set the ppi for web viewing, it is used by printer drivers to work out the dpi for printing size. Have a read at this, it is about scanning but is just as relevant for any image.

    This doesn't account for automatic conversion done my some Web/blog software when images are uploaded. There's no guarantee your uploaded image is the same that will be displayed. Some Web platforms written better than others, but it's entirely possible for the software to misconstrue an empty PPI metadata and perform too much scaling. If you know a Web platform isn't messing up your image you can keep it as is. But when results are unknown, I think it's always best to add the metadata before uploading.

  • FishtalesFishtales Posts: 6,162

    I'm not sure I understand where you are coming from. If I use an image of 1000 pixels with no dpi set and one with dpi then the software will compress them both no matter what as it will be compressed to a memory size not a pixel size. Viewing the image to get its resolution size will show the zero pixel resolution as the video resolution of the viewing screen, 72 dpi, 96 dpi or 110 dpi or whatever the user has it set as,  and it will show the resolution size from the data of the 1 ppi or the 300 ppi as that is what it reads from the uploaders data. Compression is based on image memory size not on pixel size although the more pixels the more memory used :)

  • ToborTobor Posts: 2,300

    When you upload an image to many Web sites, it's passed through a server-based image management tool (in fact, D|S uses one such popular tools as part of its graphics producing features). Some of these tools are better implemented than others.The DPI/PPI of the image is metadata, and the more metadata you provide, the more likely you'll end up getting what you expect.

    Say you have an image that's 3000x3000 pixels. This is too large for ingesting into most blogs or content management systems for display on a page. So the software will resample the image, but how will it be done? Without a specific DPI, it's based on whatever assumptions the software uses. Suppose it's written to assume 240 or 300 DPI, common resolutions for images directly uploaded from digital cameras. For our purposes, let's imagine that resolution is 300 DPI. If the software simples resamples to 72 DPI, amnd the maximum target size is 1000 pixels, will reach its target in one step, and produce an image at 720 x 720 pixels. Is that what you want? Or would you prefer it simply take your 3000x3000 image at your intended 72 DPI, and scale that to meet the Web site requirements? That same 3000x3000 image is now reproduced at 1000x1000, not 720x720. Bigger image, and likely what you expected to get.

    Unless you know the behavior of the Web site, it is always better to provide the metadata that helps the software do its job,. You can't assume graphics programs, cameras, and other devices to *always* produce 72 DPI images (they don't), and you can't assume all server software will work the same.

  • FishtalesFishtales Posts: 6,162

    Image software doesn't produce dpi they produce pixels. If an image is 3000 dpi and is viewed on any video source it is still be 3000 pixels no matter what the dpi setting is in the metadata it is only there for printers so they know what size of printed image is required. Web software that resizes images will base it on pixel and memory size. The 3000 pixel image will be resized to the pixel size it requires and then will resample the image to a memory size. It is the resampling to memory size that causes the artifacts in an uploaded image not what dpi is set. Software for the web isn't interested in ppi or dpi only in pixel size and memory usage, you can set the dpi/ppi to anything you like it wont make any difference to how the image is handled by imaging or compression software. My images at zero ppi show up as 104 ppi on my laptop because that is the screen resolution I have it set at. In Photoshop and Irfanview they show up as one or zero respectively because that is set in the metadata. The images from Studio have no dpi/ppi set but the images from my camera come with a 300 ppi set but that is so the images can be printed direct from the camera and a printer needs that information. They still only take up 4288x2848 pixels at full size on my laptop and as it is only 1376 pixels wide I have to scroll to view it, on a larger screen it will show at the same size but with less scrolling. Setting it to zero ppi makes no difference and also makes no difference to the memory size but it does make a difference to the size of print that can be produced.

  • ToborTobor Posts: 2,300

    I'm sorry you're still not understanding this. The problem has NOTHING to do with resulting pixels, but how the software is configured to scale an image with unknown metadata. I work with open and closed source image manipulation software all the time, and they all behave differently when given incomplete input. How well an image is ingested into a content management system -- blog, forum, whatever -- is highly dependent on how the developer has implemented the conversion software. 

    How your images appear on your laptop is totally irrelevent. We're talking about images that have modified by automatic software.

  • FishtalesFishtales Posts: 6,162

    Why would any software that is configuring an image for web view be interested in data for printing? Surely it should only be interested in number of pixels and memory size because those are the only two things it needs to reconfigure for the software used. I have images on quite a few different sites, blogs and forums and there isn't one where the image has been degraded because there is no ppi data. I have seen them so compressed that there are artifacts showing but that is because when they are compressed too far there is too much information thrown away, even on some images where I have left them at 300 dpi because I have forgotten to clear it when resizing.

    Wordpress was mentioned as a platform that changes the way images are viewed and degrades them if the dpi is set wrong. Not according to these sites.

    https://www.mattcromwell.com/optimizing-images-for-wordpress-like-a-pro-for-free/

    https://daraskolnick.com/image-dpi-web/

    There are a lot more sites who believe that dpi/ppi is irrelevant including the official Wordpress site.

  • ToborTobor Posts: 2,300
    edited May 2017

    Both of your examples are irrelevent. The Wordpress article talks about manual image configuration and ignores the many other CMS platforms, versions of Wordpress, and alternative plugins. There is no such thing as one Wordpress. The second talks about automatic resolution adaption by the graphics driver in the PC. Is that what we're discussing? No.

    I've already given you an example of how CMS image ingress software may misinterpret your intention. If the majority of the uploads to a CMS are camera images (which they are), then it's very reasonable for the software, when no DPI metadata is present, to simply assume a 300 DPI resolution, and *resample* (not just change the metadata) at 72 DPI in order to shrink the image, which may result in a smaller image than it needs to be. That's the easiest fix to ensure the resulting image fits the pixel dimensions constraints imposed by the Web site. You might not have noticed a difference in images, but that doesn't mean it doesn't take place.

    Over compression of JPG is a separate issue, and is a setting in the ingress plugin. They're simply being cheap and want to save bandwidth. Since the OP didn't provide an example of the quality loss seen, it's hard to know what it was caused by.

     

    Post edited by Tobor on
  • FishtalesFishtales Posts: 6,162

    I have never* used a CMS, my website was first hand coded in HTML on an Amiga and then went to a Windows machine and then I implemented CSS, all hand coded :) It would also seem I am not the only 'web designer', in quotes as I don't see myself as one only having designed three, who doesn't know about DPI making a difference when designing using a CMS.

    https://www.webdesignerdepot.com/2010/02/the-myth-of-dpi/

    * I'm saying never but I have tried Joomla, Drupal, Wordpress and Adobe GoLive but never really got on with them and just slogged away with hand coding.

  • ToborTobor Posts: 2,300

    I don't like CMSs for my own sites, either, as they can be a real bother. But I've had to work with them in various capacities, including as a graphics program developer. Most CMSs use an open source API such as ImageMagick or FreeImage. D|S uses FreeImage as part of its graphics repertoir. While these APIs provide fairly standardized methods for manipulating graphics, how they do it is completely up to the application programmer, so there is considerable variance.

    While it's true that DPI has little meaning for Web site or desktop app graphics display, any time there's a piece of automated software in the loop, as there is for Web sites that limit graphics size, there can be trouble. The really good conversion apps will even take into consideration gamma and document profiles, if the images are so tagged, and use this meta data accordingly for other post-processing. But there are times when it screws that up. too..

    So I always advise this: if you want to maintain as much visual fidelity as possible, do any image processing yourself before uploading. This may include saving with a profile that will maintain color faithfulness in Web browsers that respect tagging. While the author of the blog you pointed to is correct in saying browsers don't care about DPI, that's missing the world of automated conversion tools that look for clues as to how to best transform an image for their system. It's always better to do this work yourself. If the site has a maximum of 900 pixels on a side, for instance, manually resample or crop to fit that limit. There are fewer surprises that away.

  • FishtalesFishtales Posts: 6,162

    I bow to your expert knowledge of something that I, as a user, shouldn't need to have knowledge of or need to bother about. If that is what is happening all over the web then there is something far wrong with how images are implemented on user generated sites, I am thinking along the lines of Facebook, Pinterest etc. Sites where users are requested to upload their images shouldn't degrade them to the point where it is A) obvious or B) not what the uploader wants. It isn't something I will lose sleep over though and I will continue to save and upload my images the way I have always done for the past 20 years or so :)

    Thank you for sharing your expert knowledge though, very thought provoking and insightful. I always thought that the degradation of images was because the receiving software was over compressing the files on upload and causing .jpg artifacts, I now know that isn't always the case.

Sign In or Register to comment.