I was trying to archive a web page, and made a screenshot of it which I then saved as heic, but I ran into this weird phenomenon: When I tried a narrower window the image became bigger, and apparently the original png too?
This is my screenshot for a full-sized browser window:
PNG 2,1 MB 6016×3336 HEIC 796 KB 6016×3336.
This is my screenshot for a narrower browser window
PNG 2,4 MB 1532×3408 HEIC 1,1 MB 1532×3408.
How does this make sense? I would love to know.
Web page from the screenshot
PNG encoders filter your image on a line-by-line before compressing them. They can look at a line of pixels and determine if each pixel is heavily based on the line above, or the previous pixel to the left or some more complicated combination of these. They then choose the optimal filter for the line and store it in the output file for the decoder.
As a result, repetitive lines which are largely identical to the line above, or unchanging across the width of the image, are compressed extremely well.
That's what you have in your wider image - there are vast areas of pure white on left and right and they compress very well so although the pixel dimensions are larger, the compression is more effective.
Related
I added 33 mb worth of sprite assets (they are large character illustrations), so I would expect the data folder to increase proportionally. However, the size actually increases by 2 GB (6000% increase!) increasing total data size by over 500% too.
Doesn't make any sense to me. Is there a mistake with my import options? I use mip maps, bilinear/trilinear filters. Truecolor/ vs compressed doesn't change anything.
Additional info: It's like 10 files with 5-8 large sprites each. Another weird thing is that when it's compressed to a zip file the size collapses to 142mb (from like 2.3 GB). Which is weird because that's too big of a difference.
It's also very slow to start.
I believe this is related to how unity handles image compression. The assets live in your project in compressed (jpg/png) form, but they get recompressed (or not) to a form thats fastest to decode on the target platform. Try playing with the compession settings with the asset import settings (available if you highlight your asset in the project window)
There are a few reasons why file sizes can get so big.
As #zambari said, PNG/JPEG are compressed forms, which compress much better than what unity will. Due to that, you have to be careful with your file sizes, since they will be much bigger in-game.
Another issue I had was that my files weren't sized properly. The compression method that I was trying to utilize requires file sizes divisible by 4 (DTX5).
Another big issue was I had large images that I did not need. I used "generate mip-maps" + trilinear filtering, and that once again doubled the file sizes. The best thing you can do is just use image sizes that reflect their use. Relying on Unity to do that for you by using max image size does not guarantee good quality (in fact it looked terrible). This was all in Unity 5
We have many square EPS images, which we would like to export via script to PNG at very specific formats/sizes, namely
8192x8192, greyscale, no alpha, no anti-aliasing
2048x2048,greyscale, no alpha, anti-aliased.
We have had no luck scripting the "professional" tools Photoshop or Illustrator to do this (although we can do so through the UI, their weak scripting support does not give control over alpha or precise image export size, so we either always get alpha in the large images, or we sometimes get slightly inaccurate image sizes which breaks subsequent algorithms.)
Our first attempt at doing the high resolution version of this was:
gs -sDEVICE=pnggray -o cover.png -dDEVICEWIDTHPOINTS=8192 -dDEVICEHEIGHTPOINTS=8192 -dGraphicsAlphaBits=1 -dPDFFitPage=true cover.eps
However, this does not seem to resize the image to fill the box as expected.
Is there a way, given a square EPS, to get Ghostscript to do what we want?
Your problem with EPS files is that they do not request a media size. That's because EPS files are intended to be included in other PostScript programs, so they need to be resized by the application generating the PostScript.
To that end, EPS files include comments (which are ignored by PostScript interpreters) which define the BoundingBox of the EPS. An application which places EPS can quickly scan the EPS to find this information, then it sets the CTM appropriately in the final PostScript program it is creating and inserts the content of the EPS.
The FitPage switch in Ghostscript relies on having a known media size (and you should set -dFIXEDMEDIA when using this) and a requested media size, figuring out what scale factor to apply to the request in order to make it fit the actual size, and setting up the CTM to apply that scaling.
If you don't ever get a media size request (which you won't with an EPS) then no scaling will take place.
Now Ghostscript does have a different switch, EPSCrop which picks up the comments from the EPS and uses that to set the media size (Ghostscript has mechanisms to permit processing of comments for this reason, amongst others). You could implement a similar mechanism to pick up the BoundingBox comments, and scale the EPS so that it fits a desired target media size.
I could probably knock something up, but I'd have to mess around creating an example file to work from.....
Do not accidentally specify PDFFitPage in the command line above. Specify EPSFitPage when dealing with EPS files. PDFFitPage will silently do nothing.
I have an image captured via webcam of my cat (the subject might not be important). I've aquired it as a 31 kB JPG file. When I open it with an image editor, then save it (without alteration) as a PNG (max. compression) it stores as a 297 kB file.
Why is the PNG file 10x larger than the original JPG. As I understand it, opening a JPG is lossless, and saving a PNG is lossless. So, where does all the extra data come from? If the image comes entirely out of the small file, why does it then re-save to 10x the size on disc?
Please read this carefully. I'm not asking why the two formats produce different file sizes from an original image. I'm asking why opening an existing JPG then saving that exact same image as PNG is 10x bigger. I don't think that this is a duplicate question as far as I can ascertain.
Some tests I've done:-
I've looked at both JPG and PNG and they look identical.
I've zipped both files and got cat.jpg.zip as 31 kB, and cat.png.zip as 296 kB. I take this to mean that both files are fully compressed with virtually no latent redundancy.
I've tried this via the BMP format as well; cat.jpg (31 kB) -> cat.bmp (922 kB) -> cat.bmp.zip (404 kB).
Any ideas regarding the mysterious extra data..?
JPEG inherently produces better compression than PNG. However, JPEG trades off fidelity to the original image for better compression. PNG reproduces the original exactly.
If you go from JPEG to PNG, you are not going to see a changes.
If you go from PNG to JPEG, it is likely you ill see a lot of change.
JPEG uses a series of compression techniques. One of them, the DCT, transforms the image. This creates a subtle waviness in color. For example, if you start with a solid red block that is all one color, JPEG produces a lot of slight color variations.
PNG compression relies on finding repeated pixel patterns in scan lines. The subtle color variations introduced by JPEG can make PNG compression less effective.
The extra data you refer to is simply the difference in how the two format represent the same image.
If I take a JPEG image from a camera and convert to PNG, the result is usually about 10 times larger.
For a PNG Graphic image going to JPEG, I normally get files about 1/3 smaller.
JPG uses lossy compression, while PNG uses loseless compression. When you convert JPG to PNG, what actually happens is uncompressing from JPG and saving the results in PNG.
The "extra data" is actually due to different algorithms used.
As for why zipped files also have different size, that's because PNG has to save all pixels(including those JPG has lossy compressed) loselessy.
I need to include many images of unknown origin in a report. I have no idea what the images might be: portrait or landscape fotos, large or small, or even something with an atypical shape, like a 400x80 logo.
I'd like to scale down images with the following rule: proportionally downscale until the larger side is 200. And resulting image shouldn't take more space than needed (i.e. 1000x600 should be downscaled to 200x120, not to 200x200), so that there are no unneeded blank margins around non-square images.
Is what I need possible with JasperReports?
EDIT:
To clarify: "real size" mode is almost what I need. However, I don't see a way to limit height of resulting image. As a result, if the image I want to print is a portrait foto (or has even larger height compared to width), generated PDF looks ugly; in this case I would prefer to somehow downscale it to a smaller width.
I solved the Problem of resizing images of various sizes to a fixed size with "RetainShape" by writing an ImageResizer, based on the idea of the ImageTransformer from https://stackoverflow.com/a/39320863/8957103 , using https://github.com/rkalla/imgscalr for scaling the image.
The original PNG image is 800x1200 and takes up about 34K. After the images is resized by GraphicsMagick to 320x480 size, the resulting images takes up approximately 37K. (For comparison, if the image is resized with Paint on Windows 7 then the resulting image is 40K.) What gives? The whole point of resizing an image was to save space. How should GraphicsMagick be used to shrink the image size?
PNG is a lossless format and compresses the image data by first performing a step called prediction and then applying the same algorithm used in zlib. The prediction step is a crucial one in order to effectively compress the file, and it is based on the values of earlier neighbors pixels.
So, suppose you have a large PNG in black & white (by that I really mean only black and white, some people confuse that by grayscale sometimes). Also suppose it is not a tiny checkerboard pattern. In many regions of this image, you will have a relatively large white region, and then a relatively large black region, and so on. When the predictor is inside one of these large regions, it has no trouble to correctly predict that the current pixel intensity is exactly equal to the last one. This makes it easier to better compress the data describing your image.
Now, let us downscale this black & white image using some resampling filter different than nearest neighbor (let's say Lanczos). This has a great chance to turn your black & white image into a grayscale one, which has a much greater intensity range. This potentially makes the job of the predictor much harder, and thus the final file size might be larger.
For instance here is a black & white 256x256 PNG image which takes 5440 bytes, a resizing of it (using 3-lobed Lanczos) to 120x120 which now takes 7658 bytes, and another resizing (using nearest neighbor) to 120x120 which occupies 2467 bytes.
PNG is a compressed format. Sometimes trying to compress a maximally compressed item actually results in a larger item. So if the 800x1200 is resized to a smaller size, but the result retains everything that was in the original, because the original is already as minimal as possible, you could see this happen. To demonstrate this, try using 7zip to compress some data with ultra compression. Then try compressing the compressed file. Often the second compressed file will be larger than the first.