[ANN] picfit, an image resizing server

[floren...@gmail.com]

Hi,

My first real Go project https://github.com/thoas/picfit

Features:

• Supports multiple storages (file system, s3) using a unified interface (https://github.com/thoas/gostorages)
  
• Supports multiple k/v stores (in-memory cache, redis) also with a unified interface (https://github.com/thoas/gokvstores)
• Security
• Sharding on disk
• Error reporting
• etc.

If you want to help me in the roadmap, don't hesitate.

Feedback welcome :)

[Nigel Tao]

"Go image doesn't currently support CMYK color mode" should be fixed
on Go tip (what will eventually be released as Go 1.5).

[Florent Messa]

Excellent news!

I'm planned to support imagemagick.

[Justin Israel]

I was about to ask if you were planning to support different image packages.
I have a similar preview image server that I wrote for internal use which has very close functionality. I wonder if you have plans to do any of the things similar to what mine has...

* ability to define different "resolvers" that can interpret the image "key" in the request, into the actual absolute path. Such as matching a certain type of URN and making an external call to resolve the path, in addition to just recognising the actual file path directly.
* Mine supports color transformations directly through OpenColorIO bindings,  outside of the ImageMagick transformations , but I wonder if there was a generic way to supply a pluggable backend. Maybe people want to do them with ImageMagick instead of OpenColorIO.
* In-memory LRU for the image blobs, as another alternative to storage

Would be cool if an open source version provided the equivalent and I could use it.

Justin

On Fri, 13 Mar 2015 9:01 PM Florent Messa <floren...@gmail.com> wrote:

Excellent news!

I'm planned to support imagemagick.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Florent Messa]

On Friday, March 13, 2015 at 12:02:20 PM UTC+1, Justin Israel wrote:

I was about to ask if you were planning to support different image packages.
I have a similar preview image server that I wrote for internal use which has very close functionality. I wonder if you have plans to do any of the things similar to what mine has...

* ability to define different "resolvers" that can interpret the image "key" in the request, into the actual absolute path. Such as matching a certain type of URN and making an external call to resolve the path, in addition to just recognising the actual file path directly.

The purpose of this will be url rewriting if I'm understanding?

If no, could you provide me some examples :)

 

* Mine supports color transformations directly through OpenColorIO bindings,  outside of the ImageMagick transformations , but I wonder if there was a generic way to supply a pluggable backend. Maybe people want to do them with ImageMagick instead of OpenColorIO.

It's not planned at the moment because I don't need color transformations, if you have some code examples to see a concret use case it will be great.

I will provide a generic abstraction on top of Go image lib and ImageMagick like sorl-thumbnail does, see https://github.com/mariocesar/sorl-thumbnail/tree/master/sorl/thumbnail/engines to switch the engine in the config file.

 

* In-memory LRU for the image blobs, as another alternative to storage

That's a great idea, I will open an issue in https://github.com/thoas/gostorages

 

Would be cool if an open source version provided the equivalent and I could use it.

Justin

On Fri, 13 Mar 2015 9:01 PM Florent Messa <floren...@gmail.com> wrote:

Excellent news!

I'm planned to support imagemagick.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

[Justin Israel]

On Sat, Mar 14, 2015 at 12:12 AM Florent Messa <floren...@gmail.com> wrote:

On Friday, March 13, 2015 at 12:02:20 PM UTC+1, Justin Israel wrote:

I was about to ask if you were planning to support different image packages.
I have a similar preview image server that I wrote for internal use which has very close functionality. I wonder if you have plans to do any of the things similar to what mine has...

* ability to define different "resolvers" that can interpret the image "key" in the request, into the actual absolute path. Such as matching a certain type of URN and making an external call to resolve the path, in addition to just recognising the actual file path directly.

The purpose of this will be url rewriting if I'm understanding?

If no, could you provide me some examples :)

I suppose it sounds like url rewriting although I am not sure if it is the same.  The idea is that ultimately the server needs to source an image for which transformations should be applied and then served. An a simplest form it would be calling something like this:

http://server/getImage/path/to/the/image.jpg

But maybe you want to define how it should be able to resolve, say, a specific URN from an external system, to an image:

http://server/getImage/urn:myService:specificType:12345

If the server had registered "resolvers", and a resolver matched this key, it could do the work of resolve that id into an actual image from myService, and then the same image handling process occurs. Maybe you have different services/ways that images could be derived for different applications. An example similar to this one is that we have an asset management system that can reference images through its URNs, so my image server can accept those applications-specific identifiers, resolve them with the external service, and then do the standard handling and caching. 

 

* Mine supports color transformations directly through OpenColorIO bindings,  outside of the ImageMagick transformations , but I wonder if there was a generic way to supply a pluggable backend. Maybe people want to do them with ImageMagick instead of OpenColorIO.

It's not planned at the moment because I don't need color transformations, if you have some code examples to see a concret use case it will be great.

I don't have a public concrete example of how I am using it in my service unfortunately, but I use my own bindings for OpenColorIO (https://github.com/justinfx/opencolorigo), and allow people to do something like this in their requests:

?in_colorspace=foo&out_colorspace=bar

And this would do color transformations through OpenColorIO, which can handle the abstraction of different colorspace configurations/definitions across different projects. 

I realize my examples might be more specific to my own use case, but I was just wondering if there might be a generic way to make the concepts pluggable.

[Justin Israel]

On Sat, Mar 14, 2015 at 11:42 AM Justin Israel <justin...@gmail.com> wrote:

On Sat, Mar 14, 2015 at 12:12 AM Florent Messa <floren...@gmail.com> wrote:

On Friday, March 13, 2015 at 12:02:20 PM UTC+1, Justin Israel wrote:

I was about to ask if you were planning to support different image packages.
I have a similar preview image server that I wrote for internal use which has very close functionality. I wonder if you have plans to do any of the things similar to what mine has...

* ability to define different "resolvers" that can interpret the image "key" in the request, into the actual absolute path. Such as matching a certain type of URN and making an external call to resolve the path, in addition to just recognising the actual file path directly.

The purpose of this will be url rewriting if I'm understanding?

If no, could you provide me some examples :)

I suppose it sounds like url rewriting although I am not sure if it is the same.  The idea is that ultimately the server needs to source an image for which transformations should be applied and then served. An a simplest form it would be calling something like this:

http://server/getImage/path/to/the/image.jpg

But maybe you want to define how it should be able to resolve, say, a specific URN from an external system, to an image:

http://server/getImage/urn:myService:specificType:12345

If the server had registered "resolvers", and a resolver matched this key, it could do the work of resolve that id into an actual image from myService, and then the same image handling process occurs. Maybe you have different services/ways that images could be derived for different applications. An example similar to this one is that we have an asset management system that can reference images through its URNs, so my image server can accept those applications-specific identifiers, resolve them with the external service, and then do the standard handling and caching. 

One more example would be an absolute path to a non-image file that a specifically registered resolver would know how to then produce an image from, for standard processing.

 

 

* Mine supports color transformations directly through OpenColorIO bindings,  outside of the ImageMagick transformations , but I wonder if there was a generic way to supply a pluggable backend. Maybe people want to do them with ImageMagick instead of OpenColorIO.

It's not planned at the moment because I don't need color transformations, if you have some code examples to see a concret use case it will be great.

I don't have a public concrete example of how I am using it in my service unfortunately, but I use my own bindings for OpenColorIO (https://github.com/justinfx/opencolorigo), and allow people to do something like this in their requests:

?in_colorspace=foo&out_colorspace=bar

And this would do color transformations through OpenColorIO, which can handle the abstraction of different colorspace configurations/definitions across different projects. 

I realize my examples might be more specific to my own use case, but I was just wondering if there might be a generic way to make the concepts pluggable.

 

I will provide a generic abstraction on top of Go image lib and ImageMagick like sorl-thumbnail does, see https://github.com/mariocesar/sorl-thumbnail/tree/master/sorl/thumbnail/engines to switch the engine in the config file.

 

* In-memory LRU for the image blobs, as another alternative to storage

That's a great idea, I will open an issue in https://github.com/thoas/gostorages

 

 

Would be cool if an open source version provided the equivalent and I could use it.

Justin

On Fri, 13 Mar 2015 9:01 PM Florent Messa <floren...@gmail.com> wrote:

Excellent news!

I'm planned to support imagemagick.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.