First, thanks for any and all help regarding this topic.
Sites like Facebook and Twitter strip EXIF information from images as they are uploading. My goal is to allow users to upload images to our platform (working with Nextcloud and others) with full EXIF information, however, we need to display images that do not contain EXIF information or any metadata. Without stripping and creating a second, Exif-Free image for each, is it possible to simply hide that EXIF info so that, if a user downloads that image, the EXIF is not embedded?
We were told that the only way to do this is to have a second, exif-free copy (the order of when that's created is irrelevant pre/during/post upload). I'm hoping there's a way that we can simply display such a copy without doubling our physical space requirements.
Thanks again for your help.
Exif is metadata, along with IPTC, XMP, AFCP, ICC, FPXR, MPF, JPS and a comment, just for the JFIF/JPEG file format alone. Other picture file formats support even more/other metadata.
You wrote it yourself: a download - so it's a file in any case. Pictures are files, just like executables, movies, texts, music and archives are files, too. And metadata is part of its content, so whoever accesses the raw bytes of the file can grab everything in it. Which is not "please don't look" proof. If you
create that on the fly by stripping metadata everytime a download is requested,
or if you do it once to preserve performance and instead occupy space remains your decision.
If there would be something as simple as a "don't show" feature then it would still be in the file and could be extracted easily by software written to ignore that instruction. Seriously, there's no shortcut to that - do it properly and don't spare yourself from getting work done at the wrong end.
Related
A friend of mine inherited (don't ask about the specifics here) a documentation on Google Earth which incorporates a lot of images. Those where on a server and accessed from there.
Now the server has been shutdown, so the web-links are gone. Nevertheless the images are still available as the server data has been secured. The links in GE are now marked as invalid, and I can see that there are web-links in the form of https://domain.tld/directory/image.jpg in the app.
So I am looking for a solution to extract the data to be able to replace the https://domain.tld/directory-part, replace it with an appropriate local directory (C:\directory\) and then reload it back into the GE.
Or is there any internal function/tool available in GE?
(IT-knowledge to a certain extent to make conversions is available.)
If by "documentation on Google Earth" you mean a KML file, then yes, you should be able to update the URLs relatively easily. a KML file is just an XML text file, so you can open it up with any text editor. If you use a full featured text editor then you can do a find/replace on the "https://domain.tld/directory/" part, and replace it with something that looks like: "file:///C:/directory/".
Where you find the URLs will depend on whether the images are used as ground overlays, icons, content in balloons associated with placemarks, etc.
I want to know if there is a 'right' way to make file uploads through custom tools.
I've seen the https://confluence.sakaiproject.org/display/BOOT/File+Uploads+with+RSF guide and it seens ok, but It stops with the file in memory with no further info. I can built a random file upload code but I want to make it Sakai-friendly (Using ContentHosting and Resources service?)
Any hints?
Thanks
The link you provided for the first part is a good example of how to get the upload initially processed. Going through RequestFilter will get your files validated, but you can use whatever method you want to upload it.
For the second part, I'd look at the ContentHosting webservice (createContentItem) for an example of how to add a file from a byte[] in memory after you've uploaded it.
These methods in ContentHostingService also accept InputStream as a parameter as of 2.7 (KNL-325), so you don't have to store the entire file in memory and can stream it as you're uploading, which you should do if the files are of any reasonable size.
I've been scanning some old family photos and posting them to Facebook. On the back is some information like the date or who is in the photo. So I'm dutifully entering that info into Facebook as well. But now the metadata is in Facebook, not connected to the picture itself.
If I copy/paste my scanned images subfolder, there's no metadata about who or when these pictures are from.
Is there a way to embed that info into a jpg or png?
There are ways to do this in both PNG and JPEG. The simplest way in JPEG is to inset a COMment marker with your text into the stream. You could do that with a simple C program without having to recompress the data. Just insert the comment marker after the SOF and APPn marker---it could even be write before the EOI (end of image) marker).
Some JPEG file formats (e.g. EXIF) have various predefined tags but that is format specific.
For that you'd need some image viewing application that would allow you to set the tag values.
I'm trying to create a comic reader app which supports both online reading & off-line reading (by downloading).
I've found MWPhotoBrowser as my image viewer, which supports SDWebImage as the image cache.
My problem is that if some user read little part of a comic on-line, and then they decides to download it for offline reading. Since the already read part is cached by SDWebImage, I don't wanna download them again from the web server. But since user asks to download them locally, I don't wanna keep them on the image cache neither as this will make the downloaded images out of our hand.
Copy the image from the image cache to the place I wanna put is a feasible solution, but it takes storage space. So, what I'm trying to do is cut the image from the image cache to the right place, and then make some soft-link in the image cache. In this way, there should be only one image copy in the storage file system.
You don't want a symbolic (soft) link. A symlink doesn't prevent the original file (in the cache) from being deleted. If the original file is deleted, you'll get an error when you try to open it through the symlink.
You want a hard link. You can create a hard link using -[NSFileManager linkItemAtURL:toURL:error:] or -[NSFileManager linkItemAtPath:toPath:error:]. Take a look at the NSFileManager Class Reference.
If you need to learn more about hard links and symbolic links, you can quickly find a lot of information by searching for “hard link” or “symbolic link” in your favorite search engine.
NOTE FOR FUTURE SEARCHERS
You can create a symbolic link using -[NSFileManager createSymbolicLinkAtURL:withDestinationURL:error:] or -[NSFileManager createSymbolicLinkAtPath:withDestinationPath:error:].
I have to link a date and a name to some jpegs that I am including in my bundle, or possibly downloading from my own server to the Documents folder. Is there a way to extract EXIF data easily?
If so, then I will use EXIF to store this info. If not, then I will have to create a database or flat file that maps my extra data to the image file.
Keep in mind, these are not photos the iPhone has taken and is providing via UIImagePicker or from outside the sandbox. These are photos that I am including with the app or downloadig to the Docs folder myself. The important point here is ease:
Is it easier to
read EXIF file from my image files
have another file that keeps track of
the image file and the associated
data (could be sqlite)
Thanks!
You can try using iphone-exif toolkit to extract the data. However, it's licensed GPL and if your app is commercial you'll need to negotiate a license deal. If that's not viable then you may want to go the external meta-data route.
The actual EXIF data is stored in the form of a small TIFF file with EXIF-specific TIFF tags for information that doesn't have a home in the TIFF specification. When placed in a JPEG file (really a JFIF bitstream), it is stored in a JPEG APP1 marker which limits the total size of the EXIF data to just a bit less than 64KB.
It shouldn't be that difficult to locate the APP1 marker, confirm it contains EXIF data, and then parse out a specific collection of EXIF tags with fairly brute force coding.
One example you can look at is exiftool which does just that, and is written in Perl and open source under the same terms as Perl itself.
If these files are purely for use in your own application and will not be reused in other tools by the user, then there is some mileage in storing your data as XML/JSON in the comment segment 0xFFFE. As mentioned before you get just short of 64k to play with.
The beauty of using the comment segment is that it should be preserved by image editing tools, is quick to access (because you do not need to traverse the IFD blocks that store EXIF data, you just read/write a text string with 4 byte type/length header) and is human readable/writable in a graphics app.
I would avoid storing the associated data in a db if practical, so that you don't risk the db becoming out of sync with the available files.
I use ExifTool
embedded in my app. Works a treat.