I need to run with tiles on an offline system.
I like the idea of being able to download .mbtiles files,
and extract the tiles.
I downloaded a data set and tried to extract tiles using mb-util.
When I try to extract tiles from the .mbtiles file.
The .png files are not readable.
This isn't a permissions problem.
The .png files don't appear to be .png files.
Any idea why this doesn't work?
Is is not supported?
Does it have something to do with the free data set I'm testing with?
I'm going to have a difficult time getting my company to spend money for
something, if I can't prove the data is valid.
Related
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.
Is there anyway I can preserve image georeferencing information after processing or converting the image via IrfanView?
I have a couple of .png files with spatial reference and I'm trying to save them as ecw images. Unfortunately this process destroys the spatial reference vital for using the images in GIS software. If there was a way around this problem it would be a great help.
Thanks.
I would recommend using gdal_translate to handle all your geospatial translation needs.
Assuming that you have a PNG with a world file associated then you can easily convert to ecw (providing that the propitiatory ecw driver is compiled in).
How is fireworks able to store this extra information in a format that is otherwise flat raster. And is there any open source way to write similar vector, layered, paginated files in Png format that would be readable by fireworks?
The PNG format allows for ancillary data chunks to store metadata aside from the image itself. I don't believe anyone's actually worked out the format that Adobe stores that data in though.
Building a system which search for a specific region in the picture, and saves it. Everything works fine. Mostly I am going to extract these regions from pdf books.
So I am looking for a solution to treat PDF file in matlab as an array of images (each page is an image). Up till now the only thing I have found is how to open pdf files in matlab.
The best solution I came up with is to export PDF as many PNG images and iterate through them. There is nothing bad with these idea, but I am wondering am I missing something
Judging from this page it appears to be impossible to import pdf directly into matlab:
And a quick file exchange search for 'pdf import' only offers an attempt to extract text, rather than the images.
So all in all your approach of saving the pdf as images and then importing them seems to be the way to go.
I agree with Salvador Dali and Dennis. To convert each page of the PDF to a png image, I downloaded imagemagick and followed the commands here:
https://aleksandarjakovljevic.com/convert-pdf-images-using-imagemagick/
Specifically:
convert -density 150 -antialias "input_file_name.pdf" -resize 1024x -quality 100 "output_file_name-%03d.png"
Of course, there are other discussion about using ImageMagick for this purpose:
Converting a PDF to PNG and
Convert PDF to PNG using ImageMagick
This is an old thread, but it's the one I found when I asked the same question, so I thought I would elaborate in case it's helpful to future users who also land on this thread.
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.