View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002731 | Scribus | Import / Export | public | 2005-10-18 09:06 | 2012-03-14 19:38 |
| Reporter | gustavohomem | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| Platform | Linux | OS | Mandriva 2005 LE | OS Version | Mandriva 2005 LE |
| Product Version | 1.3.2cvs | ||||
| Summary | 0002731: Scribus produces *HUGE* PDFs if colour is chosen as "Printer" | ||||
| Description | For a files which contains, say 10MB of images, Scribus will export a reasonably sized PDF if colour target is "Screen/Web". Something like 12 or 13 MB will be the result if the "subset fonts option is used" (no other options besides "subset" and "colour intended for" are change from the defaults). However, if the colour target is "Printer" the resulting file size will be between 80 and 100MB. Here is an example archive with both the sla and the images: http://people.angulosolido.pt/~gustavo/scribus/barbie.tar.gz The resulting PDF for this document is 89 MB. Are we doing something wrong here ? | ||||
| Steps To Reproduce | Layout the document. Click on the export to PDF button. On the Fonts tab, choose "subset all fonts". On the Color tab choose Printer. | ||||
| Additional Information | The PDFs display OK on Acrobat, but can't be printed a on Laser Printer since they run out of memory (and laser printers must receive each page at once). | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
|
|
At least two of your images are at 1200dpi. Sounds like a lot of data to me when converting to CMYK. |
|
|
I wasnt expecting such a growth due to RGB->CMYK conversion, but if someone can confirm that this is normal, I can close this report. |
|
|
If both RGB source and CMYK destination format are uncompressed, you can expect about 33% growth, as you're going from three (usually 8-bit) channels to four. With compression, it depends largely on the method used (lossy / lossless, type and strength of compression). If you can post one of the PDFs somewhere I should be able to check it out in PitStop and see where the space is going. |
|
|
I was expecting something like a 33% growth, due to adding an extra colour component, exactly as you mentioned, instead of a 600% growth as I got. You can check the PDFs here: http://people.angulosolido.pt/~gustavo/scribus/PDF/ All of them were produced with "Output intended for" Printer, except press-screen.pdf No other options besides "subset" and "colour intended for" were changed from the defaults (so on image settings Method=Automatic, Quality=Maximum) |
|
|
I grabbed the smaller of the two print quality PDFs to have a look. Images take up 99.6% of the space. All images are CMYK encoded bitmap data that's been losslessly deflate-compressed. The main one I looked at was 3072x2048 px, working out to about 200x200 dpi given its 1075x716 pt dimensions. Translation: You have some *big* images in there. They're at a sensible DPI already so downsampling them probably isn't smart (though Scribus won't do that unless you ask it to anyway). Scribus is using lossless compression to store them. Consequently, they stay big. The only thing I'm wondering about is whether the image being used is zoomed and cropped significantly. The DPI, page size, and pixel dimensions suggest that. If so, it'd probably be nice if Scribus could crop off any unused parts. This can be done without additional loss if we're working with a lossless format already or if we're doing a colourspace conversion (and therefore decompressing a JPEG). As far as I can tell, to make your PDF smaller, you must sacrifice quality by losslessly compressing the images and/or downsampling them. If I recompress one image at max quality JPEG, it halves in size (from about 50% of uncompressed size down to about 25%). If I use "high" quality, it goes down to 6% size. I haven't played with downsampling since it looks like they're at a fairly low resolution already for a 21x29 cm page. I managed to crash Acrobat 6 while working on this PDF. That's usually not cause for worry, since frankly it's not the most stable app in the world, especially with PitStop loaded. Interestingly, it crashed when I deleted one of the images. I haven't tested to see if this is reproducable yet (I'm tired and have assignments to do) but will try to later. For now, I suggest you play with the image resampling and compression options in Scribus and see if you find something to your satisfatction - keeping in mind that you may well lose quality if you start playing with the images, especially if the originals were in JPEG or another lossy format. [edit: fix mantis's overenthusiastic conversion of tilde to note link] |
|
|
Craig, Thanks for your comment. From my standpoint, this is what remains unanswered: 1) does the image compression algorithm change by changing the "Output intended for" parameter ? 2) if so, is this intended to be this way ? (this is at least counter-intuitive IMHO, aren't colour space and compression method orthogonal concepts ?) Knowing the answer for these questions we may understand whether this is a bug or the desired behaviour. Quoting your comment: > Translation: You have some *big* images in there. They're at a sensible DPI > already so downsampling them probably isn't smart (though Scribus won't do > that unless you ask it to anyway). Scribus is using lossless compression to > store them. Consequently, they stay big. > So, why are they "smaller" with "Output intended for" set to Screen/Web? (you can compare press-printer.pdf with press-screen.pdf) > > The only thing I'm wondering about is whether the image being used is zoomed > and cropped significantly. The DPI, page size, and pixel dimensions suggest > that. If so, it'd probably be nice if Scribus could crop off any unused > parts. This can be done without additional loss if we're working with a > lossless format already or if we're doing a colourspace conversion (and > therefore decompressing a JPEG). > Are you suggesting that the invisible parts of the image (masked by the image frame) are actually present on the PDF ? If so, that's _surprising_, otherwyse I didn't understand what you meant. [...] > For now, I suggest you play with the image resampling and compression options > in Scribus and see if you find something to your satisfatction - keeping in > mind that you may well lose quality if you start playing with the images, > especially if the originals were in JPEG or another lossy format. I will do so, as soon as I understand what's the cause of this unexpected size difference. Thanks a lot for your feedback! |
|
|
1) I'll have to check the sources. I strongly suspect Scribus will use a lossy scheme for "web/screen" and a lossless scheme for "print" if "Method" is set to automatic. You can override that by setting your own compression method in the image settings on the main panel. 2) Yes, it's counter intuitive to have "Colour" control things like image compression methods too. That's a hold-over from older Distiller versions, which used similar terms for presets. I think the target needs to be removed from the "colour" section and put into the first page and used as a "preset". Image settings should go in a separate tab, and the "colour" tab should control colour space rather than a wider set of presets. Doing that involves tangling with code that's less than fun to work with, and I don't have the time to work on it right now (uni, other major scribus work to do, real paying work). I do think it needs doing and want to get to it. Yes, invisible parts of the image are present in the PDF. I too find that somewhat surprising, and was unaware of it until I investigated this issue. I was able to use Acrobat Professional to extract the full size images from your PDF. That explains the low DPI but high pixel dimensions - the image is actually there in full, just masked off with a path. At the very least that needs to be an option that's off by default for all images that Scribus must already resample, convert, or otherwise manipulate. One reason to include an un-cropped image is probably with JPEG images that you don't need to do anything else to and want them in JPEG format eventually. For those, you risk losing quality by cropping and recompressing, so it should probably be either controllable or tied to other settings. If a colourspace conversion or resampling is required that's irrelevant anyway. Another reason might be if there's a single image that's used in many places across the document with different cropping and zoom levels. In that case, though, it's probably best to extract the parts(s) that are actually used, though the calculation of that could get somewhat complex when trying to avoid duplicating parts of the image. I also found that there appear to be multiple images where each image is placed. It's not yet clear if that's an Acrobat / PitStop issue or a Scribus issue, and I don't yet know if that corresponds to multiple copies of the image in the file. Acrobat crashes when I try to delete one of the images with PitStop, so I'm having trouble investigating it right now. |
|
|
I get a 55mb file with current CVS after the recent CMYK JPG export changes. |
|
|
Excuse me, why is "Last update" for this issue shown as "12-Mar-14 16:32" (today) without anything corresponding in the "Issue History"? |
|
|
Because Jluc added himself to the monitoring list.. which is in the Issue History |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-10-18 09:06 | gustavohomem | New Issue | |
| 2005-10-18 19:35 | cbradney | Note Added: 0007131 | |
| 2005-10-19 16:36 | gustavohomem | Note Added: 0007140 | |
| 2005-10-20 04:22 |
|
Note Added: 0007141 | |
| 2005-10-20 04:23 |
|
Status | new => acknowledged |
| 2005-10-20 10:26 | gustavohomem | Note Added: 0007143 | |
| 2005-10-20 11:37 |
|
Note Added: 0007145 | |
| 2005-10-20 11:38 |
|
Note Edited: 0007145 | |
| 2005-10-20 22:11 | gustavohomem | Note Added: 0007158 | |
| 2005-10-20 22:12 | gustavohomem | Note Edited: 0007158 | |
| 2005-10-21 03:06 |
|
Note Added: 0007164 | |
| 2005-10-21 03:08 |
|
Note Edited: 0007164 | |
| 2005-10-21 03:09 |
|
Relationship added | related to 0002144 |
| 2005-10-21 03:10 |
|
Relationship added | related to 0001899 |
| 2005-12-07 23:06 | cbradney | Note Added: 0007667 | |
| 2012-03-14 17:48 | mabri | Note Added: 0027803 | |
| 2012-03-14 19:38 | cbradney | Note Added: 0027804 | |
| 2012-03-14 19:38 | cbradney | Note Edited: 0027804 |
