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.

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

.Net Core Support #16

Closed
neurospeech opened this Issue Jun 27, 2016 · 30 comments

Comments

Projects
None yet
@ghost

ghost commented Jun 27, 2016

ImageMagick is already cross platform, will it be possible you to create NuGet package that is also cross platform?

@dlemstra

This comment has been minimized.

Show comment
Hide comment
@dlemstra

dlemstra Jun 27, 2016

Owner

There is .NET Core version of Magick.NET and it can be found here: https://www.nuget.org/packages?q=magick.net.core. It currently only works on Windows but I am planning to add support for other platforms in the future. I will keep this issue open to remind myself.

Owner

dlemstra commented Jun 27, 2016

There is .NET Core version of Magick.NET and it can be found here: https://www.nuget.org/packages?q=magick.net.core. It currently only works on Windows but I am planning to add support for other platforms in the future. I will keep this issue open to remind myself.

@hey-red

This comment has been minimized.

Show comment
Hide comment
@hey-red

hey-red Oct 26, 2016

@dlemstra It would be nice!

hey-red commented Oct 26, 2016

@dlemstra It would be nice!

@dlemstra

This comment has been minimized.

Show comment
Hide comment
@dlemstra

dlemstra Dec 30, 2016

Owner

This issue is marked as help wanted so it is probably also a good idea to explain what kind of help I need (Thanks @bleroy). Magick.NET uses the ImageMagick library through a DllImport. One of the projects creates a native dll that statically links the ImageMagick library files. These .lib files are created with a build script that takes the various projects (https://github.com/dlemstra/Magick.NET/blob/master/ImageMagick/Source/Checkout.sh) and uses a tool of the ImageMagick project to create a solution and build it. I would need a script that builds all the projects and creates library files for Linux/Mac that I can statically link. I am not really a Linux/Mac expert so I could use some help to get the libraries compiled and linked into the Magick.NET.Native project. Once that's done it should be really easy to change the rest of the project to correctly call the native library.

Owner

dlemstra commented Dec 30, 2016

This issue is marked as help wanted so it is probably also a good idea to explain what kind of help I need (Thanks @bleroy). Magick.NET uses the ImageMagick library through a DllImport. One of the projects creates a native dll that statically links the ImageMagick library files. These .lib files are created with a build script that takes the various projects (https://github.com/dlemstra/Magick.NET/blob/master/ImageMagick/Source/Checkout.sh) and uses a tool of the ImageMagick project to create a solution and build it. I would need a script that builds all the projects and creates library files for Linux/Mac that I can statically link. I am not really a Linux/Mac expert so I could use some help to get the libraries compiled and linked into the Magick.NET.Native project. Once that's done it should be really easy to change the rest of the project to correctly call the native library.

@MatthiasJost

This comment has been minimized.

Show comment
Hide comment
@MatthiasJost

MatthiasJost Jun 28, 2017

@dlemstra I was using "Magick.NET.Core-Q8": "7.0.3.902" (from project.json) in VS 14 (2015). I migrate our project to VS 15.2 (2017). I have a .NET Core Console project running under Windows only. However it says: "The owner has unlisted this package. This could mean that the package is deprecated or shouldn't be used anymore.".

I tried with another version but it says then:
Installing Magick.NET-Q8-AnyCPU.Web 7.0.5.900. Package Magick.NET-Q8-AnyCPU.Web 7.0.5.900 is not compatible with netcoreapp1.1 (.NETCoreApp,Version=v1.1). Package Magick.NET-Q8-AnyCPU.Web 7.0.5.900 supports: net40-client (.NETFramework,Version=v4.0,Profile=Client) One or more packages are incompatible with .NETCoreApp,Version=v1.1. Package restore failed. Rolling back package changes for 'imagePrototype'.

Could you help me? I want to integrate a .NET Core compatible version of Magick.NET in my new Visual Studio 2017 project (to be run on Windows only)?

MatthiasJost commented Jun 28, 2017

@dlemstra I was using "Magick.NET.Core-Q8": "7.0.3.902" (from project.json) in VS 14 (2015). I migrate our project to VS 15.2 (2017). I have a .NET Core Console project running under Windows only. However it says: "The owner has unlisted this package. This could mean that the package is deprecated or shouldn't be used anymore.".

I tried with another version but it says then:
Installing Magick.NET-Q8-AnyCPU.Web 7.0.5.900. Package Magick.NET-Q8-AnyCPU.Web 7.0.5.900 is not compatible with netcoreapp1.1 (.NETCoreApp,Version=v1.1). Package Magick.NET-Q8-AnyCPU.Web 7.0.5.900 supports: net40-client (.NETFramework,Version=v4.0,Profile=Client) One or more packages are incompatible with .NETCoreApp,Version=v1.1. Package restore failed. Rolling back package changes for 'imagePrototype'.

Could you help me? I want to integrate a .NET Core compatible version of Magick.NET in my new Visual Studio 2017 project (to be run on Windows only)?

@dlemstra

This comment has been minimized.

Show comment
Hide comment
@dlemstra

dlemstra Jun 28, 2017

Owner

You will need to use the latest version of the package Magick.NET-Q8-AnyCPU. The Core packages have been moved into the normal packages. The .Web package is a separate package that adds extra 'Web' functionality that you don't need.

Owner

dlemstra commented Jun 28, 2017

You will need to use the latest version of the package Magick.NET-Q8-AnyCPU. The Core packages have been moved into the normal packages. The .Web package is a separate package that adds extra 'Web' functionality that you don't need.

@MatthiasJost

This comment has been minimized.

Show comment
Hide comment
@MatthiasJost

MatthiasJost Jun 28, 2017

Thanks. It works.

MatthiasJost commented Jun 28, 2017

Thanks. It works.

@markbeaton

This comment has been minimized.

Show comment
Hide comment
@markbeaton

markbeaton Jul 16, 2017

I might be able to help out here - we develop on the Mac, deploy to Ubuntu - historically Mono, but we're increasingly embracing .NET Core. I've also got some experience building native libraries for multiple platforms (Win, Mac, Linux, iOS, Android).

I'll have a look this week & see how far I get.

markbeaton commented Jul 16, 2017

I might be able to help out here - we develop on the Mac, deploy to Ubuntu - historically Mono, but we're increasingly embracing .NET Core. I've also got some experience building native libraries for multiple platforms (Win, Mac, Linux, iOS, Android).

I'll have a look this week & see how far I get.

@dlemstra dlemstra referenced this issue Jul 17, 2017

Closed

Linux support? #74

@dlemstra

This comment has been minimized.

Show comment
Hide comment
@dlemstra

dlemstra Jul 24, 2017

Owner

@markbeaton I created a proof of concept with .NET Core this weekend. I had help from @stephanbruny who got it working with Mono. Will integrate the POC this week and this means that the new release will include support for Linux on Ubuntu. It will require building ImageMagick from source but I will put up some instruction on what you need to do.

Owner

dlemstra commented Jul 24, 2017

@markbeaton I created a proof of concept with .NET Core this weekend. I had help from @stephanbruny who got it working with Mono. Will integrate the POC this week and this means that the new release will include support for Linux on Ubuntu. It will require building ImageMagick from source but I will put up some instruction on what you need to do.

dlemstra added a commit that referenced this issue Jul 26, 2017

@markbeaton

This comment has been minimized.

Show comment
Hide comment
@markbeaton

markbeaton Aug 3, 2017

Apologies all - I'm not going to get a chance to help out here for some time, but it looks like you're making progress anyway.

markbeaton commented Aug 3, 2017

Apologies all - I'm not going to get a chance to help out here for some time, but it looks like you're making progress anyway.

@dlemstra

This comment has been minimized.

Show comment
Hide comment
@dlemstra

dlemstra Aug 6, 2017

Owner

I just published a new release 7.0.6.600 that has support for running Magick.NET on Linux. Extra instructions can be found here: https://github.com/dlemstra/Magick.NET/blob/master/Documentation/CrossPlatform.md

Owner

dlemstra commented Aug 6, 2017

I just published a new release 7.0.6.600 that has support for running Magick.NET on Linux. Extra instructions can be found here: https://github.com/dlemstra/Magick.NET/blob/master/Documentation/CrossPlatform.md

@hey-red

This comment has been minimized.

Show comment
Hide comment
@hey-red

hey-red Aug 6, 2017

@dlemstra

The Magick.NET.Native library is not automatically copied to the output directory when the NuGet reference is added to the project.

That can be solved in this way

hey-red commented Aug 6, 2017

@dlemstra

The Magick.NET.Native library is not automatically copied to the output directory when the NuGet reference is added to the project.

That can be solved in this way

@dlemstra

This comment has been minimized.

Show comment
Hide comment
@dlemstra

dlemstra Aug 7, 2017

Owner

Thanks for the tip @hey-red. I updated the .targets file.

Owner

dlemstra commented Aug 7, 2017

Thanks for the tip @hey-red. I updated the .targets file.

@derwasp

This comment has been minimized.

Show comment
Hide comment
@derwasp

derwasp Sep 21, 2017

@dlemstra hey. I've bodged in a build script here to build the binaries on Amazon Linux: https://github.com/albumprinter/Albelli.Magick.Builder
I need them to work in a Lambda function. I thought you would like to look at it yourself.

It's WIP, so you shouldn't expect it to look pretty just yet.

I see a problem with the way you distribute the linux bins: not every linux is the same. And since you've compiled yours against libjpeg8, it's a bit of a hassle to make it work on the centos/fedora based distros.
My advise would be to keep the original nuget packages without the linux binaries and distribute those separately. You can have it named like e.g. Magick.NET-Q8-x64.Natives.AmazonLinux.

Another issue wich makes it hard to automate your build is the fact that you are using a vcxproj for the linux build as well. I made a CMakeLists.txt which works fine on Linux. I guess this should be somewhat compatible/convertable to the visual studio format, but I didn't check on that.

I will try to make my build work and produce a nuget package (currently it's just a bunch of .so files). You are free to borrow things from that repo if you want to. But since you are using appveyor as CI I don't think it will work right away. I am tryin to use travis for it.

derwasp commented Sep 21, 2017

@dlemstra hey. I've bodged in a build script here to build the binaries on Amazon Linux: https://github.com/albumprinter/Albelli.Magick.Builder
I need them to work in a Lambda function. I thought you would like to look at it yourself.

It's WIP, so you shouldn't expect it to look pretty just yet.

I see a problem with the way you distribute the linux bins: not every linux is the same. And since you've compiled yours against libjpeg8, it's a bit of a hassle to make it work on the centos/fedora based distros.
My advise would be to keep the original nuget packages without the linux binaries and distribute those separately. You can have it named like e.g. Magick.NET-Q8-x64.Natives.AmazonLinux.

Another issue wich makes it hard to automate your build is the fact that you are using a vcxproj for the linux build as well. I made a CMakeLists.txt which works fine on Linux. I guess this should be somewhat compatible/convertable to the visual studio format, but I didn't check on that.

I will try to make my build work and produce a nuget package (currently it's just a bunch of .so files). You are free to borrow things from that repo if you want to. But since you are using appveyor as CI I don't think it will work right away. I am tryin to use travis for it.

@dlemstra

This comment has been minimized.

Show comment
Hide comment
@dlemstra

dlemstra Sep 21, 2017

Owner

I am linking against libjpeg-turbo and I wonder why that is an issue on centos/fedora. But I should probably add that to: https://github.com/dlemstra/Magick.NET/blob/master/Documentation/CrossPlatform.md. The project has a .vcxproj file because I am using remote compilation. You can find some information about that in the CrossPlatform documentation. The build is automated with Tools\BuildCrossPlatform.cmd.

Owner

dlemstra commented Sep 21, 2017

I am linking against libjpeg-turbo and I wonder why that is an issue on centos/fedora. But I should probably add that to: https://github.com/dlemstra/Magick.NET/blob/master/Documentation/CrossPlatform.md. The project has a .vcxproj file because I am using remote compilation. You can find some information about that in the CrossPlatform documentation. The build is automated with Tools\BuildCrossPlatform.cmd.

@derwasp

This comment has been minimized.

Show comment
Hide comment
@derwasp

derwasp Sep 21, 2017

I wonder why that is an issue on centos/fedora

Unable to find image 'centos:latest' locally
latest: Pulling from library/centos
d9aaf4d82f24: Pull complete
Digest: sha256:eba772bac22c86d7d6e72421b4700c3f894ab6e35475a34014ff8de74c10872e
Status: Downloaded newer image for centos:latest
[root@878f6f639d2a /]# yum install -y libjpeg-turbo
Loaded plugins: fastestmirror, ovl
base                                                                                             | 3.6 kB  00:00:00
extras                                                                                           | 3.4 kB  00:00:00
updates                                                                                          | 3.4 kB  00:00:00
(1/4): base/7/x86_64/group_gz                                                                    | 156 kB  00:00:00
(2/4): extras/7/x86_64/primary_db                                                                | 102 kB  00:00:00
(3/4): updates/7/x86_64/primary_db                                                               | 2.8 MB  00:00:01
(4/4): base/7/x86_64/primary_db                                                                  | 5.7 MB  00:00:04
Determining fastest mirrors
 * base: mirrors.noction.com
 * extras: mirrors.noction.com
 * updates: mirror.oxilion.nl
Resolving Dependencies
--> Running transaction check
---> Package libjpeg-turbo.x86_64 0:1.2.90-5.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

========================================================================================================================
 Package                         Arch                     Version                          Repository              Size
========================================================================================================================
Installing:
 libjpeg-turbo                   x86_64                   1.2.90-5.el7                     base                   134 k

Transaction Summary
========================================================================================================================
Install  1 Package

Total download size: 134 k
Installed size: 342 k
Downloading packages:
warning: /var/cache/yum/x86_64/7/base/packages/libjpeg-turbo-1.2.90-5.el7.x86_64.rpm: Header V3 RSA/SHA256 Signature, ke
y ID f4a80eb5: NOKEY
Public key for libjpeg-turbo-1.2.90-5.el7.x86_64.rpm is not installed
libjpeg-turbo-1.2.90-5.el7.x86_64.rpm                                                            | 134 kB  00:00:00
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
Importing GPG key 0xF4A80EB5:
 Userid     : "CentOS-7 Key (CentOS 7 Official Signing Key) <security@centos.org>"
 Fingerprint: 6341 ab27 53d7 8a78 a7c2 7bb1 24c6 a8a7 f4a8 0eb5
 Package    : centos-release-7-4.1708.el7.centos.x86_64 (@CentOS)
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : libjpeg-turbo-1.2.90-5.el7.x86_64                                                                    1/1
  Verifying  : libjpeg-turbo-1.2.90-5.el7.x86_64                                                                    1/1

Installed:
  libjpeg-turbo.x86_64 0:1.2.90-5.el7

Complete!
[root@878f6f639d2a /]# ls /lib64 | grep jpeg
libjpeg.so.62
libjpeg.so.62.1.0
[root@878f6f639d2a /]# ls /usr/lib64 | grep jpeg
libjpeg.so.62
libjpeg.so.62.1.0
[root@878f6f639d2a /]#

Your lib is compiled against libjpeg.so.8. As you can see from the output above, a slightly different binary is available on Centos (and amazonlinux, which is centos based).

The project has a .vcxproj file because I am using remote compilation.

And it requires a Visual Studio instance to be opened, right? Or I am missing things and I can run a script on a CI server which will produce a binary?

derwasp commented Sep 21, 2017

I wonder why that is an issue on centos/fedora

Unable to find image 'centos:latest' locally
latest: Pulling from library/centos
d9aaf4d82f24: Pull complete
Digest: sha256:eba772bac22c86d7d6e72421b4700c3f894ab6e35475a34014ff8de74c10872e
Status: Downloaded newer image for centos:latest
[root@878f6f639d2a /]# yum install -y libjpeg-turbo
Loaded plugins: fastestmirror, ovl
base                                                                                             | 3.6 kB  00:00:00
extras                                                                                           | 3.4 kB  00:00:00
updates                                                                                          | 3.4 kB  00:00:00
(1/4): base/7/x86_64/group_gz                                                                    | 156 kB  00:00:00
(2/4): extras/7/x86_64/primary_db                                                                | 102 kB  00:00:00
(3/4): updates/7/x86_64/primary_db                                                               | 2.8 MB  00:00:01
(4/4): base/7/x86_64/primary_db                                                                  | 5.7 MB  00:00:04
Determining fastest mirrors
 * base: mirrors.noction.com
 * extras: mirrors.noction.com
 * updates: mirror.oxilion.nl
Resolving Dependencies
--> Running transaction check
---> Package libjpeg-turbo.x86_64 0:1.2.90-5.el7 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

========================================================================================================================
 Package                         Arch                     Version                          Repository              Size
========================================================================================================================
Installing:
 libjpeg-turbo                   x86_64                   1.2.90-5.el7                     base                   134 k

Transaction Summary
========================================================================================================================
Install  1 Package

Total download size: 134 k
Installed size: 342 k
Downloading packages:
warning: /var/cache/yum/x86_64/7/base/packages/libjpeg-turbo-1.2.90-5.el7.x86_64.rpm: Header V3 RSA/SHA256 Signature, ke
y ID f4a80eb5: NOKEY
Public key for libjpeg-turbo-1.2.90-5.el7.x86_64.rpm is not installed
libjpeg-turbo-1.2.90-5.el7.x86_64.rpm                                                            | 134 kB  00:00:00
Retrieving key from file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
Importing GPG key 0xF4A80EB5:
 Userid     : "CentOS-7 Key (CentOS 7 Official Signing Key) <security@centos.org>"
 Fingerprint: 6341 ab27 53d7 8a78 a7c2 7bb1 24c6 a8a7 f4a8 0eb5
 Package    : centos-release-7-4.1708.el7.centos.x86_64 (@CentOS)
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : libjpeg-turbo-1.2.90-5.el7.x86_64                                                                    1/1
  Verifying  : libjpeg-turbo-1.2.90-5.el7.x86_64                                                                    1/1

Installed:
  libjpeg-turbo.x86_64 0:1.2.90-5.el7

Complete!
[root@878f6f639d2a /]# ls /lib64 | grep jpeg
libjpeg.so.62
libjpeg.so.62.1.0
[root@878f6f639d2a /]# ls /usr/lib64 | grep jpeg
libjpeg.so.62
libjpeg.so.62.1.0
[root@878f6f639d2a /]#

Your lib is compiled against libjpeg.so.8. As you can see from the output above, a slightly different binary is available on Centos (and amazonlinux, which is centos based).

The project has a .vcxproj file because I am using remote compilation.

And it requires a Visual Studio instance to be opened, right? Or I am missing things and I can run a script on a CI server which will produce a binary?

@dlemstra

This comment has been minimized.

Show comment
Hide comment
@dlemstra

dlemstra Sep 22, 2017

Owner

Would your issue be fixed if you would rebuild libjpeg-turbo from source also? I think you don't need to rebuild the CrossPlatform project when you build libjpeg-turbo from source.

The remote compilation does work without having Visual Studio open but you will need to register the remove build agents inside Visual Studio. Not sure how you could do this from the command line.

Owner

dlemstra commented Sep 22, 2017

Would your issue be fixed if you would rebuild libjpeg-turbo from source also? I think you don't need to rebuild the CrossPlatform project when you build libjpeg-turbo from source.

The remote compilation does work without having Visual Studio open but you will need to register the remove build agents inside Visual Studio. Not sure how you could do this from the command line.

@derwasp

This comment has been minimized.

Show comment
Hide comment
@derwasp

derwasp Sep 22, 2017

That is what I called "hassle" and that is something I'd rather avoid. It's way easier to rebuild the wrapper in a way I did. Is there a particular reason why you don't want to distribute the bins separately?
This is a nice example of such a package, which makes use of the solution I described: Avalonia.Skia.Linux.Natives

Got it. But it means we can't use that script to build this thing in Travis/AnotherCiOfChoice, right? Since you don't really open the VS there. And in most cases you don't even have it there. With CMakeLists.txt my build works on Travis already. I just don't have the nuget packing logic just yet.

In any case I will proceed with my repo and if you would like to have it in yours, you are welcome to take bits and pieces you like. I started this conversation because I read that you were asking for help with the Linux part. I know it's not a static build we all would like to have ;) But it's a solution which works for me and can work for others.

derwasp commented Sep 22, 2017

That is what I called "hassle" and that is something I'd rather avoid. It's way easier to rebuild the wrapper in a way I did. Is there a particular reason why you don't want to distribute the bins separately?
This is a nice example of such a package, which makes use of the solution I described: Avalonia.Skia.Linux.Natives

Got it. But it means we can't use that script to build this thing in Travis/AnotherCiOfChoice, right? Since you don't really open the VS there. And in most cases you don't even have it there. With CMakeLists.txt my build works on Travis already. I just don't have the nuget packing logic just yet.

In any case I will proceed with my repo and if you would like to have it in yours, you are welcome to take bits and pieces you like. I started this conversation because I read that you were asking for help with the Linux part. I know it's not a static build we all would like to have ;) But it's a solution which works for me and can work for others.

@dlemstra

This comment has been minimized.

Show comment
Hide comment
@dlemstra

dlemstra Sep 22, 2017

Owner

I would like to avoid a separate package because it is really nice that I can now include the .so file in the package easily. The binary is stored inside the folder: runtimes\linux-x64\native but I could decide the have a separate build for centos-x64 (https://docs.microsoft.com/en-us/dotnet/core/rid-catalog) and create a folder runtimes\centos-x64\native that contains a .so file that is linked with a different version of libjpeg. But I really wonder if that would be a good solution. You will need to build ImageMagick from source because I always use the latest version to link against. And it should not be that difficult to also build libjpeg-turbo from source.

Maybe we could create some Docker files that other people could use as their base image that has ImageMagick and libjeg-turbo already installed. I already have a Docker file for the image that I use to remotely compile the source on an Ubuntu machine: https://github.com/dlemstra/Magick.NET/blob/master/Source/Magick.NET.CrossPlatform/ubuntu.16.04/Dockerfile. I could split that file into two images one that builds ImageMagick and has it installed and one that adds the ssh stuff so I can use it for remote compilation. What would you think of that solution?

Owner

dlemstra commented Sep 22, 2017

I would like to avoid a separate package because it is really nice that I can now include the .so file in the package easily. The binary is stored inside the folder: runtimes\linux-x64\native but I could decide the have a separate build for centos-x64 (https://docs.microsoft.com/en-us/dotnet/core/rid-catalog) and create a folder runtimes\centos-x64\native that contains a .so file that is linked with a different version of libjpeg. But I really wonder if that would be a good solution. You will need to build ImageMagick from source because I always use the latest version to link against. And it should not be that difficult to also build libjpeg-turbo from source.

Maybe we could create some Docker files that other people could use as their base image that has ImageMagick and libjeg-turbo already installed. I already have a Docker file for the image that I use to remotely compile the source on an Ubuntu machine: https://github.com/dlemstra/Magick.NET/blob/master/Source/Magick.NET.CrossPlatform/ubuntu.16.04/Dockerfile. I could split that file into two images one that builds ImageMagick and has it installed and one that adds the ssh stuff so I can use it for remote compilation. What would you think of that solution?

@derwasp

This comment has been minimized.

Show comment
Hide comment
@derwasp

derwasp Oct 5, 2017

@dlemstra the solution with compiling libjpeg, when it's already available in the system, is not something I am aiming for.
And I thought that the idea is that you compile Magick.NET against a locked version and not just any. Therefore I don't understand why would I want to have a docker image with a pre-installed Magick.

I have some more news for people who might be interested in the package I am working on. Currently I have a version which is statically compiled with libjpeg-turbo, zlib, lcms2, libwebp, libpng. It's still in PoC state, that's why the buildscripts are.. weird.
But the good news is that it is usable. And the build result is just one .so file.
I am not publishing it to nuget, because it's far from perfect, but it is good for the tests I am doing.

A version to test with is available from myget (you can see the link in the repo's readme) as a complete nuget package.

It's possible to use the scripts locally to build the package yourself, in case you need Q16 or HDRI enabled.

The only requirement is that you have docker installed.

The readme is available in the repo.

derwasp commented Oct 5, 2017

@dlemstra the solution with compiling libjpeg, when it's already available in the system, is not something I am aiming for.
And I thought that the idea is that you compile Magick.NET against a locked version and not just any. Therefore I don't understand why would I want to have a docker image with a pre-installed Magick.

I have some more news for people who might be interested in the package I am working on. Currently I have a version which is statically compiled with libjpeg-turbo, zlib, lcms2, libwebp, libpng. It's still in PoC state, that's why the buildscripts are.. weird.
But the good news is that it is usable. And the build result is just one .so file.
I am not publishing it to nuget, because it's far from perfect, but it is good for the tests I am doing.

A version to test with is available from myget (you can see the link in the repo's readme) as a complete nuget package.

It's possible to use the scripts locally to build the package yourself, in case you need Q16 or HDRI enabled.

The only requirement is that you have docker installed.

The readme is available in the repo.

@laurentKTR

This comment has been minimized.

Show comment
Hide comment
@laurentKTR

laurentKTR Feb 21, 2018

Hi
i'm currently trying to build a dockerfile to have dotnet core 2.0 and imagemagick

I have 2 options
1st:
i'm starting from ubutntu, adding libjpeg-turbo8-dev
i'm then download delegates °+ Imagemagick source + compiling
then i'm adding dotnet-sdk-2.0.2
finally i'm running
WORKDIR /usr/local/lib
RUN cd ~/.nuget/packages/magick.net-q16-anycpu/7.4.1/runtimes/linux-x64/native
&& ldd Magick.NET-Q16-x64.Native.dll.so
the result of this command is
linux-vdso.so.1 => (0x00007ffc186de000)
libMagickCore-7.Q16.so.5 => /usr/local/lib/libMagickCore-7.Q16.so.5 (0x00007f97348a3000)
libMagickWand-7.Q16.so.5 => /usr/local/lib/libMagickWand-7.Q16.so.5 (0x00007f97345a3000)
libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007f973433b000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9733fe5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9733c05000)
libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x00007f97339d2000)
libz.so.1 => /usr/local/lib/libz.so.1 (0x00007f97337b4000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f9733585000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f973336e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f973314f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f97350bc000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9732f4b000)

=> i can call my core console and everything works well
The downside of this option is that the image size is 2 go

2nd:
i'm starting from microsoft/dotnet:sdk, adding libjpeg62-turbo-dev
=> libjpeg-turbo8-dev is unkown in the repo of this source
i'm then download delegates °+ Imagemagick source + compiling
finally i'm running
WORKDIR /usr/local/lib
RUN cd ~/.nuget/packages/magick.net-q16-anycpu/7.4.1/runtimes/linux-x64/native
&& ldd Magick.NET-Q16-x64.Native.dll.so
the result of this command is
linux-vdso.so.1 (0x00007ffdde516000)
libMagickCore-7.Q16.so.5 => /usr/local/lib/libMagickCore-7.Q16.so.5 (0x00007ff9ca640000)
libMagickWand-7.Q16.so.5 => /usr/local/lib/libMagickWand-7.Q16.so.5 (0x00007ff9ca337000)
libjpeg.so.8 => not found
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff9ca033000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff9c9c94000)
libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62 (0x00007ff9c9a29000)
libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x00007ff9c97f7000)
libz.so.1 => /usr/local/lib/libz.so.1 (0x00007ff9c95db000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007ff9c93ae000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff9c9197000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff9c8f7a000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff9cae50000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff9c8d76000)

this time the call to my core console fails due to this missing libjpeg.so.8 but i have libjpeg.so.62
can you help on this point ?
I'm a bit lost in this libjpeg <-> libjpgturbo

the aim of this solution N° is to reduce the size of the image

laurentKTR commented Feb 21, 2018

Hi
i'm currently trying to build a dockerfile to have dotnet core 2.0 and imagemagick

I have 2 options
1st:
i'm starting from ubutntu, adding libjpeg-turbo8-dev
i'm then download delegates °+ Imagemagick source + compiling
then i'm adding dotnet-sdk-2.0.2
finally i'm running
WORKDIR /usr/local/lib
RUN cd ~/.nuget/packages/magick.net-q16-anycpu/7.4.1/runtimes/linux-x64/native
&& ldd Magick.NET-Q16-x64.Native.dll.so
the result of this command is
linux-vdso.so.1 => (0x00007ffc186de000)
libMagickCore-7.Q16.so.5 => /usr/local/lib/libMagickCore-7.Q16.so.5 (0x00007f97348a3000)
libMagickWand-7.Q16.so.5 => /usr/local/lib/libMagickWand-7.Q16.so.5 (0x00007f97345a3000)
libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007f973433b000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9733fe5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9733c05000)
libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x00007f97339d2000)
libz.so.1 => /usr/local/lib/libz.so.1 (0x00007f97337b4000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f9733585000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f973336e000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f973314f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f97350bc000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9732f4b000)

=> i can call my core console and everything works well
The downside of this option is that the image size is 2 go

2nd:
i'm starting from microsoft/dotnet:sdk, adding libjpeg62-turbo-dev
=> libjpeg-turbo8-dev is unkown in the repo of this source
i'm then download delegates °+ Imagemagick source + compiling
finally i'm running
WORKDIR /usr/local/lib
RUN cd ~/.nuget/packages/magick.net-q16-anycpu/7.4.1/runtimes/linux-x64/native
&& ldd Magick.NET-Q16-x64.Native.dll.so
the result of this command is
linux-vdso.so.1 (0x00007ffdde516000)
libMagickCore-7.Q16.so.5 => /usr/local/lib/libMagickCore-7.Q16.so.5 (0x00007ff9ca640000)
libMagickWand-7.Q16.so.5 => /usr/local/lib/libMagickWand-7.Q16.so.5 (0x00007ff9ca337000)
libjpeg.so.8 => not found
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff9ca033000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff9c9c94000)
libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62 (0x00007ff9c9a29000)
libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x00007ff9c97f7000)
libz.so.1 => /usr/local/lib/libz.so.1 (0x00007ff9c95db000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007ff9c93ae000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff9c9197000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff9c8f7a000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff9cae50000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff9c8d76000)

