View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0016150 | Scribus | public | 2020-07-03 10:05 | 2021-11-09 20:55 | |
| Reporter | ale | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Product Version | 1.5.6.svn | ||||
| 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 https://upload.wikimedia.org/wikipedia/commons/thumb/6/69/Iglesia_de_san_francisco_300_dpi.jpg/850px-Iglesia_de_san_francisco_300_dpi.jpg 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. | ||||
| Patch | No | ||||
|
|
>> 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 (https://graphicdesign.stackexchange.com/questions/138540/scribus-export-to-pdf-results-in-a-large-file-size-compared-to-the-included-jpe). - 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 Image: 1.jpg Format: JPEG (Joint Photographic Experts Group JFIF format) Mime type: image/jpeg Class: DirectClass Geometry: 1169x826+0+0 Resolution: 100x100 Print size: 11.69x8.26 Units: PixelsPerInch Type: TrueColor Endianess: Undefined Colorspace: sRGB Depth: 8-bit Channel depth: red: 8-bit green: 8-bit blue: 8-bit Channel statistics: Pixels: 965594 Red: min: 0 (0) max: 255 (1) mean: 193.787 (0.759947) standard deviation: 82.9539 (0.32531) kurtosis: 0.0297665 skewness: -1.23898 entropy: 0.685253 Green: min: 0 (0) max: 255 (1) mean: 184.401 (0.723143) standard deviation: 86.1274 (0.337755) kurtosis: -0.661801 skewness: -0.927692 entropy: 0.700684 Blue: min: 0 (0) max: 255 (1) mean: 180.436 (0.707594) standard deviation: 88.9565 (0.348849) kurtosis: -0.921378 skewness: -0.802509 entropy: 0.702137 Image statistics: Overall: min: 0 (0) max: 255 (1) mean: 186.208 (0.730228) standard deviation: 86.0476 (0.337441) kurtosis: -0.554014 skewness: -0.986431 entropy: 0.696025 Rendering intent: Perceptual Gamma: 0.454545 Chromaticity: 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 Interlace: JPEG Intensity: Undefined Compose: Over Page geometry: 1169x826+0+0 Dispose: Undefined Iterations: 0 Compression: JPEG Quality: 90 Orientation: Undefined Properties: date:create: 2020-07-03T15:47:23+02:00 date:modify: 2020-07-02T09:28:01+02:00 jpeg:colorspace: 2 jpeg:sampling-factor: 1x1,1x1,1x1 signature: ddfbaa24065f98aaa0cf27b27a2eefe877fbf27d527ba27b66c2dbcb35fe72d1 Artifacts: filename: 1.jpg verbose: true Tainted: False Filesize: 165KB 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: https://nonsoloprogrammi.net/wp-content/uploads/2015/01/collage.jpg 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 cf0bd70b9b64b302e490d2799ae207b5 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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 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 | |
| 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 | |
| 2020-07-03 17:36 | jghali | Note Edited: 0047779 | |
| 2020-07-03 17:53 | jghali | Note Edited: 0047779 | |
| 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 | |
| 2020-07-16 09:43 | jghali | Note Edited: 0047839 | |
| 2021-11-09 20:55 | jghali | Relationship added | has duplicate 0016677 |
