View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0016150||Scribus||public||2020-07-03 10:05||2020-07-16 09:43|
|Target Version||Fixed in Version|
|Summary||0016150: try harder to embed jpg images as is|
|Description||when creating a pdf, scribus should try harder to embed jpg images as is.|
i've tried a few (if not all) of the available options and i could not get this image
to be embedded into a pdf without having the size of the pdf being the double or more of the original image. (and without losing much of the quality)
i could not find out the reason why this image gets converted and other images (https://upload.wikimedia.org/wikipedia/commons/d/db/Patern_test.jpg) are inserted as is but scribus:
- should make sure that when it resamples an image it does not increase its size (except if it has reasons for doing so)
- offer an option to the user to say that (jpg) images should be included as is. (in the pdf export dialog or in the settings for the single images)
|Tags||No tags attached.|
>> when creating a pdf, scribus should try harder to embed jpg images as is.
That's not because PDF supports JPEG encoded images that JPEG files can be embedded as is. There are in fact many case where JPEG files *cannot* be embedded as is:
- JPEG file use progressive encoding
- JPEG exif data uses non default rotation (eg: images using portrait orientation taken with digital cameras)
- JPEG file colorspace does not match PDF output colorspace
- JPEG file uses CMYK colorspace: would force to use a PDF feature which is regularly misinterpreted by RIPs
- JPEG file uses grayscale and PDF output target is printer: grayscale data can be ambiguous in a CMYK workflow as RIPs can interpret it either as RGB data or as CMYK data with K only
- JPEG has to be downsampled
There is however one case which relates to a Scribus limitation with grayscale colorspace, and it applies to your case: 0003540.
>> offer an option to the user to say that (jpg) images should be included as is. (in the pdf export dialog or in the settings for the single images)
No, for all the reasons mentioned above this cannot be a user option.
your explanation is very valuable and those are for sure good reasons for resampling the jpg.
now, does scribus know why it cannot embed a jpeg in a pdf?
can scribus provide the information in the preflight manager?
or in the image info in the context menu?
or in the image manager?
currently, users are puzzled on the reasons why the size of the pdf "explodes" and it would be nice to provide them with the information.
(btw, this could also go into a pdf report...)
||Yes this should be in the preflight verifier I think and potentially be analysed on jpeg import|
Only the first two cases I mentioned can. The others depends on PDF output parameters. It should be noted tho that the second case related to exif data may well bring lots of noise. Also in most cases, users will not be able to easily fix those warnings by themselves, which would make that noise pretty useless.
>> currently, users are puzzled on the reasons why the size of the pdf "explodes" and it would be nice to provide them with the information.
As for the sample image you uploaded, this is related to 0003540, not to a specific image format. When you export to RGB, lack of explicit support for grayscale colorspace will trigger grayscale images to be exported as RGB, hence the file size increase. Same when exporting to CMYK as we intentionally convert grayscale data to CMYK with K only to avoid ambiguous interpretation of grayscale data in RIPs.
||imo it's not about being able to fix the image, but knowing that scribus is doing the right thing or the best it can.|
I'd like to add some comments, because I have asked the question which has led to this ticket
- Sorry, I cannot upload my file, because of legal reasons.
- It's not grayscale, it has colors. The JPEG image is a composition of other images (photos). It' s landscape, it's landscape in the PDFs as well.
- Both ImageMagick's convert and LibreOffice writer embed the same JPEG file "as-is" into a PDF document (there is no real increase of the file size). OTOH gimp shows the same issue.
The JPEG file:
165039 Jul 2 09:28 1.jpg
Resulting PDF file sizes:
177923 Jul 3 15:43 1-convert.pdf
1012406 Jul 2 10:13 1-gimp.pdf
166432 Jul 2 17:12 1-lxwriter.pdf
413298 Jul 2 10:43 1-scribus-72dpi.pdf
1012638 Jul 2 10:17 1-scribus.pdf
Maybe the JPEG meta data shows somehting:
$ identify -verbose 1.jpg
Format: JPEG (Joint Photographic Experts Group JFIF format)
Mime type: image/jpeg
Print size: 11.69x8.26
min: 0 (0)
max: 255 (1)
mean: 193.787 (0.759947)
standard deviation: 82.9539 (0.32531)
min: 0 (0)
max: 255 (1)
mean: 184.401 (0.723143)
standard deviation: 86.1274 (0.337755)
min: 0 (0)
max: 255 (1)
mean: 180.436 (0.707594)
standard deviation: 88.9565 (0.348849)
min: 0 (0)
max: 255 (1)
mean: 186.208 (0.730228)
standard deviation: 86.0476 (0.337441)
Rendering intent: Perceptual
red primary: (0.64,0.33)
green primary: (0.3,0.6)
blue primary: (0.15,0.06)
white point: (0.3127,0.329)
Background color: white
Border color: srgb(223,223,223)
Matte color: grey74
Transparent color: black
Page geometry: 1169x826+0+0
Number pixels: 966K
Pixels per second: 48.28MB
User time: 0.020u
Elapsed time: 0:01.019
Version: ImageMagick 6.9.7-4 Q16 x86_64 20170114 http://www.imagemagick.org
||Unfortunately the output of identify does not provide any helpful information.|
>> Sorry, I cannot upload my file, because of legal reasons
If that helps you can set the view status of specific notes to "private". In such case only developers and administrators will see it. We can also set a whole issue to private mode, effect will be the same.
Sorry for the late response. I was busy, and then it took me a while to find another JPEG which shows that behaviour:
I have found that image using duckduckgo.com, "foto collage", large image.
$ wget https://nonsoloprogrammi.net/wp-content/uploads/2015/01/collage.jpg
$ md5sum collage.jpg
$ convert collage.jpg convert.pdf
Now saving that image (as-is in a frame, then fit-to-frame) using Scribus:
402081 Dez 23 2014 collage.jpg
432343 Jul 15 14:56 convert.pdf
2088983 Jul 15 14:56 scribus-1.pdf
2088984 Jul 15 14:56 scribus-2.pdf
I tried around 15 images until I found that one. All of the other ones were fine.
>> Sorry for the late response. I was busy, and then it took me a while to find another JPEG which shows that behaviour
The image provided by this link falls in one of the category I have mentioned in my first note : JPEG file using progressive encoding. Progressive encoding has to be avoided for the applications Scribus targets.
|2020-07-03 10:05||ale||New Issue|
|2020-07-03 14:57||jghali||Note Added: 0047772|
|2020-07-03 14:58||jghali||Note Edited: 0047772||View Revisions|
|2020-07-03 16:45||ale||Note Added: 0047776|
|2020-07-03 17:19||cbradney||Note Added: 0047777|
|2020-07-03 17:34||jghali||Note Added: 0047779|
|2020-07-03 17:34||jghali||Note Edited: 0047779||View Revisions|
|2020-07-03 17:36||jghali||Note Edited: 0047779||View Revisions|
|2020-07-03 17:53||jghali||Note Edited: 0047779||View Revisions|
|2020-07-03 18:00||jghali||Note Added: 0047783|
|2020-07-03 18:12||ale||Note Added: 0047784|
|2020-07-08 06:53||beryllium2||Note Added: 0047800|
|2020-07-08 11:06||jghali||Note Added: 0047802|
|2020-07-08 14:33||jghali||Note Added: 0047804|
|2020-07-15 13:00||beryllium2||Note Added: 0047836|
|2020-07-15 23:29||jghali||Note Added: 0047839|
|2020-07-15 23:29||jghali||Note Edited: 0047839||View Revisions|
|2020-07-16 09:43||jghali||Note Edited: 0047839||View Revisions|