this time the call to my core console fails due to this missing libjpeg.so.8 but i have libjpeg.so.62
can you help on this point ?
I'm a bit lost in this libjpeg <-> libjpgturbo

the aim of this solution N° is to reduce the size of the image

@dlemstra

This comment has been minimized.

Show comment
Hide comment
@dlemstra

dlemstra Feb 21, 2018

Owner

@laurentKTR I am trying to statically link ImageMagick with the help of @superstator. We have made some progress and the library works on the following base images: https://github.com/dlemstra/Magick.NET/blob/master/Source/Magick.NET.CrossPlatform/Linux.Verify.Dockerfile without doing any extra installation or building. Will work on seeing how well his works with running the unit test on a Linux machine. Will try to publish a new release once I have this working properly.

Owner

dlemstra commented Feb 21, 2018

@laurentKTR I am trying to statically link ImageMagick with the help of @superstator. We have made some progress and the library works on the following base images: https://github.com/dlemstra/Magick.NET/blob/master/Source/Magick.NET.CrossPlatform/Linux.Verify.Dockerfile without doing any extra installation or building. Will work on seeing how well his works with running the unit test on a Linux machine. Will try to publish a new release once I have this working properly.

@dlemstra

This comment has been minimized.

Show comment
Hide comment
@dlemstra

