Model Explicit Likelihood Inference

Context
Documenting field-level explicit likelihood inference from a differentiable cosmological model.
In code, we run joint inferences of the initial field ($64^3$ mesh), cosmological parameters ($\Omega_c$ and $\sigma_8$), and Lagrangian bias parameters.
For one-chain samplers, chains are initialized on fiducial.
In order to assess chain convergences, so to observe a potential bias in the sampling process, we should limit the other sources of bias. For instance, observations should be generated with no likelihood noise. This doesn't solve that all, cf. a simple $\mathcal N(x|z^2,I)$ likelihood model. In any case, samplers will be compared with respect to a reference posterior obtained by an Implicit Likelihood Inference method.
Aims
Samplers to test:

[ ] Hamiltonian Monte Carlo (HMC)

Implemented in numpyro

[ ] HMCGibbs

Implemented in numpyro

[ ] No-U-Turn Sampler (NUTS)

Implemented in numpyro

[ ] MicroCanonical Langevin Monte Carlo (MCLMC)

Implemented in BlackJax

[ ] Variational self-Boosted Sampling (VBS)

cf. paper

[ ] Metropolis-Adjusted Langevin Algorithm (MALA)

Implemented in numpyro via a tensorflow_probability wrapper

[ ] custom version of "Continuously Annealed Langevin Algorithm (CALA)"

cf. #1

NUTS
NUTS max_tree_depth comparison.
num_samples adapted to max_tree_depth such that each run required about 36,000 Hamiltonian steps, 3h wall time.

NUTS, mtd=12
using 75 rows, 6 parameters; mean weight 1.0, tot weight 75.0

mean
std
median
5.0%
95.0%
n_eff
r_hat

Omega_c
0.25
0.01
0.25
0.24
0.26
28.92
1.02

b1
0.98
0.03
0.98
0.94
1.03
11.48
1.11

b2
-0.03
0.01
-0.03
-0.05
-0.01
16.63
1.07

bnl
0.32
0.24
0.32
-0.05
0.68
34.93
1.06

bs
-0.01
0.04
-0.01
-0.08
0.07
28.06
1.18

sigma8
0.84
0.01
0.84
0.82
0.86
14.29
1.02

NUTS, mtd=10
using 300 rows, 6 parameters; mean weight 1.0, tot weight 300.0

mean
std
median
5.0%
95.0%
n_eff
r_hat

Omega_c
0.25
0.01
0.24
0.23
0.26
60.32
1.04

b1
0.98
0.03
0.98
0.93
1.05
6.95
1.00

b2
-0.03
0.02
-0.03
-0.06
0.00
6.78
1.03

bnl
0.39
0.30
0.40
-0.10
0.87
36.07
1.02

bs
-0.00
0.05
-0.00
-0.08
0.07
9.04
1.05

sigma8
0.83
0.02
0.83
0.80
0.86
6.56
1.01

NUTS, mtd=8
using 1215 rows, 6 parameters; mean weight 1.0, tot weight 1215.0

mean
std
median
5.0%
95.0%
n_eff
r_hat

Omega_c
0.25
0.01
0.25
0.23
0.26
41.84
1.00

b1
0.99
0.02
0.99
0.96
1.01
16.98
1.01

b2
-0.03
0.01
-0.03
-0.05
-0.01
18.18
1.03

bnl
0.38
0.23
0.37
-0.01
0.72
14.33
1.09

bs
0.02
0.04
0.01
-0.04
0.08
15.78
1.11

sigma8
0.83
0.01
0.83
0.82
0.84
14.88
1.03

NUTS, mtd=3
using 44290 rows, 6 parameters; mean weight 1.0, tot weight 44290.0

mean
std
median
5.0%
95.0%
n_eff
r_hat

Omega_c
0.25
0.01
0.25
0.24
0.26
8.39
1.02

b1
1.03
0.01
1.03
1.01
1.05
15.61
1.03

b2
-0.01
0.01
-0.01
-0.03
0.01
4.96
1.28

bnl
0.17
0.26
0.15
-0.24
0.60
5.79
1.48

bs
0.02
0.04
0.03
-0.04
0.09
3.56
1.73

sigma8
0.82
0.01
0.82
0.81
0.83
7.73
1.00

Long run
Preliminary

