We have a serious issue that a lot of our iOS users encounter since the launch of our v1. The scanner crashes randomly on most iPhone SE and iPhone 6, both updated to the latest iOS version. It happens sometime a few seconds after the world is loaded or more randomly after a bit. Those iPhone are the only one we had in our studio with this issue, but it might affects other versions as well. Wikitude version is 8.2.0
Here is the crash report from iOS, which is the same for every incident (also attached the file) :
The images are cached in memory as far as I know. If you profile the memory usage in your device, you can verify that it increases along with the amount of PNGs that you load and their uncompressed size, there are no leaks on our end.
I must insist on reducing the resolution of your images. This is just the way PNGs work, regardless of our SDK. Considering that the uncompressed size of your first 10 images is 56.48MB, let's say 50 of your spritesheets take around 250-300MB in memory... That is demanding for many devices, and those resources are allocated just for your images. Add to that the memory in use by the OS, our SDK, your app... You are likely to go above the limit with so many PNGs of these large resolutions, particularly on a device with a maximum RAM of 1GB like the iPhone 6.
If you must have 50 spritesheets like these loaded at all times, I would reduce the width and height of all PNGs by half and try again. If that is not enough, halve their resolutions again and try once more. Otherwise, you should maybe reconsider the logic of your app to either decrease the targets that can be detected at anytime, or divide the existing ones between different scenes. This way you could destroy and generate ImageResource objects as needed, while only keeping one of them at a time with way less active targets than you have right now.
- Damian
1 person likes this
Wikitude Support
said
about 4 years ago
Hi,
Could you please provide the following details:
Is the same issue also happening with the latest version of the SDK?
What Xamarin version are you using?
Is this happening with the sample app or in your own app? If it happens with your own app, does the sample app work on the device that makes troubles?
If the issue is also happening with the SDK sample app and you made sure that the setup of your app is based as in the technical documentation, please send over the complete AR experience.
Thx and greetings
Nicola
M
Marlène Varnerin
said
almost 4 years ago
Hello Nicola,
Getting back to you, we dig the issue and we found that it's a memory problem linked with the class ImageResource. It happens on iPhone 6 when loading about 36 images of 200ko each. The same happen on iPhone SE and iPhone 6 S with about 100 ImageResources of the same size.
Is the same issue also happening with the latest version of the SDK?
Yes, both 8.2 and 8.10
What Xamarin version are you using?
The latest, but the same bug happen with older versions (with a very wide range of stable releases)
Is
this happening with the sample app or in your own app? If it happens
with your own app, does the sample app work on the device that makes
troubles?
It happens in the sample app as well if we modify slightly the scripts to load that many ImageResources from internet. I attached a minimalist modification of the first sample's javascript file so you can reproduce it without all our project.
If
the issue is also happening with the SDK sample app and you made sure
that the setup of your app is based as in the technical documentation,
please send over the complete AR experience.
Yes, please find attached :
1) imageontarget.js, the script from the sample xamarin app that we just modified by adding the following lines :
/* REPRODUCE THE CRASH (about 50 images are enough for iPhone 6, putting more for testing purpose) */
var urls = [
"https://app.inclood.fr/parse/files/Inclood/c4b96e3afe6d39153625a7c6fbd6dd4f_01-LaureAbdelmoumeni1.png",
"https://app.inclood.fr/parse/files/Inclood/862639808eb3a0c939fb1ae6168e78f9_02-RoseMarieRaynaud.png",
"https://app.inclood.fr/parse/files/Inclood/01e889f1d2b60299af7fbe0f0b5f0959_04-Bonnesoeurs.png",
"https://app.inclood.fr/parse/files/Inclood/cc4fd246d89476836b9d7ff80a17b162_03-ZohraAbdelgheffar.png",
"https://app.inclood.fr/parse/files/Inclood/c6dadfc29cca0a466c23d00623e64ff9_04-JulieAbbou2.png",
"https://app.inclood.fr/parse/files/Inclood/5bdd9eab2a7bbdd4030f27b0d08303fe_05-FCasasChastel.png",
"https://app.inclood.fr/parse/files/Inclood/de22be18ddbb14fb1d18f74e8707df9f_06-SophieScheidt.png",
"https://app.inclood.fr/parse/files/Inclood/89f4779c1c3cb5965109a72ff4fb582e_07-ManonAltazin.png",
"https://app.inclood.fr/parse/files/Inclood/94e36def1a2a7c6c8e7120c45c63abec_08-RonitLeven.png",
"https://app.inclood.fr/parse/files/Inclood/164767b90a5dd5d67774af45e0c4355d_10-EmmanuelleBoyer.png",
"https://app.inclood.fr/parse/files/Inclood/01b3ca690fb5a7fe7f53b59f7bd9e42b_09-LilaBensebaa.png",
"https://app.inclood.fr/parse/files/Inclood/c460195ff6a4ad9364c156b1f7e736c4_11-MTLHuillier.png",
"https://app.inclood.fr/parse/files/Inclood/14ebb57cce1d16482b9072e67eef9fdf_12-AudreyFlorenceau.png",
"https://app.inclood.fr/parse/files/Inclood/3c31ce0beaaf5f6e36e7b22d4c74aa0d_13-SylvieRochette.png",
"https://app.inclood.fr/parse/files/Inclood/10757f08b2fada2566369799690f3fa3_14-AnneMadec.png",
"https://app.inclood.fr/parse/files/Inclood/b4d3a0fd443e83463f94bd1012e57cb4_15-SophiaBallester.png",
"https://app.inclood.fr/parse/files/Inclood/7c5a0f38d4086b3ae5320c28558c6265_16-ClemenceColin.png",
"https://app.inclood.fr/parse/files/Inclood/667e9b9850f0b0c5b8163e64ad7d9d90_17-ELaboritCLiennel.png",
"https://app.inclood.fr/parse/files/Inclood/0dff0f4eaa5d829ae66d87e95629f083_18-DelphineStRaymond.png",
"https://app.inclood.fr/parse/files/Inclood/d1e0f29dd7db9fc997822faa5aa60ea8_19-PaulineStroesser.png",
"https://app.inclood.fr/parse/files/Inclood/9d6fc5ec78cdeac575a4546b623f14ac_20-MariamaDiolo.png",
"https://app.inclood.fr/parse/files/Inclood/0560648878f25a87e10bfdd4c33f420a_21-AnneSarahKertudo.png",
"https://app.inclood.fr/parse/files/Inclood/786717d140c854c175c5a5325509893b_22-NoemieChurlet.png",
"https://app.inclood.fr/parse/files/Inclood/474fb7ddbb68d7d97711c3e30d7b0a8e_23-AlexiaBailly.png",
"https://app.inclood.fr/parse/files/Inclood/55115bae61e122c8b03cb19eed8d43fa_24-CatherineZlatkovic.png",
"https://app.inclood.fr/parse/files/Inclood/0571e6609b9c1d2b0b3766168336322d_25-IsabelleVoizeux.png",
"https://app.inclood.fr/parse/files/Inclood/425344099f632f526fd4c96efa2a41ff_26-VeroniqueRoussel.png",
"https://app.inclood.fr/parse/files/Inclood/29427a9a985fb33c9cab4db2d2de6b6e_27-AgnesinaSecolier.png",
"https://app.inclood.fr/parse/files/Inclood/3923eb73b681436138cec61f2b78edb6_28-StephanieFloux.png",
"https://app.inclood.fr/parse/files/Inclood/b7c9e8f65f3d59743484eae882bae24a_29-IsabelleMalaurie.png",
"https://app.inclood.fr/parse/files/Inclood/ac2f54a9ceb09318ea59cdcb32137af0_30-ElodieLefur.png",
"https://app.inclood.fr/parse/files/Inclood/67a5f354e1f269cd959afb6469218c1c_31-SandrineHerman.png",
"https://app.inclood.fr/parse/files/Inclood/bde03e6f29a8a2c8319be2a49e646fc5_32-MarieGiraud.png",
"https://app.inclood.fr/parse/files/Inclood/82b9cac94fbeb77c789e4be15ce74918_33-MaryvonneVanoye.png",
"https://app.inclood.fr/parse/files/Inclood/081f8bf47f8db4c25cbbdb406da9ecb0_34-AmandineMansilla.png",
"https://app.inclood.fr/parse/files/Inclood/ff2fcfa29e3a0db08551e9921f4ef452_35-ThumetteLeon.png"
];
var repetitions = 4; // to make sure the crash happen on SE or iphone6 S as well (but 35 are enough to make iphone6 crash)
for(var i = 0; i < urls.length * repetitions; i++) {
var imgOne = new AR.ImageResource(urls[i % urls.length], {
onError: World.onError
});
}
2) crash logs when that happens, which is a memory error code from iOS
Many thanks for your help, don't hesitate to reach me for more information (we tried various thing, such as loading those resources sequentially with promises, etc. without success). It's a very critical issue for us.
If that can help, we also tried to download locally the files on the first hand and creating ImageResource from the local files : the same thing happens.
Wikitude Technical Support
said
almost 4 years ago
Hi Marlène,
Looks like you are using the image URLs individually. Have you already tried generating a wtc file in Wikitude Studio with all your targets and initializing the TargetCollectionResource with it, as we do in our sample app?
Please keep in mind the limitations for image targets that are specified in our documentation:
Non-transparent PNG and JPEG files of maximum 10MB file-size are supported formats for image-target creation. A WTC file may hold up to 1,000 targets for offline processing while with online Cloud Recognition, the WTC file supports up to 50,000 different images.
Let us know if that helps.
- Damian
M
Marlène Varnerin
said
almost 4 years ago
Hi Damian,
Thank your for your help and assistance. For now, we sorted this issue out by dynamically adapting the size of the served spritesheets to the device.
To anyone reading this and working with a large collection of tracked image and associated drawable animations, the best option you have is to cache them on the disk manually and to create the drawable's ImageResource object on the go when the associated target is detected. It would have been nice to have an option to cache the ImageResource objets on disk instead of memory to create the target-drawable association on load instead of on-the-go.
Kind regards,
M
Marlène Varnerin
said
almost 4 years ago
Hello Damian,
Thanks a lot for your answer. However as mentioned in our post, the whole issue is about the ImageResource class, not ImageTarget. We do use a .wtc file (there is no other choice in version 8.2) for the targets and we don't have more than 36. The snippet we attached are spritesheets drawn over targets.
In our previous post we attached the memory crash as well as a very slightly modified javascript code to use in place of the first sample in the xamarin example application so that you can reproduce it. It seems there is a very critical issue in the way memory is managed with ImageResource and we tried every workaround we could as I mentioned...
If we can give you any further elements, please let me know,
Kind regards,
Wikitude Technical Support
said
almost 4 years ago
Hi Marlène,
I'm sorry for the misunderstanding.
Upon closer inspection of the images you linked previously, you seem to be working with quite large resolutions, that is an important factor on this issue. Even if the size of a PNG is about 200KB, once it is uncompressed it could take several MB in memory. Your first 10 images alone are already taking about 56.48MB in memory once uncompressed, this is definitely a problem when you load so many PNGs with these resolutions at once.
First, I would recommend reducing the resolution of the PNGs that you are working with. I would also suggest to include only the PNGs that you currently need in the ImageResource, instead of loading them all at the same time. Once you require other images, destroy the previous ImageResource and create another one with the new PNGs.
I hope that helps, please let us know either way.
- Damian
M
Marlène Varnerin
said
almost 4 years ago
Many thanks for your reply Damian.
Our understanding was a bit different. According to your team answer on this thread : https://support.wikitude.com/support/discussions/topics/5000076804 : <<However, you can load the images directly inside the AR World from a
remote URL, they are cached internally and accessed dynamically when
needed.>>. What you imply however is that all the image resources are kept in the memory and not cached ?
If that's not the case, could you please guide us a bit on the proper way of doing the following ?
We have about 50 ImageTargets that can be detected at anytime without specific order (but one by one)
For each ImageTarget, we have a spritesheet (that can be large sometime, depending on the drawing)
We need to overlay an AnimatedImageDrawable right away on the top of any detected Target.
If I'm right, all your samples preload the ImageResources before detection and I believe that is necessary to avoid a delay between the detection of a target and its augmentation.
Marlène Varnerin
We have a serious issue that a lot of our iOS users encounter since the launch of our v1. The scanner crashes randomly on most iPhone SE and iPhone 6, both updated to the latest iOS version. It happens sometime a few seconds after the world is loaded or more randomly after a bit. Those iPhone are the only one we had in our studio with this issue, but it might affects other versions as well. Wikitude version is 8.2.0
Here is the crash report from iOS, which is the same for every incident (also attached the file) :
- Oldest First
- Popular
- Newest First
Sorted by PopularWikitude Technical Support
Hi Marlène,
The images are cached in memory as far as I know. If you profile the memory usage in your device, you can verify that it increases along with the amount of PNGs that you load and their uncompressed size, there are no leaks on our end.
I must insist on reducing the resolution of your images. This is just the way PNGs work, regardless of our SDK. Considering that the uncompressed size of your first 10 images is 56.48MB, let's say 50 of your spritesheets take around 250-300MB in memory... That is demanding for many devices, and those resources are allocated just for your images. Add to that the memory in use by the OS, our SDK, your app... You are likely to go above the limit with so many PNGs of these large resolutions, particularly on a device with a maximum RAM of 1GB like the iPhone 6.
If you must have 50 spritesheets like these loaded at all times, I would reduce the width and height of all PNGs by half and try again. If that is not enough, halve their resolutions again and try once more. Otherwise, you should maybe reconsider the logic of your app to either decrease the targets that can be detected at anytime, or divide the existing ones between different scenes. This way you could destroy and generate ImageResource objects as needed, while only keeping one of them at a time with way less active targets than you have right now.
- Damian
1 person likes this
Wikitude Support
Hi,
Could you please provide the following details:
Thx and greetings
Nicola
Marlène Varnerin
Hello Nicola,
Getting back to you, we dig the issue and we found that it's a memory problem linked with the class ImageResource. It happens on iPhone 6 when loading about 36 images of 200ko each. The same happen on iPhone SE and iPhone 6 S with about 100 ImageResources of the same size.
2) crash logs when that happens, which is a memory error code from iOS
Many thanks for your help, don't hesitate to reach me for more information (we tried various thing, such as loading those resources sequentially with promises, etc. without success). It's a very critical issue for us.
Marlène Varnerin
If that can help, we also tried to download locally the files on the first hand and creating ImageResource from the local files : the same thing happens.
Wikitude Technical Support
Hi Marlène,
Looks like you are using the image URLs individually. Have you already tried generating a wtc file in Wikitude Studio with all your targets and initializing the TargetCollectionResource with it, as we do in our sample app?
Please keep in mind the limitations for image targets that are specified in our documentation:
Non-transparent PNG and JPEG files of maximum 10MB file-size are supported formats for image-target creation. A WTC file may hold up to 1,000 targets for offline processing while with online Cloud Recognition, the WTC file supports up to 50,000 different images.
Let us know if that helps.
- Damian
Marlène Varnerin
Hi Damian,
Thank your for your help and assistance. For now, we sorted this issue out by dynamically adapting the size of the served spritesheets to the device.
To anyone reading this and working with a large collection of tracked image and associated drawable animations, the best option you have is to cache them on the disk manually and to create the drawable's ImageResource object on the go when the associated target is detected. It would have been nice to have an option to cache the ImageResource objets on disk instead of memory to create the target-drawable association on load instead of on-the-go.
Kind regards,
Marlène Varnerin
Hello Damian,
Thanks a lot for your answer. However as mentioned in our post, the whole issue is about the ImageResource class, not ImageTarget. We do use a .wtc file (there is no other choice in version 8.2) for the targets and we don't have more than 36. The snippet we attached are spritesheets drawn over targets.
Wikitude Technical Support
Hi Marlène,
I'm sorry for the misunderstanding.
Upon closer inspection of the images you linked previously, you seem to be working with quite large resolutions, that is an important factor on this issue. Even if the size of a PNG is about 200KB, once it is uncompressed it could take several MB in memory. Your first 10 images alone are already taking about 56.48MB in memory once uncompressed, this is definitely a problem when you load so many PNGs with these resolutions at once.
First, I would recommend reducing the resolution of the PNGs that you are working with. I would also suggest to include only the PNGs that you currently need in the ImageResource, instead of loading them all at the same time. Once you require other images, destroy the previous ImageResource and create another one with the new PNGs.
I hope that helps, please let us know either way.
- Damian
Marlène Varnerin
Many thanks for your reply Damian.
Our understanding was a bit different. According to your team answer on this thread : https://support.wikitude.com/support/discussions/topics/5000076804 : <<However, you can load the images directly inside the AR World from a remote URL, they are cached internally and accessed dynamically when needed.>>. What you imply however is that all the image resources are kept in the memory and not cached ?
If that's not the case, could you please guide us a bit on the proper way of doing the following ?
If I'm right, all your samples preload the ImageResources before detection and I believe that is necessary to avoid a delay between the detection of a target and its augmentation.
We are grateful for your time and help,