jpeg datatype

Gilloo · 26 December 2023, 19:49

For this test I set 8MB chip and 128MB fast in WinUAE.
3.1 and 3.1.4 jpeg datatype seens to refuse big jpeg pictures.
a 5472x3648 jpeg can't load with multiview, saying "not enough memory".

Is there a limitation on sizes with datatypes ?

paraj · 26 December 2023, 21:50

Experimenting a bit it seems like multiview allocates a BitMap for the image it wants to display, and you're thus limited by "video memory" (chipmem for traditional modes, and graphics mem for RTG-modes). The datatype probably handles such images just fine assuming you have enough (contiguous?) memory.

thomas · 26 December 2023, 22:07

As paraj said, a picture of 5472 x 3648 pixels in truecolor needs at least 5472 x 3648 x 3 bytes of Fast RAM and converted to native mode 5472 x 3648 bytes of Chip RAM. That's around 60 MB Fast RAM and 20 MB Chip RAM.

Try to add 32bit Chip RAM instead of (or in addition to) Fast RAM.

Gilloo · 27 December 2023, 13:27

Thanks @thomas @paraj

60MB + 20 MB => 128MB of 32bit chip RAM and it load as a charm.
128MB of chip, this is not a very common configuration...

This limitation is due to the jfif.datatype or the picture.datatype ?

derSammler · 27 December 2023, 14:46

It's not a limitation of a datatype, but, as paraj already stated, of available video memory. You can not display an image that is larger than what fits into video memory. Using RTG, you can get around the chip mem limitation, because video memory is then provided by the (emulated) graphics card.

paraj · 27 December 2023, 14:50

It's multiview that's the limiting factor here. A more advanced image viewer could show you the picture. What happens is:

1. The image is loaded to fast memory (taking ~ 60MB)
2. Multiview wants to display the image and allocates a displayable BitMap (i.e. in chipmem for native modes, or RTG video memory): At 8bpp that's the ~20MB. This is where memory allocation fails. If you change screen mode to 640x256x4 it'd be ~5MB, and should be displayable with 8MB chip.

If you emulate a RTG card (installing the relevant drivers etc.) and change screen mode to e.g. 640x480x32bit and make sure the card has ~128MB of memory you will also be able to display the picture.

Another approach is to find an image viewer that only allocates as much video (chip) memory as is necessary to show the visible (possibly scaled) part of the image.

26 December 2023, 19:49	#1
Gilloo Registered User Join Date: Nov 2010 Location: Grenoble, Isère, Rhône-Alpes, France, Europe, Earth Posts: 297	jpeg datatype For this test I set 8MB chip and 128MB fast in WinUAE. 3.1 and 3.1.4 jpeg datatype seens to refuse big jpeg pictures. a 5472x3648 jpeg can't load with multiview, saying "not enough memory". Is there a limitation on sizes with datatypes ?

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
ADpro JPEG error	FerociousAmiga	support.Apps	4	25 April 2022 01:40
NewDTObject with JPEG datatype crash	betajaen	Coders. C/C++	7	22 February 2022 12:35
Using JPEG with Amos	WAKD	support.Apps	25	21 January 2021 07:57
AROS: ico.datatype and info.datatype	AMIGASYSTEM	News	0	17 October 2018 08:53
JFIF (JPEG) picture datatype 44.9	HanSolo	support.Apps	8	01 September 2018 12:38

26 December 2023, 21:50	#2
paraj Registered User Join Date: Feb 2017 Location: Denmark Posts: 1,218	Experimenting a bit it seems like multiview allocates a BitMap for the image it wants to display, and you're thus limited by "video memory" (chipmem for traditional modes, and graphics mem for RTG-modes). The datatype probably handles such images just fine assuming you have enough (contiguous?) memory.

26 December 2023, 22:07	#3
thomas Registered User Join Date: Jan 2002 Location: Germany Posts: 7,030	As paraj said, a picture of 5472 x 3648 pixels in truecolor needs at least 5472 x 3648 x 3 bytes of Fast RAM and converted to native mode 5472 x 3648 bytes of Chip RAM. That's around 60 MB Fast RAM and 20 MB Chip RAM. Try to add 32bit Chip RAM instead of (or in addition to) Fast RAM.

27 December 2023, 13:27	#4
Gilloo Registered User Join Date: Nov 2010 Location: Grenoble, Isère, Rhône-Alpes, France, Europe, Earth Posts: 297	Thanks @thomas @paraj 60MB + 20 MB => 128MB of 32bit chip RAM and it load as a charm. 128MB of chip, this is not a very common configuration... This limitation is due to the jfif.datatype or the picture.datatype ?

27 December 2023, 14:46	#5
derSammler Senior Member Join Date: Jun 2001 Location: Germany Posts: 1,667	It's not a limitation of a datatype, but, as paraj already stated, of available video memory. You can not display an image that is larger than what fits into video memory. Using RTG, you can get around the chip mem limitation, because video memory is then provided by the (emulated) graphics card.

27 December 2023, 14:50	#6
paraj Registered User Join Date: Feb 2017 Location: Denmark Posts: 1,218	It's multiview that's the limiting factor here. A more advanced image viewer could show you the picture. What happens is: 1. The image is loaded to fast memory (taking ~ 60MB) 2. Multiview wants to display the image and allocates a displayable BitMap (i.e. in chipmem for native modes, or RTG video memory): At 8bpp that's the ~20MB. This is where memory allocation fails. If you change screen mode to 640x256x4 it'd be ~5MB, and should be displayable with 8MB chip. If you emulate a RTG card (installing the relevant drivers etc.) and change screen mode to e.g. 640x480x32bit and make sure the card has ~128MB of memory you will also be able to display the picture. Another approach is to find an image viewer that only allocates as much video (chip) memory as is necessary to show the visible (possibly scaled) part of the image.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)