dlemstra Feb 25, 2018

Owner

@laurentKTR Can you give the latest release a try?

Owner

dlemstra commented Feb 25, 2018

@laurentKTR Can you give the latest release a try?

@laurentKTR

This comment has been minimized.

Show comment
Hide comment
@laurentKTR

laurentKTR Feb 27, 2018

works well, my dockerfile is now very simple,
i don't have any delegate/imagemagick to compile and link before beeing able to use magick.net
and the size of the image is 260 mo
thanks !

laurentKTR commented Feb 27, 2018

works well, my dockerfile is now very simple,
i don't have any delegate/imagemagick to compile and link before beeing able to use magick.net
and the size of the image is 260 mo
thanks !

@heyandy1st

This comment has been minimized.

Show comment
Hide comment
@heyandy1st

heyandy1st Mar 2, 2018

Has there been any more work on getting Magick.Net running on Raspberry Pi? I have tried what little instructions I have found and nothing seems to work.
I am using Visual Studio 2017 on Mac OS X to build my application. I then do a dot-net publish -r linux-arm and move the files from the publish directory to my Pi.
However when I attempt to hit Magick.Net within the app, I get thrown a System.DllNotFound looking for Magick.NET-Q8-x86.Native.dll.
Of course the -x86 dll isn’t there the -AnyCPU dll is there.
Looking at the .deps.json file it appears all targets clearly show the -AnyCPU dll’s.
So I seem to be missing something here.
Any follow-up on this working on Pi?

heyandy1st commented Mar 2, 2018

Has there been any more work on getting Magick.Net running on Raspberry Pi? I have tried what little instructions I have found and nothing seems to work.
I am using Visual Studio 2017 on Mac OS X to build my application. I then do a dot-net publish -r linux-arm and move the files from the publish directory to my Pi.
However when I attempt to hit Magick.Net within the app, I get thrown a System.DllNotFound looking for Magick.NET-Q8-x86.Native.dll.
Of course the -x86 dll isn’t there the -AnyCPU dll is there.
Looking at the .deps.json file it appears all targets clearly show the -AnyCPU dll’s.
So I seem to be missing something here.
Any follow-up on this working on Pi?

@meysamSamanpour

This comment has been minimized.

Show comment
Hide comment
@meysamSamanpour

meysamSamanpour May 1, 2018

Contributor

Hi I started to work in dotnet standard 2 there is nothing now in this version of dotnet standard to support the class of ColorTranslator. I just need the mothod of FromHtml() in that class. Is there anything in Magick.Net so I can convert the Hex text color to RGB ?

Contributor

meysamSamanpour commented May 1, 2018

Hi I started to work in dotnet standard 2 there is nothing now in this version of dotnet standard to support the class of ColorTranslator. I just need the mothod of FromHtml() in that class. Is there anything in Magick.Net so I can convert the Hex text color to RGB ?

