A more robust definition of a photo object

[jmathai]

I anticipate this system will have a heavy usage on photos.

That being said, we've done a bit of work on this front. We should at least reuse or learn from the photo object we've come up with.

https://github.com/photo/frontend/blob/master/documentation/schemas/Photo.markdown

Happy to discuss why these fields are included.

[berg]

You're absolutely right—we do need a robust, structured definition of a photo. This photo object would make a good starting point for what a well-known photo attachment annotation would look like.

[berg]

@jmathai curious if you might give me some feedback on:

https://gist.github.com/3173716

Thanks!

[jmathai]

@berg I like it. A couple questions.

1. For the following, 200x200 with cropped: false means the aspect ratio is maintained? This means the actual dimensions might differ, right?
2. Are you planning on any concept of tracking what app generated the event or object? Is it feasible to have permissions around that as well? i.e. Only grant app A access to content it creates.
3. How do permissions work. At the least, public and private.
4. I see a date field but what about date taken (from exif) and date created or uploaded?

Possibly a few more but that's enough for now..

[berg]

Thanks. Let me respond to your questions in turn:

1. With cropped: false, the aspect ratio would be maintained, yes. The idea is that the key would reflect the post-crop dimensions. cropped: true means that the image has been cropped to square (that key could be more accurately named).
2. There will be a link object on the photo, which will have information about the photo's creator and app, if desired. This will allow for a link back to the canonical location of the image. I left that out because I'm still working on defining this link object.
3. This is an annotation on a post. The post itself determines the public/private nature of the image.
4. The date here is intended to be the date taken—i.e., the date from EXIF tags, given that the post surrounding this image will have its own date.

[jmathai]

That all sounds good to me. Does cropped: true implying it's a square image? Any reason the aspect ration can't be flexible?

For example..

        "200x300": {
            "size": 30,
            "width": 200,
            "height": 300,
            "cropped": true,
            "rotation": 0,
            "url": "http://example.com/photo/200x300.jpg"
        },

[berg]

cropped: true is supposed to be an easy way for an stream consumer to find a square thumbnail. Does that make sense?

[jmathai]

It does and it's probably sufficient. I'm coming from the perspective of a pure photo API when I question if the only cropped ratio should be square.

Just bringing that up in the event you forsee API developers wanting a specific size that's not a square. The way it is now your only options are to get a square or whatever the original aspect ratio is. If that's okay, then I think what you have proposed is good.