What compression level is used for the jpg rasters from Prince? And is there a way to control that anywhere? I am using `raster-format=jpg` from the command line. I have it set to 300 DPI, but I have a customer complaining that the image is too soft so I am wondering if it is a compression issue or not.
Forum › How do I...?
Raster jpg quality
I don't think I need to go to the extreme of using PNG. I was just wondering what jpg compression it is using and if there is a way to control that. If you are already using decently high compression this customer might just be not liking something that has nothing to with the compression anyways.
To add onto this conversation, we are having some customers complain about the raster quality of certain images that have text on the image that are becoming fuzzy. In this particular case it was the name of the team on a sports jacket. At first I thought maybe the issue was being created on my end so I increased the resolution of the image that was being embedded into the html. This helped but didn't completely fix the issue. Even with a huge ~5MB file embedded in without anything being done to it on my end, the raster quality of a 8x10 at 300 DPI made the text on the embedded image fuzzy. Increasing the DPI to something like 400DPI did help, but isn't always feasible since we have customers that need the DPI to be exactly 300 to print correctly (no idea why to be honest).
Outputting a png resulted in the same quality as far as I could tell. Unless you are using libjpeg to do the actual rasterization I don't think the lossy compression is the issue here.
I am reaching for straws here, but when using ImageMagick or libvips to convert jpgs there is an option to control the compression algorithm. Usually the defaults are fairly fast but dirty algorithms that introduce artifacts like I am seeing here. Is there something similar in Prince's rasterization pipeline you can expose as a CLI option to help with quality issues?
These are limited signed S3 urls to the images so they won't last forever, but here is an example of what I talking about:
Generated composite resulting in blurry text on jacket: https://plic-elements-staging.s3.amazonaws.com/books/55542642-8678-4183-9d40-101cbdffb564/images/Medium%20Batch.jpg?X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJI42PHFH33MAXS6Q%2F20200720%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20200720T200105Z&X-Amz-SignedHeaders=host&X-Amz-Expires=3600&X-Amz-Signature=ca1ad56df9c25f61f39bfc50782323911bc4ad07fdf63581b4b8d14a56b05002
Original full quality image: https://plic-io.s3.amazonaws.com/photos/a227f154-437b-40a9-ab21-eacfba0d07c1/original/0003-00003.jpg?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJAMRRGAHI5LJPB6A%2F20200720%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20200720T203430Z&X-Amz-Expires=604800&X-Amz-SignedHeaders=host&X-Amz-Signature=4ba61af28888d88c76e20f8528d0ea38cad7aef1e13e9d0a36c78b5a080615a4
Outputting a png resulted in the same quality as far as I could tell. Unless you are using libjpeg to do the actual rasterization I don't think the lossy compression is the issue here.
I am reaching for straws here, but when using ImageMagick or libvips to convert jpgs there is an option to control the compression algorithm. Usually the defaults are fairly fast but dirty algorithms that introduce artifacts like I am seeing here. Is there something similar in Prince's rasterization pipeline you can expose as a CLI option to help with quality issues?
These are limited signed S3 urls to the images so they won't last forever, but here is an example of what I talking about:
Generated composite resulting in blurry text on jacket: https://plic-elements-staging.s3.amazonaws.com/books/55542642-8678-4183-9d40-101cbdffb564/images/Medium%20Batch.jpg?X-Amz-Content-Sha256=UNSIGNED-PAYLOAD&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJI42PHFH33MAXS6Q%2F20200720%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20200720T200105Z&X-Amz-SignedHeaders=host&X-Amz-Expires=3600&X-Amz-Signature=ca1ad56df9c25f61f39bfc50782323911bc4ad07fdf63581b4b8d14a56b05002
Original full quality image: https://plic-io.s3.amazonaws.com/photos/a227f154-437b-40a9-ab21-eacfba0d07c1/original/0003-00003.jpg?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJAMRRGAHI5LJPB6A%2F20200720%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20200720T203430Z&X-Amz-Expires=604800&X-Amz-SignedHeaders=host&X-Amz-Signature=4ba61af28888d88c76e20f8528d0ea38cad7aef1e13e9d0a36c78b5a080615a4
Edited by daneren2005
Sorry about that. I have just made it publicly accessible: https://plic-elements-staging.s3.amazonaws.com/books/55542642-8678-4183-9d40-101cbdffb564/images/Medium+Batch.jpg
I can see the usual JPEG artefacts around the white stripe and white text on the green jacket if I zoom right up. Those wouldn't be present in a PNG image.
If the metadata is correct, the text itself is only about 3x2 mm on the page and 35x19 pixels large.
If the metadata is correct, the text itself is only about 3x2 mm on the page and 35x19 pixels large.
Sorry for the delayed response. I was taking a vacation so I didn't see your reply earlier.
Here is a PNG: https://plic-elements-staging.s3.amazonaws.com/books/cb29acc7-a10b-4739-a2c0-df72801a87b4/images/Medium+Batch.png
Here is the same image as a jpg: https://plic-elements-staging.s3.amazonaws.com/books/34ed8028-5042-48b8-b6fe-25451a1aae2d/images/Medium+Batch.jpg
I see no difference between the two so I am thinking the fuzzing happens before compressing the image to a jpg. Just for comparisons sake, I decided to do a similar screenshot using Puppeteer and it was actually worse even specifying the jpg quality at 99: https://plic-elements-staging.s3.amazonaws.com/books/76144bc0-2056-4cfd-84d0-0841c267efab/images/Medium+Batch.jpg. I also ran a PNG test with Puppeteer and saw the same results there as well.
I'm not sure what the metadata says, but those should be 10 x 8" composites. I think you are right that it is a tiny bit of text on the image so it shouldn't make a difference. The customer in question was using something called DP2 (a fairly industry specific tool) before and they are claiming that the same dimension images coming out of DP2 are better looking than what we are producing. They are also claiming that they actually printed it and it makes a difference in the printed quality as well.
Here is a PNG: https://plic-elements-staging.s3.amazonaws.com/books/cb29acc7-a10b-4739-a2c0-df72801a87b4/images/Medium+Batch.png
Here is the same image as a jpg: https://plic-elements-staging.s3.amazonaws.com/books/34ed8028-5042-48b8-b6fe-25451a1aae2d/images/Medium+Batch.jpg
I see no difference between the two so I am thinking the fuzzing happens before compressing the image to a jpg. Just for comparisons sake, I decided to do a similar screenshot using Puppeteer and it was actually worse even specifying the jpg quality at 99: https://plic-elements-staging.s3.amazonaws.com/books/76144bc0-2056-4cfd-84d0-0841c267efab/images/Medium+Batch.jpg. I also ran a PNG test with Puppeteer and saw the same results there as well.
I'm not sure what the metadata says, but those should be 10 x 8" composites. I think you are right that it is a tiny bit of text on the image so it shouldn't make a difference. The customer in question was using something called DP2 (a fairly industry specific tool) before and they are claiming that the same dimension images coming out of DP2 are better looking than what we are producing. They are also claiming that they actually printed it and it makes a difference in the printed quality as well.
Here is a comparison of the JPEG vs PNG outputs, zoomed up 800% (click to see full size):
[missing attachment: "jpeg_vs_png_comparison.png"]
You can see the JPEG artefacts (which could be described as "fuzzy") and the text in the JPEG is softer.
We may be able to enable a higher quality downsampling filter for images (Catmull-Rom vs bilinear interpolation). However, it is very much slower and I'm not sure it would be considered an improvement in this case anyway. (Note: I may not have matched your image sizes exactly.)
[missing attachment: "Catmull-Rom.png"]
I don't really know what else can be done at 300 DPI. Any reason your customers are not printing the original PDF containing unscaled images?
[missing attachment: "jpeg_vs_png_comparison.png"]
You can see the JPEG artefacts (which could be described as "fuzzy") and the text in the JPEG is softer.
We may be able to enable a higher quality downsampling filter for images (Catmull-Rom vs bilinear interpolation). However, it is very much slower and I'm not sure it would be considered an improvement in this case anyway. (Note: I may not have matched your image sizes exactly.)
[missing attachment: "Catmull-Rom.png"]
I don't really know what else can be done at 300 DPI. Any reason your customers are not printing the original PDF containing unscaled images?
Interesting. I will have to play with some different downsampling filters to see if any other algorithms do a better job there. I understand if there isn't anything to be done at 300 DPI. This is probably one of those times that I am just going to tell the customer that is what we have and we can't change it.
And as for the PDF question, unfortunately a lot of these lab's printers just flat out don't handle pdf's very well. Some crash and burn. Some just print differently than shown by Adobe. Over the last couple of years we have moved to defaulting new customers to jpg renders instead (PS I love that you guys provide that as an option so we can use the same render library for both outputs). We give the original pdf as an option, but so far the only people who actually use that are a few extremely large customers that have high end printers and the resources to properly QA before printing.
And as for the PDF question, unfortunately a lot of these lab's printers just flat out don't handle pdf's very well. Some crash and burn. Some just print differently than shown by Adobe. Over the last couple of years we have moved to defaulting new customers to jpg renders instead (PS I love that you guys provide that as an option so we can use the same render library for both outputs). We give the original pdf as an option, but so far the only people who actually use that are a few extremely large customers that have high end printers and the resources to properly QA before printing.
In the new latest build we have added a --raster-jpeg-quality option which allows it to be raised from the default of 92, perhaps this will help.