6 ms·

I think photo-sharing services need to verticalize and create niches. I see a clear case for a photo-sharing service specifically designed to host high-resolut

by eterno 18y ago

I think photo-sharing services need to verticalize and create niches. I see a clear case for a photo-sharing service specifically designed to host high-resolution images (big size) images which are rapidly becoming the norm with higher resolution cameras rolling out. What would it take: 1. Uploading will take more time. Should happen in the background. 2. Browsing can be made better - by showing reduced resolutions on the fly - zooming out on parts etc.

ojbyrne 18y ago
Just allowing bigger files would be a start. I have a Canon 5D M2, and I keep ending up trying to upload > 10 mb jpegs to flickr, which has a 10 meg limit. Perhaps expensive though.
- Avshalom 18y ago
  How about a service that allows you to upload raw formats like .DNG, and do basic non destructive editing on them, nothing fancy just crop, heal, contrast, color, that sort of thing. to serve as both an online backup service, easy way to share images when you don't have time to really fiddle with them, or they're just not good enough to bother. as well as yes just sharing you're best.
  - froo 18y ago
    How about an app that kind of automatically airbrushes pics that you upload to it so that you can then upload them to other sites?
- sokoloff 18y ago
  What do you think the user tolerance for paying to host large images would be? Obviously bandwidth and storage cost money, and if a site is to allow 4x larger photos (driving 4x larger costs), the site needs to make 4x more money somehow. Page views and ads and referral arrangements to photo printers aren't going to automatically scale with photo sizes for a free site.
  - ojbyrne 18y ago
    Probably low, since there's already at least one low priced service (zooomr) that has no individual filesize limit. Prices of hard disks have been dropping precipitously, so I think there's an expectation out there that the same cost for online services should happen (gmail's steadily increasing quota also reinforces that). I realize those expectations are probably unrealistic. In terms of bandwidth, a flickr-like display that shows a smaller size by default mitigates that. It's the convenience of uploading a full-size file and getting it resized to multiple sizes (and the full size is there for those who want to see it).
  - anamax 18y ago
    > if a site is to allow 4x larger photos (driving 4x larger costs), the site needs to make 4x more money somehow Not so fast. Bandwidth and storage needs scale roughly with resolution, but other costs scale more slowly or even not at all. Note that even storage (and to a lesser extend bandwidth) has a per-action cost that does not depend (much) on resolution. And, storage costs include meta data, which doesn't scale with resolution. I've been working through a cost model for a (different kind of) image service and there are are surprises. For a first approximation, work through how you might build such a site on Google App Engine and/or Amazon Web Services and build a parameterized cost model using their fee schedules for different things. Fiddle with the values for the parameters.
    - sokoloff 18y ago
      I realize that 4x increase in pixels doesn't mean 4x increase in the file size, but I was discussing in terms of filesize. Unless you have absolutely insanely higher metadata stored per image than we do, your metadata probably amounts to under 2.5% of the image data for hypothesized 2MB files, so maybe 2.05 goes to 10.05 which is basically still a 400% increase. Part of the metadata is on fast (DB) disk, so your costs don't scale absolutely linearly, but bulk cold disk is still scaling up 4x. To a large extent, I have worked through it for our application (I run IT for a top 100 e-commerce site that does a very substantial amount of uploads in the holiday season; we choose to self-host several dozen TB and have an emergency overflow possibility out to S3 if we fill up our in-house storage). I can't see how storage costs are meaningfully sub-linear, and bandwidth costs can be due to bulk pricing, but are still first-approximation linear with upload size. (You might argue that you can use 95/5 pricing to work around that by forcing users to schedule their uploads for an off-peak time, but then you could do that in the base case as well.) I would love to hear more about your surprises in the model, either on HN or privately, as this represents a substantial portion of my budget, and if I'm missing something, I'm not too proud to change course. :)

by eterno 18y ago

ojbyrne 18y ago

Just allowing bigger files would be a start. I have a Canon 5D M2, and I keep ending up trying to upload > 10 mb jpegs to flickr, which has a 10 meg limit. Perhaps expensive though.

Avshalom 18y ago
How about a service that allows you to upload raw formats like .DNG, and do basic non destructive editing on them, nothing fancy just crop, heal, contrast, color, that sort of thing. to serve as both an online backup service, easy way to share images when you don't have time to really fiddle with them, or they're just not good enough to bother. as well as yes just sharing you're best.
- froo 18y ago
  How about an app that kind of automatically airbrushes pics that you upload to it so that you can then upload them to other sites?
sokoloff 18y ago
What do you think the user tolerance for paying to host large images would be? Obviously bandwidth and storage cost money, and if a site is to allow 4x larger photos (driving 4x larger costs), the site needs to make 4x more money somehow. Page views and ads and referral arrangements to photo printers aren't going to automatically scale with photo sizes for a free site.
- ojbyrne 18y ago
  Probably low, since there's already at least one low priced service (zooomr) that has no individual filesize limit. Prices of hard disks have been dropping precipitously, so I think there's an expectation out there that the same cost for online services should happen (gmail's steadily increasing quota also reinforces that). I realize those expectations are probably unrealistic. In terms of bandwidth, a flickr-like display that shows a smaller size by default mitigates that. It's the convenience of uploading a full-size file and getting it resized to multiple sizes (and the full size is there for those who want to see it).
- anamax 18y ago
  > if a site is to allow 4x larger photos (driving 4x larger costs), the site needs to make 4x more money somehow Not so fast. Bandwidth and storage needs scale roughly with resolution, but other costs scale more slowly or even not at all. Note that even storage (and to a lesser extend bandwidth) has a per-action cost that does not depend (much) on resolution. And, storage costs include meta data, which doesn't scale with resolution. I've been working through a cost model for a (different kind of) image service and there are are surprises. For a first approximation, work through how you might build such a site on Google App Engine and/or Amazon Web Services and build a parameterized cost model using their fee schedules for different things. Fiddle with the values for the parameters.
  - sokoloff 18y ago
    I realize that 4x increase in pixels doesn't mean 4x increase in the file size, but I was discussing in terms of filesize. Unless you have absolutely insanely higher metadata stored per image than we do, your metadata probably amounts to under 2.5% of the image data for hypothesized 2MB files, so maybe 2.05 goes to 10.05 which is basically still a 400% increase. Part of the metadata is on fast (DB) disk, so your costs don't scale absolutely linearly, but bulk cold disk is still scaling up 4x. To a large extent, I have worked through it for our application (I run IT for a top 100 e-commerce site that does a very substantial amount of uploads in the holiday season; we choose to self-host several dozen TB and have an emergency overflow possibility out to S3 if we fill up our in-house storage). I can't see how storage costs are meaningfully sub-linear, and bandwidth costs can be due to bulk pricing, but are still first-approximation linear with upload size. (You might argue that you can use 95/5 pricing to work around that by forcing users to schedule their uploads for an off-peak time, but then you could do that in the base case as well.) I would love to hear more about your surprises in the model, either on HN or privately, as this represents a substantial portion of my budget, and if I'm missing something, I'm not too proud to change course. :)