Posterior Analysis
Some comments on posterior samples, here 1560 samples obtained by NUTS (mtd=10).

The posterior power spectrum, and its bilateral quantile-based intervals.

Here is a triangle plot of several mesh samples along directions $x, y, z$, i.e. $\delta(i,0,0)$ for $x$, $\delta(0,i,0)$ for $y$, etc., and index $i = 10\times i \text{Mpc}/h$. No strong correlations appearing here, at any distances.

Here posterior covariance matrix (diagonal) vs. the inverse mass matrix learned by NUTS (diagonal). Quite adequate on cosmology and biases, very noisy on initial mesh.

Reparametrization comparison
Comparing between standardly and unstandardly parametrized models, sampled with NUTS (max_tree_depth=10).

Triangle plots for 2048 then 8192 samples.

Summary Tables
NUTS, mtd=10, standard param
using 8192 rows, 6 parameters; mean weight 1.0, tot weight 8192.0 (8 chains grouped by)

mean
std
median
5.0%
95.0%
n_eff
r_hat

Omega_c
0.25
0.01
0.25
0.23
0.26
1285.74
1.00

b1
0.99
0.03
0.99
0.95
1.04
213.41
1.02

b2
-0.03
0.01
-0.03
-0.05
-0.01
399.69
1.01

bn2
0.36
0.29
0.36
-0.09
0.85
816.97
1.01

bs2
0.02
0.05
0.02
-0.07
0.10
378.71
1.01

sigma8
0.83
0.01
0.83
0.81
0.85
245.57
1.02

NUTS, mtd=10, unstandard param
using 10240 rows, 6 parameters; mean weight 1.0, tot weight 10240.0  (8 chains grouped by)

mean
std
median
5.0%
95.0%
n_eff
r_hat

Omega_c
0.25
0.01
0.25
0.23
0.26
1573.10
1.00

b1
0.99
0.03
0.99
0.94
1.04
178.29
1.03

b2
-0.03
0.01
-0.03
-0.05
-0.01
324.02
1.01

bn2
0.37
0.29
0.37
-0.11
0.85
723.79
1.01

bs2
0.02
0.05
0.02
-0.06
0.10
340.57
1.01

sigma8
0.83
0.01
0.83
0.81
0.85
207.84
1.02

Theory
This is consistent with theory. Likelihood acts as a filter of the prior information. Standard parametrization makes the prior better conditioned, but depending on the likelihood, this can make the posterior better or worse conditioned.

If the parameters are equally constrained, i.e. the likelihood is aligned with the prior, then it is better to reparametrize into a standard parametrization.
If the likelihood constrain parameters unequally,  i.e. the likelihood is not aligned with the prior, it can sometimes be better not to reparametrize.

example in code


What's the protocol's default _idmanager

When the user starts the login flow, the OIDC should query for the TXT record on _idmanager.<name>'s DNS.
What happens if the name has none?
Namebase's OIDC default action is to send the user to id.namebase.io which is Namebase's id manager.
However, during the registration process, this id manager asks the user to add only the device/fingerprint DNS record, keeping the id manager undefined.
If later, the same user tries to login using the same name, in a different website (that has its own OIDC) it won't be possible to know its idmanager.

Should we assume that no idmanager means id.namebase.io?
Is id.namebase.io open and expecting signing request from 3rd-parties, other than oidc.namebase.io?
Shouldn't id.namebase.io also asks its users to add the _idmanager DNS record?

The thought process on keeping the value undefined is to let a specific oidc provider handle their own default. A different OIDC provider could default to a different id manager.
The intent is to leave the separation of concern between the oidc provider and the id manager so the TXT _idmanager is being defined by the user intentionally and not being driven by the oidc component. To answer the point 3, yes the id manager should be the one responsible to prompt the user to set the TXT records for _idmanager. In the future id.manager.io could have an "eject" feature to set a custom _idmanager and deploy on heroku, s3, skynet, ...
The protocol does not impose a particular id manager. The implementation however requires a fallback. I am not sure the protocol necessarily requires a default value but I am curious to hear your thoughts if it has further implications. If the user did not decide to aggregate his identities into a custom identity manager, the oidc provider is in charge of defining its own fallback, this can be id.manager.io or a custom one. id.manager.io can totally be reused by other oidc provider. This would be an implementation decision.