@dlemstra

This comment has been minimized.

Show comment
Hide comment
@dlemstra

dlemstra May 1, 2018

Owner

@meysamSamanpour Could you start a new issue for this and explain in detail what you are talking about?

Owner

dlemstra commented May 1, 2018

@meysamSamanpour Could you start a new issue for this and explain in detail what you are talking about?

@SepiaGroup

This comment has been minimized.

Show comment
Hide comment
@SepiaGroup

SepiaGroup May 18, 2018

@dlemstra I am slightly confused on how to build/deploy Magick.net using .net core running on linux and referencing the correct dll's.

i have a .net core web app that i develop on windows and then i build and deploy it to a Docker container running Ubuntu using Jenkins.

I have Magic.net working correctly on windows and now want to build and deploy it, but this is where i am confused.

  1. do i need to build Magick.net on Ubuntu and then reference these dll's in my web app? And since I am using Jenkins can I do all this via a command line.

  2. or can i use the dll's you have in the release folder ( https://github.com/dlemstra/Magick.NET/releases ) and just reference net40\Magick.NET\Magick.NET-Q16-x64.Native.dll when i do my build via Jenkins on my linux box? It is not clear to me if this dll has the linux version of imagemagick statically linked or the windows version.

SepiaGroup commented May 18, 2018

