[Scribus] Can't place some JPEG images
Wed Sep 13 09:29:57 CEST 2006
ols6000 at sbcglobal.net wrote:
> There have been a number of suggestions for dealing with Scribus'
> inability to handle some images. None of these has been useful in
> getting at the root cause of the problem, which is most likely to be
> in the code that Scribus executes to get the image. Doing a number of
> experiments to see what does and doesn't work may provide some clues,
> but will not make Scribus work any better, which is the goal.
> 6500 x 4000 pixels at 600 dpi is not that large (about 11 x 6
> inches), nor is the 104 Mb (4 bytes/pixel?) that is required for the
> image. I'm assuming, perhaps incorrectly, that Scribus has the
> ability to crop images.
It is able to crop images, yes, but still needs to load the whole image
initially. Additionally it doesn't crop the in-memory preview image,
since you'll often change the amount of the image visible or use it in
two or more different places with different amounts of the image visible.
The image will usually be stored in a 32 bit per pixel format, yes -
IIRC either CMYK, RGBA, or plain 24 bit RGB with 8 bits of padding
(alignment reasons and because lots of libraries want it that way). Due
to an old design problem in the code, 1.2.x and (I think) 1.3.3.x
require twice that RAM to store the image due to problems with the
buffer storage class.
Some of the things that would help reduce Scribus's RAM consumption with
- Downsampling large images for display previews in portions rather
than loading the whole image then downsampling it. This is probably
related to the problem you're having.
- Loading large images progessively when sending them to PDF via
libjpeg, rather than loading the whole image into a buffer and
sending that to libjpeg. Note that if you're not resampling the
image, it's already in JPEG format, and no colour management need
be done, Scribus already just includes the original JPEG file
directly in the PDF (very quick and efficient). I think Franz
is working on progressive image loading for PDF export.
- **NEVER** shoving image data in QString instances. I think Jean
& Andreas fixed most or all of this particularly serious problem
recently, halving the RAM requirements for lots of images. I think
this fix is only in 1.3.4 (?) so far.
There are probably more areas where RAM is unnecessarily wasted in image
handling. A thorough investigation of all pathways in image handling
code would be very interesting and very useful. I'm sure there's a huge
amount of room for improvement, but those improvements will be far from
trivial to make.
> So, can we hear from someone familiar with the Scribus source code,
> who can tell me where to start looking? Then I will be asking for
> advice on how to build Scribus under Windows.
Currently the build requires MSVC++, a bunch of custom build libraries,
a hand-made project file that needs regular updates, and a lot of
mucking about. Jean doesn't have the build files for win32 in a state
where they're really releasable at this point. Both he and I are
interested in getting CMake builds for win32 working eventually (I did
some work on it a while ago; Jean more recently and probably more
effectively) but there's nothing ready yet, and no guarantee on when it
will be. Even then, there's still the fun of getting all the required
libraries built and packaged.
More information about the scribus