Anim8or Community
General Category => General Anim8or Forum => Topic started by: Alpha2 on July 27, 2016, 07:42:11 am
-
I'm working on a project that requires me to edit rendered Anima8or images for a printed book, but the generally held rule is that 300 DPI (or in some cases pixels per inch) is the minimum size for a decent print of a non anti-aliased image (which it needs to be for editing purposes since aliased images aren't as sharp). The Problem is every large render I do seems to read below 300 in Photoshop (254 to be exact.) I'd really like the images to be as sharp as they can and raising the resolution after the rendering will just end up hurting the sharpness.
Is there any way to up the resolution of the file output from 254 to 300?
(I know some people say PPI is not DPI but to be on the safe side I've always kept PS files set to that res. to avoid the issue entirely with clients.)
-
You can use an image manipulation tool to change the DPI specified in the image file to whatever you want without changing the number of pixels in the image file. I've used Irfanview to do this. I'm sure other programs can do it, too.
You do have to make sure you render the image at a size that you know will include the right number of pixels. e.g. if you want it to be 5" x 8" on a 300dpi page, render it to be 1500x2400 pixels.
(I assume you're aware that rendering an image at 2x the final image size and then downscaling it usually produces a better quality final result than rendering at the final resolution.)
-
No I realize that, but let me see if I can describe the confusion I'm running into...
Lets say I'm working on a comic book. The finished size of a page is (very) roughly about 2100 x 3070 for a 7x10" image at 300 dpi
If I produce a similar image on Anim8or with the same dimensions I get an image that fits the page layout, but at 254.
I wanted to know is there anyway to change the resolution so it just gives me 300 without having to alter the size of the image itself. I ask mostly because the 254 seems like a strange number to land on without a reference for why the program chooses that I'm used to programs like Illustrator or Photoshop that just automatically give you control over the numbers from the outset. Sure, I might be able to squeeze 300 out of the image through resizing but I've run into issues with pixel blurring in the past when clients supply me with sub print quality images which makes me gun shy about using that method and potentially wasting time. It's not so much that I don't want to do the math as it is I'd like to try and remove steps that leave room for error.
-
Anim8or has a limit of maximum 4096x4096pixels per picture with default 300x300 DPI so that shouldn't be an issue.
Just be sure to save image as .png file with 100% quality, not as the default .bmp- maybe that makes the problem.
see attached example, can you use it properly as you said?
-
Slex, Actually your PNG comes up in photoshop as 72 pixels per inch. ??? ???
Is this in .98? I use mostly .95 because it crashes on me a lot less. though I guess I could use it for still renders if I can control the resolution the way I'm hoping to.
Edit:// just checked .98 didn't see an option for PNG. is there a trick to doing that? I haven't been around the forums in a while.
-
Edit:// just checked .98 didn't see an option for PNG. is there a trick to doing that? I haven't been around the forums in a while.
Welcome back. :)
Major changes for build 1118:
PNG Support As of build 1118 Anim8or supports reading and writing PNG files.
you got me thinking how long since .png support.
found it here.. http://www.anim8or.com/smf/index.php/topic,5044.0.html
which was here http://www.anim8or.com/smf/index.php/board,7.0.html ;)
-
a very informative chat :o
1. it's the latest development release of Anim8or - build 1234, it has the option for png.
2. it seems that Anim8or has some unusual values of ppi (dpi is printer resolution), png and jpg saved format gives only 72ppi, bmp has fixed 254ppi quality and that cannot be changed in any way within Anim8or. But, as Selden said you can use Irfanview or Faststone to just open and re-save image(without changing anything) and it would fix it to a 300ppi- Faststone works that way. I think that it doesn't decrease any quality as long as you don't use jpg format
-
Okay thanks for the insight, guys. I'll give the latest build a look.
As I recall in the old pre-high bandwidth days, 72 was considered the standard internet resolution for Jpg. When I started looking into this I never found a reason for the 254 output on bmp., it never seemed to have a standard other than being a lossless/uncompressed file format.
I suppose for the time being I'll have to include an extra step to make sure I get the output I'm looking for. Glad to see development is continuing and the community still active and helpful.
-
As I pointed out, but you seem to have overlooked, you don't have to leave the dpi setting at whatever Anim8or (or other image producer) uses. You can change the dpi settings of any image without changing anything else about that image.
For example, you can take an image consisting of 2100 x 3070 pixels, one intended for a 7x10" image at 300 dpi but which has internal values of 72x72 dpi, and change its dpi values of 72x72 to be 300x300, leaving the image file otherwise unchanged.
Irfanview and Gimp are two of the programs with graphical GUIs which include that capability. ImageMagick can change dpi settings, too, if you prefer a command-line utility. ( convert -units PixelsPerInch input.png -density 300 output.png ) I'm sure there are others.
I agree that it would be nice if the dpi settings could be specified to Anim8or before it writes the image to a file, but it isn't essential if you're willing to add the dpi modification to your workflow.
-
I didn't over look it Seldon, The answer you gave me was somewhat sufficient, I was just trying to figure out if there was an in-program means for adjusting the resolution so that I didn't need to do it in a secondary program. Again, as I said before I was hoping to avoid situations that could result in errors from having to have an extra step. In the past I've had bad experiences with changing image resolutions where I've lost sharpness before between multiple art programs, so I seek opportunities to avoid the situation.
-
Alpha2: I wasn't even aware that there was an inherent pixel/inch metric built into those formats, so obviously I didn't add any option to Anim8or to set it. I'll look into the libraries that I use for .JPG and .PNG and see what I can do. Anim8or just renders pixels :)
-
To be honest depending on the printer (the people doing the printing not the machines themselves) you can usually just state what dpi your image is in and send them the image data in a format they accept and they usually will be fine with that. And printing for something like a comic book can get pretty complicated with having to deal with things like bleed margins and stuff. But it really depends on who's doing the printing because there are many different ways to go about it and some companies will only except certain things.
My best advice is ask if they want the dpi included inside the image file.
-
254 on BMPs is probably derived from the number of 10ths of a millimetre in an inch (25.4mm). ie. 254dpi = 10dpmm.
-
@cooldude234 Yeah, some printers can throw you for a loop with their requirements, I've been working in book production for a while and I'm still amazed what they can hit you with. The general rule I get from most of the printers I've dealt with is 300 dpi minimum for print comics in CMYK (I believe that's for offset if I'm not mistaken), there are some printers that accept RGB for direct digital printing now (Print on Demand places like Ka-Blam are usually okay with it) but they still suggest 300 pixels per inch. For printing on shirts, sweaters, etc. they may go as low as 150dpi, but only because their inks run a little naturally.
@Steve Thanks for looking into it!
-
To my way of thinking (with minimal print experience) there's two ways to define the resolution of an image:
1) Specifying the size of the image (in mm or inches) and specifying a DPI resolution; or
2) Specifying the number of pixels in the X and Y dimensions.
The DPI figure is of no value if referring to the image by it's X/Y pixels, it will be determined by the printed/displayed size of the image (ie. DPI = X/W where X is the width of the image in pixels and W is the width in inches). Conversely, a printer requesting a certain DPI makes sense only if the printed size of the image is known, so if you need a 5 X 8 printed image and the printer needs 300DPI you'd need to render an image 1500 x 2400px. Or am I missing something?
-
To my way of thinking (with minimal print experience) there's two ways to define the resolution of an image:
1) Specifying the size of the image (in mm or inches) and specifying a DPI resolution; or
2) Specifying the number of pixels in the X and Y dimensions.
The DPI figure is of no value if referring to the image by it's X/Y pixels, it will be determined by the printed/displayed size of the image (ie. DPI = X/W where X is the width of the image in pixels and W is the width in inches). Conversely, a printer requesting a certain DPI makes sense only if the printed size of the image is known, so if you need a 5 X 8 printed image and the printer needs 300DPI you'd need to render an image 1500 x 2400px. Or am I missing something?
DPI and resolution are two separate things all together. You can have any resolution and any DPI to get the actual width and height of the final image, or you can have any resolution and any size (eg 11 x 8.5 inch) to get the dpi.
I'm pretty sure what the op's concern is the encoded number (the meta data) within the image file its self. Which as I know not every printer uses meta data (they ask you when making a print request to state the dpi).
I may be wrong but I feel like the concern is more of an inconvenience rather than a problem (since you can easily edit meta data with many different types of software).
-
Yeah, it's mostly just an inconvenience, not specifically a bug or anything just something causing more confusing than I'd like. As I said most of the art programs I use give you control over the size and resolution at the very start, eg. Need an image to be exactly 3000 pixels wide or even a 7x10 image at 600dpi? You get it before a single pixel is drawn. Here it's a matter of figuring out how many pixels you need the finished art to be based on the pixels per inch of the file type of the finished render and hoping that was composed so that it provides enough to achieve the dimensions you need if you reduce the size of the image to fit and placed into an existing page layout is exact. It can get to be a bit time consuming so I was looking for a workaround to speed things up.
In printing (at least on paper), I'm guessing people have just merged DPI and PPI for the sake of simplicity when dealing with more widely available Print on Demand services. it's been Hammered into me from the beginning that 300 ppi results in an image that doesn't show jaggies or stair stepping on rounded or diagonal lines when going from a digital medium to a printed one where I'd assume DPI originated, so rather than wade into the details with laymen they just seem to use the different terms to mean the same thing. After a while they just became interchangeable except for people who are much more technically versed in screen resolutions.
-
It would be great if Animator saves images in 300ppi by default, that way the quality of rendered pictures be perfect.
Youtube seems to be making some readjustments after I upload video rendered within Anim8or which looks crystal clear on computer, but it always lose a lot of quality in YT. That never happens when I render animation in png pictures and connect those pictures into video with some other program. Maybe that's also related to unusual ppi values.
-
It would be great if Animator saves images in 300ppi by default, that way the quality of rendered pictures be perfect.
Youtube seems to be making some readjustments after I upload video rendered within Anim8or which looks crystal clear on computer, but it always lose a lot of quality in YT. That never happens when I render animation in png pictures and connect those pictures into video with some other program. Maybe that's also related to unusual ppi values.
Nah that would probably be something entirely different. The problem you are probably encountering has to do with codecs. That and you-tube compresses everything down to crap.
It took me a while to get you-tube to accept my 4k 60fps recordings and even then it still looks like garbage compared to the lossless original (but mind you the original did take 10 gigs just for a minute of video :P)
Shameless plug here
[/youtube]
-
10 gigs for a minute :o, were you been using fraps? I'm sure it records uncompressed videos- not sure what codec it uses. youtube uses MP4-H264-AAC codec (that's why we can watch every new uploads on all devices), and I guess it 'killed' the quality during conversion, that happened also to my animations while I've been recording them into AVI format within Anim8or. I've been installing k-lite codec pack and tried to render videos in many codecs but that didn't help much- video's quality were always degraded on YT.
Finally, after experimenting with a lot of software I've started rendering in PNG pictures and connect them into video with Blender. That way I do slow renders of scenes with Anim8or only once, and can experiment with video editing with Blender (I find Blender very complicated and slow for simple 3D animation and I don't use it for that- it gave me a lot of headache).
I've noticed something interesting with Blender- it also saves images at 72ppi by default and that value can't be changed, it has that same value within various picture formats. Having 254ppi in BMP format Anim8or is superior when you render BMP image but I guess the difference should be only visible on printers and ultra HD monitors.
72ppi is the optimal value which works great for pixel density of average computer monitors. I don't have ultra HD monitor so can't tell the difference, but if someone does I'd like to hear that, just render some image in 4K resolution with anti anti-aliasing and save them in BMP and PNG format for comparison.
-
but I guess the difference should be only visible on printers and ultra HD monitors.
72ppi is the optimal value which works great for pixel density of average computer monitors. I don't have ultra HD monitor so can't tell the difference, but if someone does I'd like to hear that, just render some image in 4K resolution with anti anti-aliasing and save them in BMP and PNG format for comparison.
Well once again the DPI of an image doesn't matter when your viewing those images on a computer (because you can scale them up or down in real-time). You could set the dpi on the image to be 23408329084 if you wanted to and it would look the same on your computer as long as the output resolution is the same.
Also DPI was term coined for printing, and PPI was a term coined for computer monitors. Both values work pretty much the same but they both refer to something slightly different.
As for the codec I was using. I used Nvidia's hardware encoder/decoder with their hvenc codec through the terrible mp4 container format at 4k 60fps with the quality ratio set to a 100.
Doing the math
3810x2160 at 8 bits per channel at 3 colour channels (which is 24 bits for all channels)
24 x 3810 x 2160 = 197510400 bits per image
197510400 / 8 (convert to bytes)
24688800 / 1000 (convert to kilobytes)
24688.8 / 1000 (convert to mega bytes)
= 24.6888 mega bytes
Now we have 60 of these for each second and we have 60 seconds in a minute so...
60 * 60 = 3600
Multiply how many frames we have by how much each frame is...
24.6888 * 3600 = 88879.68 megabytes
88879.68 / 1024 (converting to gigabytes)
= 86.7965625 Gigabytes
Now of course that would be purely lossless and the Nvenc codec was using a variable bit rate with pbuffers and more so if nothing changed in the image in any part it wouldn't have the need to update it so it wouldn't store data for it. On top of that it still was slightly compressing it as a whole. So a 10 gig file over a 86 gig one is still pretty good.
The only codec I've seen come close to quality and space was with the xvid codec where with the same settings I could make that a 2 gig file (but its really process intensive where as Nvenc isn't nearly as intensive).
Trust me, when you are dealing with high quality video expect to deal with the file size that comes with it. I mean if you think about it most bluray movies are about 40 gigs in size and that's at only 1080 at 30 frames a second.
-
I wrestled with a lot of codecs early on trying to get one that wouldn't glitch out or get massacred in the Youtube compression. The Xvid Codec has been pretty good to me for at least 720p at 24 or 30 frames (720pHD profile, single pass) the clarity has always been pretty good for a fair size and reasonable rendering time, But then again I don't use many lights and have never rendered at 60 frames per second in .95, now I kinda want to give it a shot and see if it holds up.
-
I wrestled with a lot of codecs early on trying to get one that wouldn't glitch out or get massacred in the Youtube compression.
As someone who deals with codecs on almost a daily basis, I can tell you they're a pain in the rear and extremely difficult to get working correctly in the way you want; even for an advanced user. So don't feel bad if you are having troubles with them :P
Also Xvid codec works extremely well at higher resolutions (4k and beyond), but it just gets way to taxing on CPU resources to decode all that wonderfully compressed data in real-time. IE quality vs size is superb but performance is meh.
So I really like it as an archival compression method.
-
I had to make some prints for a company few years back, and I've noticed there's amazing quality even with 150dpi for huge banners and prints. Always check antialiased when rendering, though.
I also had no problem rendering videos at 4K resolution with anim8or.
Unfortunately, it seems the max resolution for textures is same as the max resolution for renders 4096x4096.
Sometimes I create my textures as 8192x8192, and I have to size it down to 50% to be able to load it in anim8or.
Overall, anim8or proved to be the perfect choice in every situation for me :)
-
Anim8or limits the render size to 4X by 4K. I'll look into increasing this, hopefully without hitting any kind of other limits.
Anim8or limits texture sizes to the OpenGL max for the graphics card, which is a minimum of 4K by 4K. To see what the limits of your card are, run Anim8or form a command line with the parameter -traceinit and look for the line with GL_MAX_TEXTURE_SIZE. On my computer it's 16384.
-
Steve: I'll have to look into that, 'cause I don't know how to do that.
Anyhow, I had projects with 4 x 4K textures, but when trying to add another one, it crashed. Fortunately, so far it was enough for me.
-
Check how much memory Anim8or is using - that might be why it's crashing. Anim8or is not good at managing memory :(
-
cooldude234: check out build 1240 (http://www.anim8or.com/download/preview/files/animcl1240.zip) - I added a pixel/inch attribute for saving .BMP, .PNG and .JPG images. Let me know if it does what you need.
Note: .PNG files only support pixels/meter as far as I can tell so I use the closest equivalent.
-
I had to make some prints for a company few years back, and I've noticed there's amazing quality even with 150dpi for huge banners and prints. Always check antialiased when rendering, though.
I also had no problem rendering videos at 4K resolution with anim8or.
Unfortunately, it seems the max resolution for textures is same as the max resolution for renders 4096x4096.
Sometimes I create my textures as 8192x8192, and I have to size it down to 50% to be able to load it in anim8or.
Overall, anim8or proved to be the perfect choice in every situation for me :)
Antialiasing is fine when you're not editing. But it's a hassle when you get into photo shop and go to select an area of color and you get spotty edges. I've worked on projects that have required pixel perfect accuracy and the kind of "halo" effect you get on aliased images list the last thing you want to deal with.
cooldude234: check out build 1240 (http://www.anim8or.com/download/preview/files/animcl1240.zip) - I added a pixel/inch attribute for saving .BMP, .PNG and .JPG images. Let me know if it does what you need.
Note: .PNG files only support pixels/meter as far as I can tell so I use the closest equivalent.
I gave it a spin with one of the projects I'm working on, and it seems to work perfectly! Thanks for looking into this Steve. The test file properties read exactly as I'd hoped in their properties tab. The compression on jpg seems a bit more aggressive than I remember, but it's probably just been a while since I last rendered a simple jpg in Anim8or. I'll probably just stick to BMP and PNG for any serious still image output.
-
Alpha2: Try setting the JPG quality to a higher number. The default of 90 isn't really 90% - I don't know how they apply this number - it's just a parameter to the compression function. Try 100 and see if that's OK (or just use .png -it's better than .bmp because it's losless but compressed).
-
Antialiasing is fine when you're not editing. But it's a hassle when you get into photo shop and go to select an area of color and you get spotty edges. I've worked on projects that have required pixel perfect accuracy and the kind of "halo" effect you get on aliased images list the last thing you want to deal with.
Alpha2: I know what you mean, but when I must edit in PS a final render from anim8or, or for that matter any image, I use channel masks or simple matte masks. Usually, selecting a color area with the select tool is never recommended, and it never gives good results. Indeed, a fix for this would be a huge render export from anim8or, and after size it down the aliasing would be gone. But since the max is 4K, the best approach would be matte or channel masks for PS edits.
-
Alpha2: Try setting the JPG quality to a higher number. The default of 90 isn't really 90% - I don't know how they apply this number - it's just a parameter to the compression function. Try 100 and see if that's OK (or just use .png -it's better than .bmp because it's losless but compressed).
The last attachment was rendered at 100 quality already. I expected some blended edges, but I guess JPG magnified to that size will always be a bit messy. So yeah I'll try running with PNG instead.