View Issue Details

IDProjectCategoryView StatusLast Update
0016150ScribusPDFpublic2021-11-09 20:55
Reporterale Assigned To 
PrioritynormalSeverityminorReproducibilityN/A
Status newResolutionopen 
Product Version1.5.6.svn 
Summary0016150: try harder to embed jpg images as is
Descriptionwhen 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)
TagsNo tags attached.
PatchNo

Relationships

has duplicate 0016677 closedjghali Scribus bloats file size of single jpg image compared to output pdf 

Activities

jghali

2020-07-03 14:57

administrator   ~0047772

Last edited: 2020-07-03 14:58

>> 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.

ale

2020-07-03 16:45

manager   ~0047776

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...)

cbradney

2020-07-03 17:19

administrator   ~0047777

Yes this should be in the preflight verifier I think and potentially be analysed on jpeg import

jghali

2020-07-03 17:34

administrator   ~0047779

Last edited: 2020-07-03 17:53

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.

jghali

2020-07-03 18:00

administrator   ~0047783

>> 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.

ale

2020-07-03 18:12

manager   ~0047784

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.

beryllium2

2020-07-08 06:53

reporter   ~0047800

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

jghali

2020-07-08 11:06

administrator   ~0047802

Unfortunately the output of identify does not provide any helpful information.

jghali

2020-07-08 14:33

administrator   ~0047804

>> 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.

beryllium2

2020-07-15 13:00

reporter   ~0047836

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.

jghali

2020-07-15 23:29

administrator   ~0047839

Last edited: 2020-07-16 09:43

>> 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.

Issue History

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