If the user has used an OIDC, it MUST have use an idmanager as well. Probably the default for that OIDC, which is ok.
But that also means the user trust in the idmanager, also ok;
Any other OIDC (which has a separated concern from idmanager) should be able to use the previous and already trusted idmanager.
If every OIDC takes the same path as id.namebase.io of "if not set, use the default" the user will end up with a lot OIDC specific config, which could be avoided. And when a new OIDC decides not to use default values and asks the user to explicitly set an idmanager, all the other setup (individual OIDC's default idmanager) will be useless
Just ask your users to set their idmanager, what's the problem with that?

No problem with that quite the opposite! It has been considered as a future implementation but we have competing priorities at the moment. The release of the source code of the oidc provider is due. I hope it will help to submit PRs implementing these improvements.


Mode Select Cluster's On/Off feature is not supported

Problem

Mode Select Cluster's On/Off feature should be supported
Mode Select Cluster's On/Off feature is not supported

Proposed Solution
Implement the On/Off feature for Mode Select Cluster

Mode Cluster must be spec compliant for v1.
Removing tag v1_triage_split_4


TrayPublisher: Added more options for grouping of instances

Brief description
Grouping of instances has much more abilities. Instances can have their own group defined in data and creator plugin can define it's group label. This is just UI purpose change.
Description
Group label is defined by this order (if value is empty then next value is used):

key "group" in created instance data
attribute group_label on creator plugin
attribute label on creator plugin
attribute identifier on creator plugin

Additional info
Identifier must be available on creator plugin so it is end point. Default implementation returns creator's family which can be considered as last source.
Testing notes:
Creators group label

Define group_label on creator plugin and create it's instances
They should be grouped under that label

Instance group label

Create an instance with some string in "group" key in it's data
Instance should be grouped under that group in UI

Resolves https://github.com/pypeclub/OpenPype/issues/3490

I have tested two scenarios described in the PR description:

added group key to instance data > didnt work
added group_label key to instance data > this worked

Copy->Paste issue


Invoice request docs don't contain required Header Parameters

Describe the bug
The Invoice API requires Header parameters Amazon-Advertising-API-ClientId and Amazon-Advertising-API-Scope like the rest of the API but doesn't include this in the documentation. It just includes the Query Parameters
URL of the content

https://advertising.amazon.com/API/docs/en-us/invoices#tag/invoice/operation/getAdvertiserInvoices
https://advertising.amazon.com/API/docs/en-us/invoices#tag/invoice/operation/getInvoice

Description of what the documentation currently says

Description of what the documentation should say

Thanks for calling this out. You are correct that clientId and scope are required headers for this service. I will work on getting these updated and close the issue once it's resolved.


[Ride] 'Message To All' button doesn't correspond to the mock-up

Environment: Android 10, Samsung A7.
Reproducible: always.
Build found: v1.0.437.
Preconditions
The user is logged to the 'Car' application and the ride (e.g. Zaliznyi Port - Kherson, 24.11, 21:42) is created. Main paig is opened.
Steps to reproduce

Go to the 'Upcoming' rides
Tap appropriate ride (e.g. Zaliznyi Port - Kherson, 24.11, 21:42)

Actual result
'Message To All' button doesn't correspond to the mock-up
Expected result
Should be a 'Message All' button and correspond to the mock-up.
User story #4
Labels to be added
"Bug" ("bug"), Priority ("pri:low ")

mock-up

Should be 'Message All' instead of 'Message To All'


test can spawn fixture as a worker

closing - not worth the branching if we need both and we've found this is to do with missing (now incoming) bare functionality for duplex pipe overlapping support


Create a guideline for selecting the creator and audit provider scripts

Description
Some provider scripts (such as the Science Museum, which first raised the issue) can have several creators, and we need to select the correct option.
Science Museum can list several creators in the API. For example, a photograph of a replica of an object would have 3 creators: the original creator, the creator of a replica, and the photographer. For Openverse, I believe the creator should be the photographer, as that is the creator of the image that is marked with the specific license (or is in public domain). We can (and I think we should, to improve search relevancy) add the other creators as separate fields in the meta_data fields.
Examples from the original discussion
Originally posted by @stacimc in https://github.com/WordPress/openverse-catalog/issues/576#issuecomment-1198611794
Here's an example where the record is a (delightful) photograph: https://collection.sciencemuseumgroup.org.uk/objects/co8210526/timmy-the-cat-guardian-of-mr-browns-prize-budgerigars-gelatin-silver-print . In the json you can see that the maker will correctly attribute the photographer: https://collection.sciencemuseumgroup.org.uk/api/objects/co8210526
And then for @obulat's example, here's the API response: https://collection.sciencemuseumgroup.org.uk/api/objects/co56202. This one is several layers deep, because it's a photograph of a replica of an object created by Galileo Galilei, but he is the only source listed under maker. However in the type field, the maker type is labeled first as designer and also maker (original). Maybe we could use this to detect maker types that aren't true sources we want to identify as 'creator'.
The Board of Trustees is in that API response under source.legal.rights, so perhaps that could be a field we fall back to if there isn't an appropriate maker type.
Where possible we should probably keep these refactors as small as we can, though. But this is really interesting and definitely worth addressing -- I'm glad you noticed @obulat, good eye!
Note unrelated to this issue
It might also be a good idea to dump all text-based pieces of information such as Maker: Galileo Galilei; Replica Maker: xxx into a single field like description_for_search_purposes (it will probably not be readable and we shouldn't add it to the front end where we put description, but it will have data that would be nice to index to improve the search relevancy.

I agree, it sound like we should have multiple "tiers" with fallbacks as we look for the creator within the Science Museum metadata! I like the indexed description idea too, that sounds like it's also something we should look at down the line!


OutOfMemoryError in react-native 0.25

java.lang.OutOfMemoryError: Failed to allocate a 10969356 byte allocation with 8599832 free bytes and 8MB until OOM
at dalvik.system.VMRuntime.newNonMovableArray(Native Method)
at android.graphics.Bitmap.nativeCreate(Native Method)
at android.graphics.Bitmap.createBitmap(Bitmap.java:812)
at android.graphics.Bitmap.createBitmap(Bitmap.java:789)
at android.graphics.Bitmap.createBitmap(Bitmap.java:756)
at com.facebook.imagepipeline.memory.BitmapPool.alloc(BitmapPool.java:55)
at com.facebook.imagepipeline.memory.BitmapPool.alloc(BitmapPool.java:30)
at com.facebook.imagepipeline.memory.BasePool.get(BasePool.java:259)
at com.facebook.imagepipeline.platform.ArtDecoder.decodeStaticImageFromStream(ArtDecoder.java:137)
at com.facebook.imagepipeline.platform.ArtDecoder.decodeFromEncodedImage(ArtDecoder.java:81)
at com.facebook.imagepipeline.decoder.ImageDecoder.decodeStaticImage(ImageDecoder.java:127)
at com.facebook.imagepipeline.decoder.ImageDecoder.decodeImage(ImageDecoder.java:94)
at com.facebook.imagepipeline.producers.DecodeProducer$ProgressiveDecoder.doDecode(DecodeProducer.java:188)
at com.facebook.imagepipeline.producers.DecodeProducer$ProgressiveDecoder.access$200(DecodeProducer.java:96)
at com.facebook.imagepipeline.producers.DecodeProducer$ProgressiveDecoder$1.run(DecodeProducer.java:128)
at com.facebook.imagepipeline.producers.JobScheduler.doJob(JobScheduler.java:207)
at com.facebook.imagepipeline.producers.JobScheduler.access$000(JobScheduler.java:27)
at com.facebook.imagepipeline.producers.JobScheduler$1.run(JobScheduler.java:78)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
at com.facebook.imagepipeline.core.PriorityThreadFactory$1.run(PriorityThreadFactory.java:43)
at java.lang.Thread.run(Thread.java:818)
version:
"iflux-native": "^1.0.6",
"immutable": "^3.7.4",
"moment": "^2.10.6",
"object-assign": "^4.0.1",
"querystring": "^0.2.0",
"react": "^0.14.8",
"react-mixin": "^2.0.2",
"react-native": "0.25.1",
"react-native-barcodescanner": "^1.0.1",
"react-native-camera": "git+https://github.com/lwansbrough/react-native-camera.git",
"react-native-circular-progress": "0.0.5",
"react-native-code-push": "^1.7.3-beta",
"react-native-htmlview": "0.4.2",
"react-native-viewpager": "git+http://git.dev.qianmi.com/OF730/react-native-viewpager.git",
"react-timer-mixin": "^0.13.3",
"url": "^0.11.0"

It seems to me that it is a device problem...
The device doesn't have enough memory to handle whatever you are doing. (Treating an image I guess?).
We have the same problem on an old Android 4.4 device.
I'm not sure we can do anything about it, except optimize the treatment of the image.
Any Java wizard to do that ?

@wv1124 we have the same issue even on rn 0.28.0. seems to be a memory issue with the native android view pager. we get this when we do a lot of swiping in the view pager after 20 times the app crashes. On devices with less memory it crashes after 8 swipes. we moved to pure javascript implementation. Now it doesn't crash but it doesn't feel super native.

+1. We get this too, only on Android with RN 0.29.0.
Our app uses lots of photos. Eventually, if we click around, view peoples' profiles, close out the view, view someone else, over and over, we get OOM crash.
We have tried all the obvious stuff (android:largeHeap="true", making sure we load small/compressed images, etc). It seems like the images loaded via the  components are never getting fully cleaned up. I've even gone so far as to make sure that the RN core android code is calling .close() on the Fresco image (it seems to be doing it in src/main/java/com/facebook/react/modules/image/ImageLoaderModule.java:132,:141 ). Sort of out of ideas! Basically, if you keep browsing around, opening and closing things, etc, you eventually OOM error and crash on Android (not on iOS).

What is most likely happening is that you have images that haven't been removed from the view hierarchy, even if you can't see them. Often, this is because something in your app that needs to be treated like a ListView: what I mean by that is that if you have some UI where the user can scroll through items, sending them offscreen, then those offscreen views need to be unmounted temporarily until they come back on screen. This is especially important for images because if we think the image might appear back on screen soon we won't deallocate the bitmap from memory (and bitmaps are especially large).
If you're using our ViewPager, unfortunately it doesn't have great support for infinite scrolling. See https://github.com/facebook/react-native/blob/b0c023c85c9a1c675b6787c6292400c5fd229181/ReactAndroid/src/main/java/com/facebook/react/views/viewpager/ReactViewPager.java#L41-L49, there was apparently some incompatibility with the system ViewPager and the way we do layout which is keeping us from detaching children. I don't think this is a reasonable solution, but it's also not currently on our roadmap. If you want to try to fix it, you can get detaching behavior by removing the setOffscreenPageLimit calls and trying to see if you can debug the layout problems that were apparently happening.
If you're not using ViewPager, try to verify that you see image views being unmounted in your app (the lines you're pointing out @huitsing are related to closing the network request and not actually removing the image from the view hierarchy).

@astreet This also happens when reloading a bundle in dev mode. Probably images don't get cleared up when bridge gets destroyed?

That's possible, we'd need to do a memory analysis: could be other things that are not properly being released as well/instead.

Hi @astreet - We'll triple verify that the components are being unmounted properly. We don't think this is the problem, however. Wondering if it's related to facebook/fresco#1363, or some other reason the images aren't properly freed even after their component unmounts.

That could definitely be the case, though I don't think we actually require the finalizer to be called to drop the bitmap from memory: that should happen when the image is detached from the view hierarchy. e.g., you should see https://github.com/facebook/fresco/blob/4b94f604e0a98a999dcc1357992f8cb34b1b83b6/drawee/src/main/java/com/facebook/drawee/view/DraweeView.java#L173 when you unmount the view if things are working properly.

Yes, @astreet is correct - Fresco uses deterministic memory management so it is not dependent on the finalizers. The problem is probably with the integration somewhere - someone from the Fresco team will look into this this week.

Thanks @astreet and @balazsbalazs. You are both correct - we've run the app with memory profiling, and we do see large amounts of memory being both allocated and also released as we navigate around the app viewing photos. So for sure, in general, the image content is being freed successfully very quickly after the view containing the image content is closed.
Our problem must be more subtle. We've spent some time reducing image sizes, unmounting views more aggressively, etc, and are feeling much more comfortable about the memory usage. We've still can produce OOM errors, but they are infrequent and require long sessions within the app. I appreciate the tips of things to look into so far!

I'd be very interested to hear what you find out. What top level native components are you using? ScrollView, ViewPager, something custom? I ask since the other major thing I'd look for is not dropping Views (another large object, though not as large as images generally): this could either be a bug in the framework, though I'm not aware of anyone else hitting one besides the ViewPager one I mentioned above, or something to do with a custom viewmanager.

We have heavy use of <Image />, and then we use  <Modal /> <Navigator /> <View /> <ScrollView >, etc. We'll for-sure follow up if we find a smoking gun, and we'll look forward to any other activity around memory management.

Hi there,
I'm experiencing common OOM errors in my RN app. Currently it's basically a ListVIew with images loaded from the device storage and you can tap on any to see it full screen. I'm using a library react-native-transformable-image on top so that images can be zoomed and panned. They are loaded in their biggest size.
The thing, is that I end up with a Fatal Exception: java.lang.OutOfMemoryError because the app fails to allocate memory in the heap.

I've decided to track memory heap in my RN app and I can see how the app heap size gets slowly bigger and bigger until it collapses.

The images I'm loading are taken using the device camera in highest resolution available, in my Nexus 5X this results in pretty big images. If I use the allocation tracker, I can see how fresco imagepipeline JpegTranscoder is behind the biggest size chunks.

When I unload my full screen image detail, i can see how some memory heap is released, but I would say not all of it. I have the feeling that there is a memory leak somewhere, I have checked my RN app and i don't think it's in my JS code. If I downscale the image quality or size, the problem is still there although you simply need a longer session to crash the app.
This is happening in RN 0.30. is there anything I can send or do to fix this issue ?
Thanks

Just giving an update to this older issue:
We don't struggle with this problem too much any more. We've reduced the size of images loaded, turned on large heap, etc, and OOM crashes are no longer at the top of our list with more recent versions of React Native.

Closing this issue because it has been inactive for a while. If you think it should still be opened let us know why.

It still happens in 1.5.0. Following is the error log. Even if it is the problem of device, please do not throw this OOM error since I cannot catch it.
java.lang.OutOfMemoryError: Failed to allocate a 8294412 byte allocation with 1121032 free bytes and 1094KB until OOM
at dalvik.system.VMRuntime.newNonMovableArray(Native Method)
at android.graphics.Bitmap.nativeCreate(Native Method)
at android.graphics.Bitmap.createBitmap(Bitmap.java:843)
at android.graphics.Bitmap.createBitmap(Bitmap.java:820)
at android.graphics.Bitmap.createBitmap(Bitmap.java:787)
at com.facebook.imagepipeline.memory.BitmapPool.alloc(BitmapPool.java:53)
at com.facebook.imagepipeline.memory.BitmapPool.alloc(BitmapPool.java:28)
at com.facebook.imagepipeline.memory.BasePool.get(BasePool.java:257)
at com.facebook.imagepipeline.platform.ArtDecoder.decodeStaticImageFromStream(ArtDecoder.java:134)
at com.facebook.imagepipeline.platform.ArtDecoder.decodeJPEGFromEncodedImage(ArtDecoder.java:117)
at com.facebook.imagepipeline.decoder.DefaultImageDecoder.decodeJpeg(DefaultImageDecoder.java:184)
at com.facebook.imagepipeline.decoder.DefaultImageDecoder$1.decode(DefaultImageDecoder.java:59)
at com.facebook.imagepipeline.decoder.DefaultImageDecoder.decode(DefaultImageDecoder.java:122)
at com.facebook.imagepipeline.producers.DecodeProducer$ProgressiveDecoder.doDecode(DecodeProducer.java:245)
at com.facebook.imagepipeline.producers.DecodeProducer$ProgressiveDecoder.access$200(DecodeProducer.java:109)
at com.facebook.imagepipeline.producers.DecodeProducer$ProgressiveDecoder$1.run(DecodeProducer.java:142)
at com.facebook.imagepipeline.producers.JobScheduler.doJob(JobScheduler.java:204)
at com.facebook.imagepipeline.producers.JobScheduler.access$000(JobScheduler.java:24)
at com.facebook.imagepipeline.producers.JobScheduler$1.run(JobScheduler.java:75)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
at com.facebook.imagepipeline.core.PriorityThreadFactory$1.run(PriorityThreadFactory.java:42)
at java.lang.Thread.run(Thread.java:818)

@huitsing it is still present with RN - 0.50.4

it is still present