![]() ![]() The encoding time was also around the same (took 10 minutes longer for a 1hour 50 minutes movie).Įdit: I did a 1080p test myself now, took the Avatar 1080p trailer which has 9720kbit/sec. To emphasisze how this all is a good idea: I recently backuped a DVD and first did a normal 2-pass mode encode (preset: medium) with a targeted filesize of ~1,2gb, then i used constant quality mode with crf 19 and slow preset, and the final filesize was something around 800mb with basically identical, if not even slightly better quality than the 400MB bigger 2-pass encode (it's a bit hard to tell which is better because the DVD source has some artifacts aswell). General rule: the more slow or bright scenes a movie has, the bigger the final size will be. Be aware however that every movie behaves a little different with constant quality, so two different 90 minutes movies can potentially have a huge size difference with exactly the same settings. Play around with this (I recommend using a movie trailer in 1080p for testing purposes) until you find a good mix between quality, file size and encoding time. In crf mode, this will not or only minimally affect quality, while greatly increasing the filesize since the encoder compensates the lower encoding complexity with MOAR bitrate. However you could also set the preset to fast or faster. If it's small enough for you so that you are willing to let it get bigger you can a) either decrease the crf further or b) increase the output resolution, both will result in a bigger filesize with the same settings (you won't probably be able to get a 1080p file 45mins under 2gb though even with the slowest preset, but maybe around 2,5-3gb, depends on the source). First try with Medium preset then and look how big the file gets (you cannot predict file size with constant quality). First set your rate factor to something between 20 (good quality) and 18 (very good quality) (the lower the number the better the quality, but everything below 17 becomes neglectible). This is stripped off of course when saving out canvas, but it does not alter the image resolution (provided the canvas is of the same pixel resolution as the original image) so there will be no drop in print quality (compression via JPEG can of course affect general quality, but for actual resolution there is no change).You could also try to go for constant rate factor (constant quality). So in conclusion: When you pass the image through the canvas the image may have a hint embedded that indicates for example 300 DPI. No pHYs chunk and IHDR only contains actual pixel resolution.Īnd that's OK as an image is assumed to be 96 DPI on most systems nowadays so it doesn't have any consequences (where DPI is actually used to affect the image, and no other DPI/PPI is defined).įor you and me in most cases though, a 1920x1080 image will be 1920x1080 on a 15" as well as on a 50" screen. Hex-dump of PNG saved from Firefox, but the case is the same for Chrome. This must be either 1 (inch) or 2 (cm) (and of course no EXIF (0xffe1/APP1) as there is no camera/scanner producing the image). Nope, no unit defined (0) at position 0x0D. Hex-dump of JPEG saved from Firefox, but the case is the same for Chrome. The browser doesn't actually store this information in the image files it produces either (not that it need to, see below).Īnd just to document, lets first look at the binaries of a JPEG file: DPI is purely arbitrarily when saved as meta in/with images and function as a hint when transferred to physical medium such as a screen or to paper (and the entire pipe-line displaying the image considers its DPI).Īs to why: The 96 DPI refers to the "standard" (but inaccurate and a bit outdated) screen pixel density so that if you do print your image to paper as-is and hold the paper up against your screen the content on paper should somewhat match in size with that you see on the screen (most people don't calibrate theirs screens for actual DPI, and manufacturers are sometimes sloppy with their drivers, if not a generic driver is used, so there will be a small error margin). Images are only measured in pixels and has no concept of real-world sizes. ![]() The (somewhat) short answer to your question would be: You'll see me using DPI for PPI as it has been so ingrained since I started using it in the early 90s). (Side note: PPI vs DPI differs in physical properties - but not really important in this context. The quote from MDN is wrong in the sense it refers to DPI as resolution for the image. How is it possible to refer to a print resolution when there is no printing involved? ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |