So for example, there's a site that tells me what the byte arrangements are for GIFs, for example, the first 7 bytes are the HEADER, next 6 bytes are description information etc etc?
I am looking for both static and animated GIF images.
Bonus points if you can supply a site that covers other images.
It's so I know how to correctly interpret the files.
Search in the wiki a http://en.wikipedia.org/wiki/Graphics_Interchange_Format got a link.
Related
My goal is to write a program (e.g. in Python or C++) which takes as input a JPG file (e.g. tux.jpg) and make tiny changes to it, such that it outputs many different images (maybe a thousand images or even more), but in a way that all these images, while having different hash, look almost the same visually, i.e. the changes should have the least impact to the original image as possible.
I first though to play around with the jpg header but that might not be enough to make the many thousands of different pictures I want.
As a naive way, I thought to flip a random bit in the file, but that bit can possibly result in a less than desirable result, which can be seen especially in small pictures (e.g. a dark pixel in the white space in the tux picture). Ideally, I would like to change a random pixel with a "neighboring" color, such that the two resulting pictures have almost no visual difference.
For this purpose, I read the JPG codec example but I find it very confusing and hard to understand. Can someone help me what my program should look for as it parses the file in binary format and how to change a random pixel with a "neighboring" color?
You can change the comment part of the file by playing with the file header. A simple way to do that is to use a ready made open source program that allows you to put the comment of your choice, example HLLO repeated 8 times. That should give you 256 bits to play with. You can then determine the place where the HLLO pattern is located in the file using a hex editor. You then load the data in memory and start changing these 32 bytes and calculate the hash each time to get a collision (a hash that matches)
By the time you find a collision, the universe will have ended.
Although in theory doable, it's practically impossible to crack SHA256 in a reasonable amount of time, standard encryption protocols would be over and hackers would be enjoying their time.
Say I have some icons on my site (32x32, 64x64, 128x128, etc.), then converting them to Base64 makes sense, right?
Now say I have some high resolution images that are 2MB, 3MB, 4MB, and greater that I am using on my site. Does it make sense to convert these larger images to Base64 or is it "smarter" to simply keep using them as .jpg/.png/.gif/etc.?
If there is such a "law", "rule of thumb", etc. what is the line in the sand?
EDIT: While this post was marked as a duplicate, the linked "original" is from over 10 years ago; browser technology, computers, and the web itself, has changed significantly since then. What would be the answer for today's technology?
The answer to the questions is yes, and it depends.
If we rephrase the question to: Does the law of diminishing returns apply to using base64 for embedding images in a page?
a) Yes, the law applies
b) It depends on: Image count and size, and your setup (ie HTTP (HTTP/2?) connection type, etc)
The reason being that more images require more connections imply more handshakes, unless you are using keep alive connections or HTTP/2 streaming. If the images are bigger and require more computing to convert from base64 back to binary (plus decompression), then the bandwidth saves come with CPU expense.
In general, if you have lots of images (icons, for example), you could embed as base64. But in that case you also have the following options:
a) Image Atlas: Converting all small images to a single image (one load) and showing only the portion that you need through the page.
b) Converting to alternative formats, such as fonts or SVG, and again rendering what you need. Example: Open Iconic.
We are participating at the RoboCup 2015 from the German Aerospace Center in October. Before the torunament we will get a 30x30 pixel sized TIFF image, representing a low-pixel heigtmap. My task is to write a fast and lightweight, dependency free code that reads this TIFF image an does some algorythmic stuff on it.
I googled about the TIFF image format and it seems there are some powerfull libraries, but is there a simple way of reading just the color values of the file?
I remember a format, don't know which, where I just skipped the first 30 bytes and then could read the color values in RGB. Do you have any code that could do that or an idea/explanation how I could acchieve that?
As I said, I do not need filename, imagesize data etc. I actually don't even know why they have choosen the TIFF image-format since its just a normal heightmap in greyscale, but however.
Every help is very appreciated.
I have two ways to approach displaying an image on my webpage.
One way is a simple pass to the path of the image in src attribute.
Second way is to pass data in the src attribute
Will any problem occur in the future? Or a longer page loading time with second approach?
Suggestions please.
Loading the image in the page will be slower up front (larger html file), but faster overall (fewer requests to the server). Note that IE7 and lower have no support for this, and IE8 doesn't support images over 32k. (Source) Encoding in base64 also increases the image size by 1/3. (Source)
In my opinion, it makes sense for icons in CSS files, occasional small thumbnails, etc. But several large images should be loaded from normally.
If you have path: Use it.
First of all, data is not standard, so you can´t guarantee it works.
Second, you´ll get things like cache management free, without writing any code.
Yes the second approach is something like 8 times slower than the first one. That’s base64 encoding.
I use base64 to do small images, and the benefit of this is that they can be stored in a database. Use them on things like thumbnails, profile pictures etc... anything that is around 100 or 200 KB
EDIT: Sorry my bad... 37% bigger file size is base64
On a website I'm creating, I have about 100 various thumbnails (64x64) that get displayed at different times. On some pages, only 5-15 thumbnails may be displayed. On others, all 100 are loaded.
I'm considering using a technique like CSS sprites to display the images. That is, rather than have image tags for each thumb, do something like:
<span class=thumb1"></span>
And then use CSS to take a slice of one single image with all the thumbs stitched together. That is, one image with all 100 thumbs (in this scenario, a 640x640 image).
My questions:
Is this a good idea?
If yes,
should I do it on all pages the
images occur, or only on the pages
with all the images?
Is there
another technique other than sprites
that may be better than simply
including the images with img tags?
If you think that an ordinary user would visit at least two different pages with these thumbnails than my opinion is that using sprites would really be a good idea!
I would in fact make a single big image with all the thumbnails and then use it in all the pages!
Why?
Fewer http requests (from 100 to 1)! And this is one of the most important thing about web site optimizations (read here from Yahoo Performance Team speed optimization rules )
This way users will download the whole image only the first time and then they will get a super quick loading of that images in all the following pages
The most famous websites on the internet already do that! See sprites used in Yahoo, Amazon or Youtube pages.
You can add other UI or layout images to your sprite
Optimize the resulting PNG:
After you have generated your sprite, if a PNG, you can optimize the PNG even more using this tool: http://www.sitepoint.com/blogs/2009/09/18/squishing-the-last-drops-from-your-pngs/
When not to use sprites:
When part of the images in the sprite change frequently
In this specific case: when the majority of users would need less than the (about) 10% of the images
I'm not quite sure what you mean with "sprites", but this is what I think you mean: instead of 100 images seperately, you create 1 image, with a 10x10 raster. Each coordinate (x,y) contains one of the images you like to show.
Now, if you display an image, you use CSS to set background-location: i.e. x * -64px and y * -64px, perhaps using JavaScript to calculate the x and y for each image-span, or Server-Side scripting to print out a dynamic CSS.
Yes, this is a good idea: it reduces load time, since one only has to download one big image, instead of hundreds of smaller ones.
It depends. If you have caching-abilities for a page, then you can "stitch" all thumbnails into one image file. If you have a very dynamic webpage, then it's quite harsh to build this stitched image every time the thumbnales are updated.
Not sure, if this is what you ment with "sprites", then no, if you ment something else with "sprites", then yes: this answer is an example of one.
It is a good idea if
Speed matters
You don't care about accessibility (screen readers reading the ALT text of an image, etc, all that is gone when you use sprites)
You don't care that your thumbnails are not going to be printed by default in any browser
You can do it without it becoming a maintenance nightmare (which image was on position 461 again?)
As to your second question, it is probably advisable to put all sprites into one or very few container images to minimize loading times.