Firefox renders bad with interlaced images? - firefox

I'm converting all the images on my website to interlaced, but i found a possible issue, under OSX 10.10.5 and Firefox 38.0.5
Interlaced PNGs that are bigger than the browser window (and so they are resized in automatic by the browser) display in a very low quality, like if they are displayed in one of the intermediate layers, and not in the final version. Zooming the image to 100% removes the problem, and changing the browser windows size removes the problem as well.
Here is an example of an interlaced image:
https://trac.ffmpeg.org/attachment/ticket/161/Test_24bpp_interlaced_paeth.png
(you have to download it and open with firefox in a small window, so that the image zooms out)
This issue is happening in the 80% of the times I try the same operation.
The issue doesn't appear, instead, in jpeg progressive images.
Could you please confirm me the issue? I think it's very strange that I can't find any other people having my same problem.

Related

iPhone Parallax Background Image Resizing

I'm browsing but I can't find a solution. I have some parallax backgrounds as a dividers. In learning how to use the fixed background images, I discovered a potential issue with controlling how the background images display on mobile devices.
When I shrink my computer’s browser window, or load the sites into Responsinator, the backgrounds look fine. But when I view them on the actual iOS devices, they don’t look good. The mobile device just displays a highly zoomed-in portion of pixels that are in the center of the original image. There’s no resemblance to the desired background image, and it’s so enlarged that the pixelation creates a poor quality image.
You can check the site here:
daremblum.com
Thanks in advance for any help.

Why are the new (1.10.0) jQuery UI images the wrong color in Firefox?

I'm currently using jQuery UI 1.9.2 and want to upgrade to 1.10.0. I have a custom theme and used the URL at the top of my CSS file to visit the ThemeRoller.
My colors didn't look right, so I went through and double checked all my settings. I was using 3-digit hex colors and tried changing them to 6 digits, but that didn't help anything. I cleared my cache and restarted my computer. No change.
I started digging a little deeper. I opened the image in PSP, the colors are fine. They also appear fine in Safari and Chrome. They look fine in Firefox 12 on the laptop, but not in Firefox 12 on the PC (Win XP on both machines).
I thought maybe there was an add-on messing with my colors. But I opened the 1.9.2 image file in Firefox and it looks correct.
1.9.2 -> 1.10.0 ->
I just added the two images to this post from my own computer. I'm looking at the preview with the images side-by-side. The one on the left (1.9.2) is the one I want. The one on the right (1.10.0) looks much more purple on my screen. The background color is supposed to be #0066cc. I used a color picker to view the color displayed by Firefox. The 1.10.0 version has a background color of #4756c7. I see the same problem with all the new images, even the flat ones.
I looked at the two files with ExamDiff Pro and they are very different. Plus, all the new images are larger than the old images (more than twice as many bytes).
Luckily, I only copied over the CSS file and the new animated-overlay.gif, so I am just going to keep using the old images. But I want to understand what's going on.
So what did jQuery UI do differently when generating their images? And why did they change them? And why does Firefox 12 on my computer show them with different colors?
Hard to say exactly without seeing the actual files, but it sounds like browser variations in the way that ICC color profiles are being handled. More details on FireFox specifically over here. But it might not be FireFox being the problem & more connected to whatever your main development browser is & how it handles ICC profiles as well.
Like the FireFox article implies, the feature is fairly old in many browsers but what I have noticed is many modern browsers nowadays are actually paying attention to ICC profiles as a default, whereas before that feature was disabled by default.
Which is all to say I would see how these images look if you strip out all EXIF metadata using a tool like exiftool. Without an embedded ICC color profile, the images should render similarly between all browsers.
And to strip out all metadata with exiftool you would just run a command like this; assuming your file is named test.jpg:
exiftool -all= test.jpg
You will end up with a backup file tagged as test.jpg_original that still has EXIF data embedded and a cleaned test.jpg that now is 100% stripped of EXIF data.

Grainy images in Firefox but not Chrome

We are using a png image as our logo on our main site. The image is about 85x57 pixels. Whenever we are viewing the website on Chrome, the image looks smooth. However, on firefox the image is grainy and one can distinguish each pixel. Is this a common browser issue with Chrome? Or is there a quick fix for this?
The "grainy-look" could be the result of a bug in Firefox as mentioned in this post.
Browsers have different methods of interpolating images when NOT rendered at their native size.
Best advice: render the image at its native size.

IE not rendering png background image properly

I have create a PNG arrow graphic for use in a client's website. It render's perfectly everywhere except in IE 6,7,8 and 9. I have attached an image for you to examine and have already tried 2 different IE png fix scripts - one jquery and one a css behaviour .htc file.
Please assist me.
Thanks
Jamie
Image: http://i51.tinypic.com/2w1uzqe.jpg
Sorry to say that but for 5 years i've been looking for 100% working hack for png transparency bug in IE's with no result. There are many of them and usually each of them doesn't work here and there.
Try using transparent gif instead or crop arrow image with background along. It will take few more bytes of White color so won't damage your performance that much.
The bug that IE PNG Fix scripts are designed to fix is only a problem for IE6 and lower.. hmm.. possibly IE7? I forget. In any case, IE8 fixed the issue, and IE9 definitely shouldn't have it. These IE versions may still have plenty of bugs, but the old well known PNG background issue isn't one of them.
My guess is that there may be a corruption in the PNG file itself.
My suggestion is to try loading the PNG image into Photoshop (or your favourite graphics app), and re-save it. That may be all you need to do to solve the issue.
Failing that, would you be able to give us a link to the actual PNG file, so we can have a look as well?

32 bit depth jpg images problem in IE when referenced locally

We have an webbapplication that takes an image that will be uploaded and resized.
The resize-library we used saved all pictures with 32-bit depth whatever the depth was before.
We have an online client that can view the pictures via an html-file and all is fine there. All pictures are shown correctly.
The problem:
We also have an vb-winform application that download the pictures and show them in an html-file locally in an webbrowser control. But here all pictures are rejected (not rendered), just the red cross. If we create an static html-file with img-tags in them locally, its the same. All pictures that has 32-bits depth are shown as red crosses.
If we resave the pictures with 24-bits depth it magically works again. So ofcourse that was our "workaround", let the resize-library save all pictures with 24-bits depth instead.
Summary:
32-bits jpg files shows correct in IE when online but not when referenced locally in a local html-file. (This is true for IE8 on both winxp and windows7). The same local html-file opened in mozilla showed OK.
Question:
I have googled this a lot but has not found anything about this "problem". Is this a bug in IE8?
I have exactly the same problem with my own webapplication.
This isn't only a problem from IE8 but a lot of other browsers can't support the 32 bit depth on a jpg file.
For the while, no solution exist. Try to convert your picture in a 24 bit depth. Or wait for IE9.0 that comes soon. It's the only way you have.

Resources