Imbo ends up using :443 in the URL when generating a signature if accessed via https://.

Imbo needs an event listener that can purge one or more Varnish servers when different events occur.

A resource that makes it possible to test public/private keys, signing etc. Would be great for clients to make sure they are correctly configured. Could possibly also test database, filesystem etc.

Seems like imbo return always a jpg and consequently the wrong md5 of the image.

hi,

i tried adding a facebook profile picture either in format https://graph.facebook.com/user.name/picture or https://graph.facebook.com/user.id/picture which both resolve to https://fbcdn-profile-a.akamaihd.net/hprofile-ak-ash3/some_id_id_id_q.jpg via the addImageFromUrl function.

all of them gave me the ImboClient\Exception\RuntimeException

An error occured. Could not complete request (Response code: 0)

then i tried this picture http://upload.wikimedia.org/wikipedia/commons/1/1d/T-90_Bhisma_cropped.jpg. it worked ok.

what can be the problem? thanks

This makes it easier to debug problems related to transformations not existing on installations, typos etc.
Also prevents caching engines like varnish from caching an image without the transformation applied.

Generating a signature on the client side with the URL http://imbo.somehost.com:81 will use the port number when generating the signature, while the server does not.

Slightly unsure about the preferred URL-structure here, but an example would be:
/users/someuser/images/20ba09e9434c448ed629388ea5370749/?p[]=profile&accessToken=e0608d04e48ff13a3e5a700bf536bc473bfe4ab733b79140e4ceb0dbd95f2efe

Where "profile" would be a preset configured bundle of transformations, for example:
MaxSize(78, 78)
Canvas(78, 78, 'center')
Border('f00', 1, 1)

This would (in this case) cut down from 243 to 145 characters in the URL.

Another nice addition to this would be to have a "whitelist"-flag, which would indicate that the given preset did not need an access token.

Thoughts?

without an htaccess to route all requests to index.php it won't work

The border transformation should have a mode parameter that enables you to decide if the border should be put outside of the original image (which is the current behavior) or inside the image, which will retain the original image width and height.

The crop transformation fails if x or y is equal to 0.

http://host/users/dev/images/image?t[]=crop:width=100,height=100,x=0,y=20

results in HTTP/1.1 400 Bad Request with this message:

Missing required parameter: x

It would be nice to be able to configure the accessToken event listener to only be triggered for requests with one or more transformations attached.

This would make us able to send only the image identifier to a frontend and let javascript handle the URL building, potentially saving a lot of bytes.

If a client requests the following URL:

/users/foobar.json

and the foobar user does not exist, the server should respond with Content-Type: application/json, but instead it uses the Accept header. Imbo disregards the Accept header when a specific extension is used in all other cases, and should do so in this case as well.

Imbo should have a CLI tool that can be used to install event listeners on the server, and also modify parts of the configuration file to make it more easy to add users for instance.

Imbo needs stricter image validation on PUT. Now it accepts broken images (which is represented in the return value of getimagesize by size/width of 0.

Imbo should support automatically adding transformations for all images (configurable per user (public key), before and after the regular transformation chain. This could for instance be used to automatically apply watermarks to all images for specific public keys.

The configuration might look something like this:

<?php
namespace Imbo\Image\Transformation;

use Imbo\Model\Image;

class customTransformation {
    public function __invoke(Image $image) {
        // custom transformation code
    }
}

// used in the configuration below
$customTransformation = new customTransformation();

function customFunc(Image $image) {
    // some custom code
}

return array(
    // ...

    'autoImageTransformations' => array(
        // settings per public key
        'publicKey' => array(
            // transformations applied BEFORE transformations specified in t[]
            'pre' => array(
                // implementation of the Imbo\Image\Transformation\TransformationInterface interface
                'thumbnail' => new Thumbnail(),

                // closure which receives the image to work with
                'customStuff' => function(Image $image) {
                    // custom transformation code
                },

                // callable code (instantiated above)
                'moreCustomStuff' => $customTransformation,

                // reference to the function defined above
                'awesomeCustomTransformation' => 'customFunc',
            ),
            // transformations applied AFTER transformations specified in t[]
            'post' => array(
                // same possibilities as above
            ),
        ),
    ),

    // ...
);

The transformations can be specified in the same manner as regular transformations under the ìmageTransformations key in the configuration array (see http://docs.imbo-project.org/en/latest/usage/configuration.html#image-transformations) and will be applied in the order specified in the configuration.

Thoughts?

Instead of specifying all the public keys except a few exceptions, it would be nice to instead reverse it and only specify the public keys where the event listener should NOT be active.

When I enter a page with images generated by imbo they are not displayed. When image is viewed as single resource in browser (image link opened in window) and page is refreshed it becomes visible for browser.

Signatures are as of now generated using a timestamp. If this timestamp differs more than a minute or two, the request fails. This is potentially a problem in open environments where the date of the servers might be out of sync.

A solution where the signing of requests would work independently of the system clock would be a nice addition, improving the reliability.

We have experienced that every once in a while an image is stored in database but not on the filesystem.

I have not experienced this when actually adding the image or in use, only when requesting /images

I see two possible areas where something might go wrong:

• Adding an image
• Deleting an image

We should investigate this further and see if we can find any code which might lead to this "unsynced" state.

Seems like the thumbnail transformation does not care about the height parameter if one uses "inset" mode and the image is lower than the requested height.

It would be a really nice addition to be able to drop in a custom transformation without having to integrate it too deeply into the Imbo core. Adding transformations through the bootstrap for example would be a nice addition:

$container->transformationManager->addTransformation(new Rexxars\Transformation\Sexify());

...or some other clever way of doing it :-)

Imbo should include a transformation that enables progressive image rendering.

Today the router component uses the following regular expression for public keys:

(?<publicKey>[a-zA-Z0-9]{3,})

Because of this the public keys can not contain underscores. This should probably be fixed.

If the accessToken contains XSS like </script> the regexp is broken.

When adding metadata, the backend should return a 201 response instead of the default 200.

When a new image is added it is first added to the database. If this is successful, and the storing of the file using a storage driver files, the image needs to be removed from the database as well.

Whenever a transformation results in an error, and you use an image extension, the ResponseFormatter class tries to format the error model with an image formatter, which obviously makes no sense.

To trigger the error, make a request like this:

http://host/users/<publicKey>/images/<image>.<ext>?t[]=compress

The bug was introduced after the 0.1.0 tag.

When the /status resource responds with an error (for instance if the database is down) the HTML and XML response formatters fails. They both require an error element in the response data, which does not exist in the status resource, causing a E_NOTICE and some unexpected output.

Imbo should have browser plugins that enables users to right click on images and directly upload them to one or more Imbo installations.

Imbo currently only works running behind Apache because it depends on the Apache specific server variable REDIRECT_URL in Http/Request/Request.php.

The difference between REDIRECT_URL and REQUEST_URI is that REDIRECT_URL has the GET paramters stripped.

My proposed fix is to change the Http_Request contructor to build the path like this:

-        $this->path = str_replace($this->baseUrl, '', $this->server->get('REDIRECT_URL'));
+
+       $this->path = str_replace($this->baseUrl, '', $this->server->get('REQUEST_URI'));
+       if (strpos($this->path, '?') !== false) {
+            $this->path = substr($this->path, 0, strpos($this->path, '?'));
+       }

Just a test to see if the notification stuff works.

Would be great to be able to add metadata after an image has been added, for example.

Would be nice to be able to upload an image in any format and have imbo serve you the image in the format specified, falling back to the original version if none is specified. Example:

I upload an image, my-cat.jpg, to imbo. It stores it without modification and the returned image identifier is simply a md5-hash of the image, without any extension.

If I want to fetch the image as a PNG, I can simply request GET //.png
If I wanted the original image (as JPG), I could GET //(.(jpg|jpeg))?

This way, one could easily use the service in scenarios where a specific file type is required, as well as only needing to store the actual md5-sum of the image as the identifier.

Now Imbo responds with an error if a client tries to add an image that already exists. Instead it should simply replace it and return 200 OK.

The code that handles the metadata query needs to use dotted notation instead of objects to be able to execute the types of queries we want.

Today the auth info (public/private key pairs) must be an array. Imbo could also support a closure for the auth part of the config that must return an array, making it easier to implement a different source of public/private keys than the configuration array. For instance:

<?php
return array(
    'auth' => function() {
        $pdo = new PDO('dsn', 'user', 'password');
        $sql = "SELECT publicKey, privateKey FROM imbo_users";
        $stmt = $pdo->prepare($sql);
        $stmt->execute();

        return $stmt->fetchAll(PDO::FETCH_COLUMN | PDO::FETCH_UNIQUE);
    },
);

looks like its not possible to do a query on metada.

use case:

user creates an album, so i tag all photos with the name of the album, now i would like to retrieve all photos just by supplying the album name and the user. is it possible?

i believe that the hash can be indexed, so it should be doable.

Would be great to be able to ask /images for specific image identifiers.

Imbo should provide a stats endpoint that stats systems can use to aggregate data.

Elements that should be included:

• Number of images
• Number of users
• Number of images per user

Imbo needs a transformation that can take an image and expand the canvas. Options must include the color to use in the regions that end up outside of the original image, and some options for how to place the original image inside the new canvas size.

could not get imbo running - if i call /status.json i get a white screen & in the logs get an error message about php consuming too much memory ( i gave php 2048M in php.ini )
any ideas?

Imbo should use sha256 instead of md5 for calculating the checksum used as image identifiers.

MySQL won't accept the schema defined in the documentation because imageIdentifier does not have a length. Key definition for imageIdentifier does not have a length either, and is not accepted.

When configuring PHPIMS the document root must point to the public dir. PHPIMS should support residing in subdirs as well.

Today a user can't change a public key without a lot of manual work. Imbo should ship with a tool that can be used to change public keys (automatically move images, update metadata and so forth).

hi,

are the there any plans for a backend for imbo?