@Karlos

I tryed the images also on LoView with "USEWPA" ToolType, MysticView and WarpView and get:

- on LoView I can load/show all images without problems

- on WarpView no problem

- on MysticView I get a crash when trying to open one of the images that remains grey on multiview in 16bit

I've done the test in 32 bit scrrenmode.


EDIT: on mysticview the crash was recoverable and after that no crash anymore when cycling loading again the same picture that crashes before...
If I load before the 24 bit I get crash and if I load then te 8 bit no crash...but if I load 8 bit alone or for the first time I get the recoverable crash...

Last edited by Tuxedo on 09-Jan-2012 at 11:46 PM.

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

@Tuxedo

Forget the 12288-wide 8/24-bit images, they might be encoded differently as they were created afterwards in a separate tool than I used for the others. They render fine in gnome's built-in viewer but I only just noticed they are problematic in some other viewers too.

The overall tests so far suggest that the depth of the source image is not a factor, so just use the 32-bit ones.

Last edited by Karlos on 10-Jan-2012 at 12:07 AM.

_________________
Doing stupid things for fun...

I tested my BVision under OS 4.1.4. It exhibits exactly the same behaviour as the Radeon on my A1. It's safe to conclude that it's not a driver-imposed ceiling.

_________________
Doing stupid things for fun...

@Karlos

I tested unter WinUAE 3.1+AfaOS and used ImageConverter. All images are loaded fine without gfx corruption or error messages.

_________________
--
Author of
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more...
Homepage: http://www.hd-rec.de

Quote:

Wanderer wrote: @Karlos I tested unter WinUAE 3.1+AfaOS and used ImageConverter. All images are loaded fine without gfx corruption or error messages.

Well, if you are using AfaOS's picture.datatype, that could explain it - it might not be allocating bitmaps using friend bitmaps like the OS4.x one does. The RTG emulation in WinUAE may also have different BytesPerRow limits.

_________________
IBrowse, AmiSSL and Warp Datatype Developer

@ALL

I'm recovering that 3 years old thread to signal that the ugly problem with images wider than 8192 pixels was still here in AmigaOS4.1FE.....
Was really annoing to gets Not enough memory with images that occupy less than half gigabyte and you have 1GB...
Using The USEWPA ToolType LoView still loads the image, MOS 3.7 on 1GB cant load and MultiView miresably say "Not enough memory"...
WarpView show the image correctly and really fast.

Anyone involved in AmigaOS4.x development can say anything related to that problem?

Thank you.

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

@Tuxedo

Perhaps it's your graphics card limitation.

Quote:

A Radeon 9000 series cards can't handle textures larger than 2048x2048, and so that's the limit for compositing.

- Hans de Ruiter

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@number6

I dont think it is that because it is only display issue. Driver can split operations to smaller regions.

On MorphOS when using Multiview you need continues memory block for image data. When image is huge (is 8129 pixels huge anymore?) you need large continuous memory block and they are hard to get. I would guess it is same on OS4.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

Thanks.

I recall contiguous memory requirements on 68k, that brought up similar questions. User has enough memory, but...

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@number6

if you read the thread was explained the problem, its AmigaOSx.x picture.datatype related...

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

@Tuxedo

Then possibly the number 8192, which is a magic number.

That's all I can think of.

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@thread

There is a limit of 8192 for the largest bitmap creatable under AmigaOS4

You *can* load images larger than this as long as you don't use the datatype to display them, just extract the data using the Read and Write pixels methods.

This is not a bug as such.


[edit]

Remove an eroneosu calculation
[/edit]

Last edited by broadblues on 17-Mar-2015 at 11:37 PM.

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad

@broadblues

ok but that way MultiView(for example) cant load nothing that size...

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

@broadblues

Quote:

There is a limit of 8192 for the largest bitmap creatable under AmigaOS4

Limit in which sense? Application (max allocable bitmap size) or driver level?

Using my viewer, HottiesView, I tested IP96->p96AllocBitMap() OK up to 70 MP megapixels 7000x10000 ...

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

@Massi

the problem was orizontal size...
I just tryed and with the image I linked at the beginning of the thread HottiesView says Out of memory...

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

@Tuxedo

OK and thanks for the test

I guess you got a "not enough free video memory" message.

I still wonder if it is a limit at application or driver level.

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

@Tuxedo

Quote:

Was really annoing to gets Not enough memory with images that occupy less than half gigabyte and you have 1GB...

That is probably because the image is loaded into the video memory (for example 128 MB) instead of the system memory (1 GB).

Quote:

WarpView show the image correctly and really fast.

WarpView very likely loads the whole image into the system memory and then blits (= copy) a smaller part of it to the video memory for display.

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

@Massi

as stated above was a limit of picturte.datatype...no other problem...loading such images with differetn method dont give the problem...

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

@Tuxedo

OK thanks.

Sure it is the picture datatype?

It seems to me that broadblues refers to the graphics system (P96, graphics library) instead ...

Last edited by Massi on 18-Mar-2015 at 02:34 PM.

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

@Massi

Last time I checked 7000 < 8192

For clarity the limit is on the *width* of the bitmap, not the hight.

The out of memory error is simply because the datatype failed to allocate a bitmap, so assumed the reason for that was out of memory. (video memory).

_________________
BroadBlues On Blues BroadBlues On Amiga Walker Broad