@dlemstra I am slightly confused on how to build/deploy Magick.net using .net core running on linux and referencing the correct dll's.

i have a .net core web app that i develop on windows and then i build and deploy it to a Docker container running Ubuntu using Jenkins.

I have Magic.net working correctly on windows and now want to build and deploy it, but this is where i am confused.

  1. do i need to build Magick.net on Ubuntu and then reference these dll's in my web app? And since I am using Jenkins can I do all this via a command line.

  2. or can i use the dll's you have in the release folder ( https://github.com/dlemstra/Magick.NET/releases ) and just reference net40\Magick.NET\Magick.NET-Q16-x64.Native.dll when i do my build via Jenkins on my linux box? It is not clear to me if this dll has the linux version of imagemagick statically linked or the windows version.

@dlemstra

This comment has been minimized.

Show comment
Hide comment
@dlemstra

dlemstra May 18, 2018

Owner

@meysamSamanpour and @SepiaGroup Could you please open a new issue for your questions. Will close this issue because we have support for .NET Core now.

Owner

dlemstra commented May 18, 2018

@meysamSamanpour and @SepiaGroup Could you please open a new issue for your questions. Will close this issue because we have support for .NET Core now.

@dlemstra dlemstra closed this May 18, 2018

@lmontoute

This comment has been minimized.

Show comment
Hide comment
@lmontoute

lmontoute May 18, 2018

@dlemstra are there any issues or plans for macOS support (or did this get implemented)? I've been tracking this issue as a proxy for that, noticed a lot of progress on native Linux binaries but wasn't sure if that also extended to macOS.

lmontoute commented May 18, 2018

@dlemstra are there any issues or plans for macOS support (or did this get implemented)? I've been tracking this issue as a proxy for that, noticed a lot of progress on native Linux binaries but wasn't sure if that also extended to macOS.

@dlemstra

This comment has been minimized.

Show comment
Hide comment
@dlemstra

dlemstra May 18, 2018

Owner

@lmontoute I opened a new issue for that here: #216. This issue was being hijacked for other questions.

Owner

dlemstra commented May 18, 2018

@lmontoute I opened a new issue for that here: #216. This issue was being hijacked for other questions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment