[Scribus] Can't place some JPEG images

[Craig Ringer]

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 
images are:

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

--
Craig Ringer