[softwarelist] Re: Odd DPlngScan error
- From: Chris Johnson <chris@xxxxxxxxxxxxxxxxxxxxx>
- To: davidpilling@xxxxxxxxxxxxx
- Date: Thu, 22 Dec 2016 21:33:18 +0000 (GMT)
In article <55f29736eddave@xxxxxxxxxxxxx>,
Dave Symes <dave@xxxxxxxxxxxxx> wrote:
As noted before going back to version 1.25 which has a much smaller
Max RAM set, the image is displayed without any bother.
I am pretty busy at the moment with other things, so have only just
seen this.
David is correct when pointing out that DPScan converts loaded images
to an RGB raster, akin to a sprite file. Therefore it will need a lot
more memory than the size of the jpeg, which is a compressed format
(and lossy) and may be very compressed. The size of the jpeg file is
not the factor, it is the pixel count of the image.
When you load an image, if the selected tool is either the pointer or
hand then, at the far right of the info window, there is an entry
'Size'. This shows the memory size being used for that image. I have
just loaded a 3000x2000 jpeg and the size in memory is 18M.
The next thing is the apparent difference between 1.25 and 1.27
(David's last release was 1.26, by the way). The code to load and
display a jpeg has not been changed by me. The only difference in
jpeg handling is that David links to version 6 (I think) of the IJPG
library, and I am using the later version 9.
Real RISC OS hardware appears ok. Your SARPC is fine. Later hardware
running RISC OS 5 is fine. I use it all the time without problem. I
have even managed to view and manipulate an image 18000x18000 (a NASA
composite high res image of Saturn and its rings).
The problem seems to be on RPCEmu. Can you load any jpegs at all? I
have no experience with that and have no idea how it manages memory.
One thing you could do is up the wimp slot and try again. DPScan
manges its own memory, claiming it from (increasing) the wimp slot or
from a dynamic area on the fly, depending on the OS in use. If there
still isn't enough RAM, then virtual memory (hard drive) is used -
much slower. Therefore the wimp slot setting shouldn't be a factor.
There is one caveat. The IJPG library routines may need to claim some
memory for internal temporary workspace. I think version 9 of the
library processes the image in bigger blocks. I did have to increase
the wimp slot quite a bit compared with 1.26 to get png and jpeg
loading with large images, but the value of 2MB I set it to works
fine on all the hardware I have tested on (BB, PB ES, iMX6, and
IGEPv5).
Assuming small jpegs can be loaded, I think the first thing to check
is whether there is a pixel count (or maybe width of the image) below
which things are fine, above which DPScan blows up. I know, for
example, that !Thump blows up if fed a jpeg with a width more than
about 8200 pixels (can't remember the exact value).
--
Chris Johnson
To unsubscribe or subscribe goto:
//www.freelists.org/list/davidpilling
Other related posts:
