iamsalman

I'm considering doing a side-project to auto transcribe minutes from voice recognition for the meeting and index all that data so its searchable and also plugable to existing enterprise systems through REST API. Does that sound something useful?

The link is down?

ImageServe -- https://imgserve.io

Smart image CDN. Process images on-the-fly, store and serve with CDN of your choice. No need to setup any imaging infrastructure (storage, processing and CDN delivery) for web/mobile apps.

Developers get started within 5 mins to signup, point us to where your original images are and replace the <img src=""> from your domain to the new origin you just created.

One of the features is to serve the right image format which can reduce image bandwidth on a page anywhere between 40% to 400%, or more.

TL;DR Over-fitting investment models is pseudo math.

The SoC (card sized) has everything you'd need, not just the connectors to the several I/O and networking interfaces you may need. You will hook in connectors are you like with the 400-pin interface on the SoC and get going.

This has been going on since early Friday for me.

There's one serious problem with using 3rd party Imaging SDKs or utilities to build your service on: You're stuck with their flaws and you can't do much about it.

Disclaimer: I'm co-founder https://IMGX.io

We have written our own image processing SDK, using only encoders which are 3rd party (libpng, libjpeg, libwebp etc), rest is all handwritten, GPU optimized code. The rationale behind it was to be able to tweak/optimize any feature.

We wrote the complete image processing oursleves, accelerated on GPUs @ https://IMGX.io (checkout Image URL API).

Currently, only AWS offers GPU instances. There are other, smaller providers like Nimbix or Peer1 but they offer bare-metal instances. With AWS, they currently have Grid K520 GPUs which is targeted for public and private Clouds.

The gist of this paper is that non ECC memory does not zero the memory but it conveniently skips the fact that public or private Cloud uses either NVIDIA Tesla or Quadro series cards, both of which have ECC (one of the main reasons they're expensive than say GTX Titan which offers same single/double-precision performance but does not offer ECC). No one really uses GeForce series cards for anything serious and definitely not virtualization so even though this is a vulnerability, it may not effect more than 1e-10% of virtualized GPUs out there

Yes we have but crypto algorithms would still be implemented within software and not part of the GPU firmware.

The whole premise behind introducing Phi to compete with discrete GPUs from NVIDIA/AMD was to have a plug-in accelerator which supports x86 which meant no code porting needed, hence enabling companies with millions of man hours invested in their code to simply take benefit of the accelerator. However, this is not the case -- The price/performance ratio for code which is not optimized to make use of massively parallel processors would be mediocre at best.

Besides, Xeon Phi's are reincarnation of project Larrabe which never took off.

If you have to end up optimizing your code for accelerators in any case, x86 or not -- you are better off optimizing it for GPUs instead.

Three components:

1. Object recognition (there's dog and frisbee in the photo) 2. Object localization (Dog and frisbee's ROI in the photo) 3. Relation estimation (Based on X factors, the dog might be chasing the frisbee).

Not sure what you meant by spatial relations (localization?) but recognizing (what) and localizing (where) would be key to drawing relationships between objects.

Really impressive work but definitely not a leap.

Google did this with Street View for faces, house and vehicle numbers. But just masking the face won't decimate the negative effect.