Live data from Hacker News

Introducing the new Snapchat

snap.com

61–70 of 212 posts

Re: Introducing the new Snapchat

#61
post #50

Earlier quoted context omitted.

Aren't the photos on Snapchat intended to be ephemeral? I'd be totally okay with potato quality if I was sharing something quickly because Snapchat isn't a photography app. It's not as if Snapchat are a tiny company with nobody smart enough to notice there's a camera API, this is intentional. If you want to send a quality photo to a friend, there are apps for that.

"snapchat isn't a photography app" you literally take photos and send it to people

Sure, but it's a sticky note, not a novel.

Re: Introducing the new Snapchat

#62

Earlier quoted context omitted.

as a social network whose main feature is taking photos, why wouldn't you want that to be in the best quality possible?

The main feature is not "taking photos", it's "capturing memories for quick sharing". The additional time it takes to focus/take the photo (which, judging by certain built in camera apps, could be seconds) makes or breaks the in the moment feel. In the end, these photos are meant to be looked at for max 10s with stickers/drawings/text superimposed. You don't need a high quality shot for that.

I think you are overstating the delay involved in taking a photo and having it process inside Android. Whether or not you're taking a screenshot of the viewfinder or properly processing the photo, the moment you press the shutter button is the exact moment that Android captures what the camera sees. The processing that goes inside may take a second or so (if you're using the camera API) but it's fairly negligible in the long run. Any other app on Android that properly uses the camera - whether it's a built-in camera app or something third party like Facebook, Instagram, OpenCamera, Snapseed, etc - it's not like you're waiting 15 seconds for an image to process. It's all fairly quick and seamless.

The excuse of "oh it's just for quick sharing so we don't have to focus on quality" is a strawman argument that doesn't really work, because the tech is there to allow it to function both beautifully and quickly - they just don't put the resources into making it happen.

Re: Introducing the new Snapchat

#63

Earlier quoted context omitted.

As a near daily snapchat user, and someone who has developed an Android app that use's the camera, I prefer it this way. I'm not using SnapChat to take super high quality pictures, but to share moments quickly. The WYSIWYG works well for that, and a lot of Android devices are super slow to take pictures. Dealing with Camera 1 vs Camera 2 Android APIs, and device specific issues is a mess, I don't blame them for takin…

So you prefer gimping your photo quality because you're too lazy to learn how the API works, and assume that your users are OK with this as well?

It sounds like he does understand how the API works, doesn't like the way it works, and has decided that for the scope and goals of his project, doing things the fast and low quality way meets the needs of his users.

Re: Introducing the new Snapchat

#64

Earlier quoted context omitted.

As a near daily snapchat user, and someone who has developed an Android app that use's the camera, I prefer it this way. I'm not using SnapChat to take super high quality pictures, but to share moments quickly. The WYSIWYG works well for that, and a lot of Android devices are super slow to take pictures. Dealing with Camera 1 vs Camera 2 Android APIs, and device specific issues is a mess, I don't blame them for takin…

So you prefer gimping your photo quality because you're too lazy to learn how the API works, and assume that your users are OK with this as well?

We we're doing video, so we are using Camera1 (and Camera2) where its available, but its a bad situation. Lots of obscure devices we don't have access to test on fail regularly and users blame us not Android. The API is clumsy and broken, not just difficult to use.

If I was making an app with photo taking capabilities, I would explore the Snapchat route. Obviously Snapchats users are ok with this for the most part.

Re: Introducing the new Snapchat

#65
post #50

Earlier quoted context omitted.

So you prefer gimping your photo quality because you're too lazy to learn how the API works, and assume that your users are OK with this as well?

Aren't the photos on Snapchat intended to be ephemeral? I'd be totally okay with potato quality if I was sharing something quickly because Snapchat isn't a photography app. It's not as if Snapchat are a tiny company with nobody smart enough to notice there's a camera API, this is intentional. If you want to send a quality photo to a friend, there are apps for that.

Snapchat (the company) defines itself as a camera company. This can be seen in their IPO and SEC filing documents. And I bet it has a lot to do with their snapchat spectacles.

Re: Introducing the new Snapchat

#66

Earlier quoted context omitted.

As much as I love to hate on Snapchat, there's probably no reason to use the Camera API for high quality pictures given Snapchat's use case. And if your nudes were going to be leaked would you rather they were blurred or high-res?

as a social network whose main feature is taking photos, why wouldn't you want that to be in the best quality possible?

Depends on what you mean by "high quality" If you're talking about >1MB photos, that can be a hefty payload to upload for a subset of users with poor connections. Keeping the photos lean enough but where it still looks great on the wide variety of phones is probably a better approach. That being said, I'm not sure if they get that kind of quality just from a viewfinder screenshot.

Re: Introducing the new Snapchat

#68

Earlier quoted context omitted.

The main feature is not "taking photos", it's "capturing memories for quick sharing". The additional time it takes to focus/take the photo (which, judging by certain built in camera apps, could be seconds) makes or breaks the in the moment feel. In the end, these photos are meant to be looked at for max 10s with stickers/drawings/text superimposed. You don't need a high quality shot for that.

I think you are overstating the delay involved in taking a photo and having it process inside Android. Whether or not you're taking a screenshot of the viewfinder or properly processing the photo, the moment you press the shutter button is the exact moment that Android captures what the camera sees. The processing that goes inside may take a second or so (if you're using the camera API) but it's fairly negligible in…

I think it can take a hundred milliseconds or more to actually capture. It has to switch the camera from preview mode to capture, which involves a change in resolution, encoding and perhaps recalibrating white balance and automatic gain. So press the button and hold for a beat, or when you release the button you make shake/blur the image at the moment of capture.

Re: Introducing the new Snapchat

#69

Earlier quoted context omitted.

as a social network whose main feature is taking photos, why wouldn't you want that to be in the best quality possible?

Depends on what you mean by "high quality" If you're talking about >1MB photos, that can be a hefty payload to upload for a subset of users with poor connections. Keeping the photos lean enough but where it still looks great on the wide variety of phones is probably a better approach. That being said, I'm not sure if they get that kind of quality just from a viewfinder screenshot.

It would be the same amount of data if they scale the image on the client and transfer it. The problem isn't compression quality or resolution, it's that it doesn't properly autofocus or adjust for very bright or low light conditions.

Re: Introducing the new Snapchat

#70

Earlier quoted context omitted.

So you prefer gimping your photo quality because you're too lazy to learn how the API works, and assume that your users are OK with this as well?

We we're doing video, so we are using Camera1 (and Camera2) where its available, but its a bad situation. Lots of obscure devices we don't have access to test on fail regularly and users blame us not Android. The API is clumsy and broken, not just difficult to use. If I was making an app with photo taking capabilities, I would explore the Snapchat route. Obviously Snapchats users are ok with this for the most part.

This^

I have made countless cross-platform AR apps for mobile and desktop. Never an issue with WebRTC/getUserMedia, iOS, windows, etc. However Android is always a nasty problem. From incorrect aspect resolutions, image stretching, silent fails. Each device needs a custom fix which is time consuming and costly. No wonder why Snapchat went an alternative route.

Post reply on HN