Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Documentation suggestion: AdaptiveThreshold #2

Closed
glopesdev opened this issue Oct 11, 2012 · 1 comment
Closed

Documentation suggestion: AdaptiveThreshold #2

glopesdev opened this issue Oct 11, 2012 · 1 comment
Labels
feature New planned feature

Comments

@glopesdev
Copy link
Member

Original report by Danbee Kim (Bitbucket: tauntaun, GitHub: tauntaun).

popup summary should mention that this function only works on greyscale images
@glopesdev
Copy link
Member Author

Fixed #2. Added input format information to AdaptiveThreshold description.

@glopesdev glopesdev added major feature New planned feature labels Mar 25, 2020
PathogenDavid added a commit to NgrDavid/bonsai that referenced this issue May 30, 2024
@PathogenDavid
Enabled building with the .NET SDK
a58706f 
The .NET SDK uses MSBuild Core rather than MSBuild Framework. One difference between them is that the legacy Windows-centric resource embedding was completely dropped from Core.
This updated resource embedding can be used with .NET Framework by using System.Resources.Extensions. (It only affects non-string resources like images, hence why only Bonsai.Design needs it.)

-------------------------------------------------

The new reference to System.Runtime.CompilerServices.Unsafe in Bonsai32 is to work around a quirk of how NuGet resolves the dependency graph.
There exists two paths to this package from the main Bonsai project (versions noted where important):
1) Bonsai -> Bonsai.Design -> System.Resources.Extensions -> System.Memory -> System.Runtime.CompilerServices.Unsafe/4.5.3
2) Bonsai -> System.Reflection.MetadataLoadContext->System.Collections.Immutable -> System.Runtime.CompilerServices.Unsafe/6.0.0

Path bonsai-rx#2 is private to Bonsai, while Path #1 is not.
Because Path bonsai-rx#2 is private, it isn't even part of the restore graph of Bonsai32.
As a result, Bonsai32 gets a transitive reference to S.R.CS.Unsafe 4.5.3 but Bonsai already has private reference to S.R.CS.Unsafe 6.0.0, resulting in a conflict.
This eventually results in a MSB3277 warning and can result in a completely broken build (if it weren't for the recent change the prevented Bonsai32 from clobbering Bonsai's output.)
PathogenDavid added a commit to NgrDavid/bonsai that referenced this issue Jun 18, 2024
@PathogenDavid
Enabled building with the .NET SDK
8fee5cb 
The .NET SDK uses MSBuild Core rather than MSBuild Framework. One difference between them is that the legacy Windows-centric resource embedding was completely dropped from Core.
This updated resource embedding can be used with .NET Framework by using System.Resources.Extensions. (It only affects non-string resources like images, hence why only Bonsai.Design needs it.)

-------------------------------------------------

The new reference to System.Runtime.CompilerServices.Unsafe in Bonsai32 is to work around a quirk of how NuGet resolves the dependency graph.
There exists two paths to this package from the main Bonsai project (versions noted where important):
1) Bonsai -> Bonsai.Design -> System.Resources.Extensions -> System.Memory -> System.Runtime.CompilerServices.Unsafe/4.5.3
2) Bonsai -> System.Reflection.MetadataLoadContext->System.Collections.Immutable -> System.Runtime.CompilerServices.Unsafe/6.0.0

Path bonsai-rx#2 is private to Bonsai, while Path #1 is not.
Because Path bonsai-rx#2 is private, it isn't even part of the restore graph of Bonsai32.
As a result, Bonsai32 gets a transitive reference to S.R.CS.Unsafe 4.5.3 but Bonsai already has private reference to S.R.CS.Unsafe 6.0.0, resulting in a conflict.
This eventually results in a MSB3277 warning and can result in a completely broken build (if it weren't for the recent change the prevented Bonsai32 from clobbering Bonsai's output.)
PathogenDavid added a commit to NgrDavid/bonsai that referenced this issue Jul 3, 2024
@PathogenDavid
Enabled building with the .NET SDK
2d3c7dd 
The .NET SDK uses MSBuild Core rather than MSBuild Framework. One difference between them is that the legacy Windows-centric resource embedding was completely dropped from Core.
This updated resource embedding can be used with .NET Framework by using System.Resources.Extensions. (It only affects non-string resources like images, hence why only Bonsai.Design needs it.)

-------------------------------------------------

The new reference to System.Runtime.CompilerServices.Unsafe in Bonsai32 is to work around a quirk of how NuGet resolves the dependency graph.
There exists two paths to this package from the main Bonsai project (versions noted where important):
1) Bonsai -> Bonsai.Design -> System.Resources.Extensions -> System.Memory -> System.Runtime.CompilerServices.Unsafe/4.5.3
2) Bonsai -> System.Reflection.MetadataLoadContext->System.Collections.Immutable -> System.Runtime.CompilerServices.Unsafe/6.0.0

Path bonsai-rx#2 is private to Bonsai, while Path #1 is not.
Because Path bonsai-rx#2 is private, it isn't even part of the restore graph of Bonsai32.
As a result, Bonsai32 gets a transitive reference to S.R.CS.Unsafe 4.5.3 but Bonsai already has private reference to S.R.CS.Unsafe 6.0.0, resulting in a conflict.
This eventually results in a MSB3277 warning and can result in a completely broken build (if it weren't for the recent change the prevented Bonsai32 from clobbering Bonsai's output.)
PathogenDavid added a commit to NgrDavid/bonsai that referenced this issue Jul 3, 2024
@PathogenDavid
Enabled building with the .NET SDK
f2815d4 
The .NET SDK uses MSBuild Core rather than MSBuild Framework. One difference between them is that the legacy Windows-centric resource embedding was completely dropped from Core.
This updated resource embedding can be used with .NET Framework by using System.Resources.Extensions. (It only affects non-string resources like images, hence why only Bonsai.Design needs it.)

-------------------------------------------------

The new reference to System.Runtime.CompilerServices.Unsafe in Bonsai32 is to work around a quirk of how NuGet resolves the dependency graph.
There exists two paths to this package from the main Bonsai project (versions noted where important):
1) Bonsai -> Bonsai.Design -> System.Resources.Extensions -> System.Memory -> System.Runtime.CompilerServices.Unsafe/4.5.3
2) Bonsai -> System.Reflection.MetadataLoadContext->System.Collections.Immutable -> System.Runtime.CompilerServices.Unsafe/6.0.0

Path bonsai-rx#2 is private to Bonsai, while Path #1 is not.
Because Path bonsai-rx#2 is private, it isn't even part of the restore graph of Bonsai32.
As a result, Bonsai32 gets a transitive reference to S.R.CS.Unsafe 4.5.3 but Bonsai already has private reference to S.R.CS.Unsafe 6.0.0, resulting in a conflict.
This eventually results in a MSB3277 warning and can result in a completely broken build (if it weren't for the recent change the prevented Bonsai32 from clobbering Bonsai's output.)
PathogenDavid added a commit to PathogenDavid/bonsai that referenced this issue Jul 4, 2024
@PathogenDavid
Enabled building with the .NET SDK
d0fdde9 
The .NET SDK uses MSBuild Core rather than MSBuild Framework. One difference between them is that the legacy Windows-centric resource embedding was completely dropped from Core.
This updated resource embedding can be used with .NET Framework by using System.Resources.Extensions. (It only affects non-string resources like images, hence why only Bonsai.Design needs it.)

-------------------------------------------------

The new reference to System.Runtime.CompilerServices.Unsafe in Bonsai32 is to work around a quirk of how NuGet resolves the dependency graph.
There exists two paths to this package from the main Bonsai project (versions noted where important):
1) Bonsai -> Bonsai.Design -> System.Resources.Extensions -> System.Memory -> System.Runtime.CompilerServices.Unsafe/4.5.3
2) Bonsai -> System.Reflection.MetadataLoadContext->System.Collections.Immutable -> System.Runtime.CompilerServices.Unsafe/6.0.0

Path bonsai-rx#2 is private to Bonsai, while Path bonsai-rx#1 is not.
Because Path bonsai-rx#2 is private, it isn't even part of the restore graph of Bonsai32.
As a result, Bonsai32 gets a transitive reference to S.R.CS.Unsafe 4.5.3 but Bonsai already has private reference to S.R.CS.Unsafe 6.0.0, resulting in a conflict.
This eventually results in a MSB3277 warning and can result in a completely broken build (if it weren't for the recent change the prevented Bonsai32 from clobbering Bonsai's output.)
PathogenDavid added a commit to NgrDavid/bonsai that referenced this issue Jul 4, 2024
@PathogenDavid
Enable building with the .NET SDK
2e43547 
The .NET SDK uses MSBuild Core rather than MSBuild Framework. One difference between them is that the legacy Windows-centric resource embedding was completely dropped from Core.
This updated resource embedding can be used with .NET Framework by using System.Resources.Extensions. (It only affects non-string resources like images, hence why only Bonsai.Design needs it.)

-------------------------------------------------

The new reference to System.Runtime.CompilerServices.Unsafe in Bonsai32 is to work around a quirk of how NuGet resolves the dependency graph.
There exists two paths to this package from the main Bonsai project (versions noted where important):
1) Bonsai -> Bonsai.Design -> System.Resources.Extensions -> System.Memory -> System.Runtime.CompilerServices.Unsafe/4.5.3
2) Bonsai -> System.Reflection.MetadataLoadContext->System.Collections.Immutable -> System.Runtime.CompilerServices.Unsafe/6.0.0

Path bonsai-rx#2 is private to Bonsai, while Path #1 is not.
Because Path bonsai-rx#2 is private, it isn't even part of the restore graph of Bonsai32.
As a result, Bonsai32 gets a transitive reference to S.R.CS.Unsafe 4.5.3 but Bonsai already has private reference to S.R.CS.Unsafe 6.0.0, resulting in a conflict.
This eventually results in a MSB3277 warning and can result in a completely broken build (if it weren't for the recent change the prevented Bonsai32 from clobbering Bonsai's output.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature New planned feature
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@glopesdev