I am creating an app that allows you to quickly share a file (like a photo or video). It will work by generating something like a barcode, but it can be animated or anything. Just a scannable thing that can be used to shared large amounts of data. I know a QR code can only hold up to 3kb, but in this case I’m not limited to a static image. Anything that can be used to transfer data from a screen to a high resolution camera works. (However I don’t want it to upload the file to a server and then generate a QR code link to that file)
Thanks!
You need to have a storage account somewhere and hold the data in that storage and your QR code needs to redirect to that storage
Related
I develop website where people can upload images for using as textures.
I want to limit pressure on web-server by avoiding storing the same image twice.
As users can upload images very often I want to have a very fast technique to identify is uploaded image have a copy on web server and if it has when discard it and use already existing image.
Is it ok to use hash function for this task if I can accept possibility of different images having the same hash below 1e-5? What hash function is better suitable for my task?
I was wondering if there's a way to build a QR code with two kinds of data - one text data and two link URLs. Is it possible to do it?
A QR Code is a two-dimensional barcode capable of storing (according to Wikipedia) up to 2,953 bytes of binary data or 4,296 simple alphanumeric characters. The data can contain whatever you like.
The difficulty with storing multiple URLs in a QR-code is not that it is impossible, but that most scanner apps in smart phones and so on will only process a single URL. If you are writing the scanner app too then, yes, it it possible, otherwise it is possible but probably not advisable.
If you wish to store a single URL and some contact details you might look at storing a vCard in your QR code (here is a generator; I have no affiliation with this project).
It's indeed possible, but all scanner apps will not recognize all the data, and only one show one data. This QR code generator has a Multi URL feature that can redirect based on different parameters as time, location, device, ...
It is possible. we can enter text,URL,v card on a single QR code.
Well, actually, the QR code is "only" storing characters, so you could imagine having an app or any software that read the QR code content, which contains data and two URL, which split the string to open two tab.
I have a website where users upload images. These images are shown on various sections of the site with various thumbnail dimensions. Since the site is still under rapid development, I don't yet want to commit to a set number of thumb sizes. Thus I believe I should be generating thumbnails on a lazy basis.
Of the two options, which is the most performant way to do this:
When I go to serve the thumbnail, convert the dimensions into a canonical filename (like "bighouse-thumb-160x120"). Check if the file exists in blob storage using client.GetContainerReference(containerName).GetBlockBlobReference(key).Exists(); If it does not exist, generate it and save it.
When I go to serve the thumbnail, query my SQL database to see if the thumbnail exists. If it exists, get the blob URI from the DB and emit that as HTML. If it does not exist, generate it and update the SQL database.
I've used #2 in the past, but design-wise it is duplicating state which is bad. If querying azure for the existence of blobs is scalable, I'd rather do that. I don't really understand the threading model in Asp.Net. If I have 200 users requesting thumbs, will my azure Exists calls all happen in parallel? Even if they do, two round trips seem like a lot of overhead. I assume roundtripping the database is faster and lends itself more easily to generic caching solutions.
What is the right answer?
Regardless of the overhead, I would pre-generate thumbnails when you upload/store the image. This way you move the burden of generating thumbnails from something that is done many times (retrieving an image) to one that is much less often executed (storing an image).
Consider the following scenario, when you lazily generate thumbnails on the first view:
Check for an existing thumbnail (is false, first view remember ;))
Generate a thumbnail
Store the thumbnail
Send the thumbnail to the client
With pre-generated thumbnails the process is much shorter:
Send the thumbnail to the client
Done.
With 'lazy generating' the check for existing can be expensive due to network overhead (on every hit!), generating the thumbnail can be hugely expensive memory- & CPU-wise and than you have to store it, with network overhead again. You can even offload generating the thumbnail(s) to a separate process, possibly started by queue messages, to take the burden of generating the images even further away from your webservers.
However, this brings up the question of what you should do when you introduce a new thumbnail/image size. When you pre-generate the thumbnails you can write a simple tool to create the new sizes and store them, and if you went the separate process route it's even simpler. Just upgrade the separate process, generate a queue message for every existing image and just let it do its work.
I have the need to mopdify the information of patient,study,series,instance,and I have done this by putting information to dataset that stored in database.Now my question is that the information stored in database does has been modified but the dcm files stored in pacs can't modified.Is there any way to modify the dcm files at the same time?
I could be wrong, but I do not believe dcm4chee changes the images when you edit the fields through the web interface. Instead what it does is it modifies the fields in the data base. When an image is retrieved from the dcm4chee pacs, it will prepare and send the modified images. At that point in time it creates a new image header (updated with changes made through the web UI and the changes required because dcm4chee handled the images). The retriever will then get the modified set of images, dcm4chee will continue to store the original images.
To get the modified images issue a C-STORE request and have dcm4chee send the images to another client or pacs. That system will receive the modified images.
If you have DCM4CHEE 2.17.x, then you should be able to edit some information. Go onto the web interface for your installation and look for the Edit [Patient/Study/Series/Instance] Attributes icon (looks like a document with a pencil). If you click on that, you should be able to enter new values for some of the items.
Most PACS will ignore a storage request if they already have the identical SOP Instance UID value. So, another method to change the data is to use a toolkit to modify the fields you want, and then generate new UID values for the images (and it's a good idea to do the same for the study and series UID values too). This will create duplicate entries, but with different values.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Storing Images in DB - Yea or Nay?
Friends,
I have a requirement to show dynamically changing images in DataList. what I did was I am storing the images in DB as image datatype and retrieving the images. Is that good technique to store images in DB?
FYI, user can upload the images.
Regards,
Abhi
The answer is - it depends... Studies have been done (http://research.microsoft.com/pubs/64525/tr-2006-45.pdf) which have basically concluded if objects are larger than one megabyte on average, NTFS has a clear advantage over SQL Server. If the objects are under 256 kilobytes, the database has a clear advantage. Inside this range, it depends on how write intensive the workload is, and the storage age of a typical replica in the system.
I would store them as physical files on the server, but store the file path in the database, not the actual image. Storing the image in the database will increase it's size dramatically over time.
Images sizes will increase your DB size unnecessarily so not good practice to store it, instead store the file path in your db, which is not that big.
Storing image in DB should be done if you have some strong requirement or use case.
The thing you have to address if you store paths etc. is maintaining referential integrity with your images. What if somebody moves files, what if somebody uploads a new file with the same name (I'd suggest uploads get renamed to reflect some kind of key rather than keeping their original name of bob.jpg). You'll need to look at segmenting your directories etc. to keep the list sensible. Finding the images may be harder than if you store them in a DB also.
However, on the up side, you can form a CDN based on distribution of your images over diverse servers, subdomains, cloud etc. if you don't jam them all in your database
Depends on the size of the images and the DB you use.
For SQL Server it is pretty bad idea if they are larger than 1MB and you do not use the NTFS Filestreams for storage of your BLOB fields.
See for example http://www.simple-talk.com/sql/learn-sql-server/an-introduction-to-sql-server-filestream/
If you have a document oriented database like Couch DB it might be ok.
I would store them as physical files on the server, but store the file path in the database, not the actual image. And search the file as per the location store into Databasse. Storing the image in the database will increase it's size dramatically over time.
Storing them in database is also useful if you need to scale your site across multiple web servers.
If they are static then there is no use as they can be deployed with your site but things like avatars are generally better stored in the DB so they are available to all cluster members.