I have uploaded images (jpg and png) to github and used them in markdown formatted file here (first 2 images):
https://github.com/vasili111/testRepo/blob/master/github_question.md
Third and fourth images are inserted with html tag.
In link above in browser images are blurred. But they are not blurred when I access images from browser directly as here:
https://raw.githubusercontent.com/vasili111/testRepo/master/images_for_github/3.png
https://raw.githubusercontent.com/vasili111/testRepo/master/images_for_github/3.jpg
Questions:
Why images are getting blurred?
How to use images in markdown formatted text without blur effect?
It's because they are rendered at a different size. The markdown-formatted ones are stretched to fit the screen; in your case, they are a bit too wide and have to be narrowed down by a few pixels, causing the blurring effect.
There's probably nothing you can do about it.
Related
I need to implement image previews via thumbnails. Now I'm not certain how to implement it.
One option would be to do it straight with CSS, so something like this:
.thumbnail {
background-image: url(path/to/image);
background-size: 300px, 400px;
}
Is that practical? Are there any performance issues?
If you scale image in CSS to be smaller than it it actually is, browser still have to download the same amount of data. You should create separate file with the thumbnail.
With images, you need to focus on three things: size, format and the src attribute.
Image size
Oversized images take longer to load, so it’s important that you keep your images as small as possible. Use image editing tools to:
Crop your images to the correct size. For instance, if your page is 570px wide, resize the image to that width. Don’t just upload a 2000px-wide image and set the width parameter (width=”570”). This slows your page load time and creates a bad user experience.
Reduce color depth to the lowest acceptable level.
Remove image comments.
Image format
JPEG is your best option.
PNG is also good, though older browsers may not fully support it.
GIFs should only be used for small or simple graphics (less than 10×10 pixels, or a color palette of 3 or fewer colors) and for animated images.
Do not use BMPs or TIFFs.
Src attribute
Once you’ve got the size and format right, make sure the code is right too. In particular, avoid empty image src codes.
In HTML, the code for an image includes this:
When there’s no source in the quotation marks, the browser makes a request to the directory of the page or to the actual page itself. This can add unnecessary traffic to your servers and even corrupt user data.
Pro Tip: Take time to re-size your images before uploading them. And always include the src attribute with a valid URL.
To ensure your images load quickly, consider adding the WP Smush.it plugin to your website.
from: http://blog.crazyegg.com/2013/12/11/speed-up-your-website/
I would like to convert a single page pdf into multiple layered images.
For example the library pdf2htmlEX converts a pdf to html by making a single background png image and placing text on that image(the text is in unicode).
i would like to do something similar, Separate the background image and other portions but all in image format.
I have looked into poppler libraries and some other solutions, but couldnt find anything useful.
A url at which someone else wants the same thing done.
How do extract text layer and background layer from pdf?
Basically exactly what the question asks. Do images on a website download the full file before re sizing them. I have a bunch of pictures and I use html to resize the images down to thumbnails to easily display on the page. However, these images take way to long to load while they are only 100px x 100px big. My only explanation is that it is downloading the entire file before re sizing.
Yes. The full image is downloaded.
If the source url is 1000x1000 and you size it on the screen to 100x100, it still has to load the entire image.
You should store the thumbnail at 100x100 and the full size at 1000x1000 and reference each when appropriate.
I was noticing that a GIF was being displayed with padding in FireFox 5 and IE 8. When I viewed the image size via FireBug, I noticed that it was a few pixels larger than expected.
Expected height: 160px vs. actual height: 171px
When I opened the GIF in an image editor, the editor displayed the correct dimensions, however when I ran ImageMagick identify I received the following information:
newGif.gif GIF 200x160 200x171+0+5 PseudoClass 256c 30kb
If I modified the geometry to 200x160+0+0 the image displayed as I expected it to in FireFox. FireFox and IE 8 seemed to be referencing the Image's page geometry rather than dimensions! Is my analysis correct and if so is this true for all image types or just GIF's?
Updated, I have included an image for your viewing pleasure! This image displays as 200 x 171 for me in FF, but is actually 200 x 160 when you download and view in a graphics program.
Header of this GIF file does not correspond to it's body.
Image dimensions are stored in 6th to 9th bytes and from the screen shot you can see that dimensions in the header are 00C8 x 00AB which is 200x171 but it's actual size is 200x160
So this image is not valid. There are no standardized behavior for parsing invalid gifs and that's why there is this inconsistency.
Most probably firefox preallocates place for images before they are fully downloaded, when an image is fully downloaded it is put into the center of preallocated space. and because preallocated space is 200x171 but the actual image is 200x160 you will see a border.
EDIT: After going through GIF format reference it appears that GIF does allow this. So the image is valid. So here's what's actually going on here:
GIF format consists from several blocks. There is a header block and one or more(if the image is animated) image blocks (there could be other blocks as well, but they are not connected with the issue). Header block holds some information about the image, including it's width and height. However each image block has it's own width and height as well. So what happens with the image in question that it has the main image size as 200x171 but the single frame with the size 200x160. So most editing programs and libraries which doesn't support animated gifs will extract the first frame and display it with the size 200x160 the browsers and editors which do support animation should display it with the full size of 200x171.
PS Every image block has image top and image left position. It seems that by allowing frames to be smaller than canvas, and allowing to move frame's position on the canvas, GIF's developers tried to shave couple of bytes of the animated gif files. I wonder if any of the modern graphic editors take advantage of that... probably not... :)
GIF format byte order
I suspect that the GIF is an animated format, so it could contain several images located on different positions of the geometry frame. Therefore, the browser should reserve place for a whole thing.
If you save the picture, and right click->properties, it'll state that it is 200x160, also of note when you preview the picture in windows black bars are added to the image, which is strange. If you open it in ms paint (just for demonstration purposes) you'll notice that the image is padded with black bars, and when you look at the file->properties it says the image is now 200x171.
The most likely scenario is that the file header says it's 200x160 (which windows/browsers etc looks at to tell you the image size quickly), while the actual image block is 200x171. The black bars don't show up in browsers as they are likely transparent, but as ms paint and windows preview don't support transparency, the black bars show in them. Further the correct size is found in mspaint because the header data is thrown out, and the properties show you properties of their data structure now holding the image block to image editing, similarly if you load the image into mspaint, modify the image to remove the black bars, save, and then put that picture into your browser then the padding will disappear.
Most of the time, when loading the image of an image file, only horizontal resolution of the image is required, and the image block is just read for the horizontal resolution for every vertical row of the image, when you read the end of the image block, you're at the end of the image, so heeding the vertical resolution isn't mandatory to load the image from it. This is why the image appears normal, and doesn't crop off the bottom edge.
As for why this image isn't padded in other browsers. I can only assume that this padding images with boarders is a standard of sorts that they have come to expect in image files, and when confronted with an image block larger than the file header specifies, they crop it toward the centre of the image block to the best of their ability
I was wondering if there is any way to use just one image for repeating and non-repeating images using css sprites.
So in this case I would like to combine all the images on a page no matter what width and height and if they will be used as repeating or non-repeating images.
I know the standard is to create 1 image using all the non-repeating images and another image using all the repeating images. But i just wanted to know if i could just use 1 image for everything.
Thanks.
The short answer is "no".
The explanation is that repeating images are displayed in their entirety in whatever direction they repeat. So, a background that is set to repeat-x will show all image content in the horizontal direction. This is why you can't repeat in both directions simultaneously using sprites.
I know the standard is to create 1
image using all the non-repeating
images and another image using all the
repeating images.
I think you are mistaken. It's impossible to selectively tile a segment of an image. You can only tile an image in its entirety. Thus, all repeating images must live in their own image files.
#Ryan Kinal is right when saying in his answer that a sprite image can't be used for repeating background images (in both directions).
There is still a way to do it cross-browser with only one or two files (not images), but it isn't that simple and should prove complicated to modify (though sprites are also complicated to modify, but at least it's visual!).
data: base64 encoding for modern browsers and IE8+
MHTML for IE7 and below (see comments for IE7 on Vista), rediscovered or translated by Stoyan Stefanov
As stated in the PHPIED article, the inline images are repeated twice but with the help of 3 conditional comments you can aim IE7 and below with the MHTML file, IE8 and above with the data: base 64 file and !IE with the same data file.
You end up with 5 different files on your server and 4 downloaded by any given browser:
an image with no-repeat-ing sprites
an image with repeat-x-ing sprites
an image with repeat-y-ing sprites
a file for MHTML (should be served to IE7 and below) background-images
a file for the same repeating background images but data encoded for IE8+ and !IE browsers
Large repeating images shouldn't be encoded as filesize could increase a lot, your design may vary.
Unfortunately you can't force both kinds of images to work on same sprite. Usually repeating image is a little part of a larger image (gradient) that could be repeated in order to save on loading time and size. You can repeat images horizontally, vertically and both.
repeat-x, repeat-y or just repeat for both. For non repeating images on the sprite you need to indicate scroll coordinates such as scroll 60px -20px (60px is left coordinate and -20px is top coordinate).