I'm trying to fit small part of a video on the larger static PNG background and the edges of the video are supposed to seamlessly blend to the background, ie. you shouldn't be able to recognize where the video ends and static image in the background starts.
However, I found out that every browser renders the video colors differently. In Chrome, it depends whether you add ANY CSS filter (-webkit-filter) property, for example
filter: saturate(100%)
(which shouldn't change the video at all). I created this JSFiddle to demonstrate the problem https://jsfiddle.net/bj4hshwz/1/. Without it, it renders the video slightly brighter. With the filter property, the video is darker/more saturated (and matches the background in my case). Firefox renders the video correctly and it matches the background and in Safari, it's always brighter, whether you add the filter or not.
Is there a way how to make the video in Safari also correct?
The no-op filter changing rendering is a bug. You should report it to the browser vendor. Your reduced test case is going to be helpful for fixing this.
Apart from that, there's a problem of color profile handling in videos, and it's a bit of a mess.
Images and CSS colors on the web generally settled on the sRGB color space, but videos internally use a few other color spaces, most commonly Rec. 709 (for HD) and BT. 601 (old SD TV).
The problem is these profiles are similar enough that a lot of software doesn't care about converting between them, or converts incorrectly (which so easy, because there are so many subtly incompatible color spaces called "YUV"). Only when you try to match colors exactly (like you do), the error becomes noticeable.
Rec 709 has gamma ~2.4 and sRGB has gamma ~2.2, so software that doesn't convert precisely between them is going to make brightness slightly off. 709/601 mix-up is going to shift hue a bit.
To get video colors match CSS colors exactly all the stars must align:
Software that you use to generate video needs to read colors in sRGB and convert them correctly to video's color space (e.g. Rec. 709). It probably won't, unless you set appropriate flags/checkboxes.
Information about the video color space should be embedded in the metadata of the video file, so that the players don't guess it. Some players will guess anyway (e.g. Firefox assumes low-res videos can't use HD color space).
Player (browser) has to understand video color spaces and be able to choose the right color space for the video.
The browser has to play the video with conversion of color to the display color space (last time I checked Firefox didn't do that, unless you manually enabled a hidden option).
The browser has to convert CSS colors from sRGB to display color space (or failing that, leave CSS colors alone, but always convert videos to sRGB). Chrome is very bad at this.
You can count on Safari doing all of this correctly, but in other browsers it's generally hopelessly buggy. Consider changing your design to hide the discrepancy?
I noticed this on Chrome for Android, so I used the below code to target Chrome on Android:
#media screen and (-webkit-min-device-pixel-ratio:3) and (pointer:coarse){
video:first-child {
filter: contrast(1)
}
}
...but it doesn't work for fullscreen.
What I ended up finding was a suggestion to set chrome://flags/#force-color-profile to sRGB
That fully resolves the issue.
Related
I have a link to a pdf file pdf-link
The background colors display correctly in firefox but not in chrome. Is there a way to fix this?
All pdf viewers should render the default range from white background to black text It is possible in PDF viewers to change that range by filtering but most will default to keep RRGGBB static from 000000 to FFFFFF, there can be small differences in tone shades but not usually noticeable by eye (often requires screen capture of rendered colour to spot any slight shade difference). Acrobat can have the greatest range of enhancements for Accessibility, altering different objects colour. But thats exceptional for browsers unless there are plugin enhancements.
Anyway here Firefox is top left, and Chrome is lower Left, without a noticeable difference.
We've developed a web application that shows quite a bit of data in a somewhat fancy interface with a table. I can't show the page, but it has quite a big table, inside a fixed positioned element, with some images (mostly icons smaller than 2KB, PNGs with alpha transparency, and no more than 30 different images).
It's not that heavy, with less than 1000 elements in the page. It was developed mainly in Chrome, and works flawlessly in Chrome. And IE11, and IE10.
But when it comes to IE9, this happens:
Yes, that's IE11, because it offers decent analyzing tools. I'm using IE9 emulation, but that same unresponsiveness happens with IE10 in IE9 mode, and with "native" IE9, with high CPU usage - but steady memory usage.
In a lighter way, it happens in IE8 too:
But the repainting takes much less time (perhaps it repaints smaller parts of the page?) and the responsiveness isn't compromised.
As you can see, no script is running, just some random garbage collection. In IE10, IE11 and Chrome there's no repaint involved.
If I disable the images (did this in IE10, don't know how to do that in IE11), IE9 doesn't keep repainting, but if I disable or hide all the images through the style sheets it keeps hogging the CPU. Disabling hardware acceleration makes things even worse, as expected.
What may cause this odd behaviour in IE9 (and partially IE8)?
After a lot of investigations, I think I've found the culprit.
It seems to be a problem related to animated GIFs. Whether it's a <img> element, or set as a background image, or as the content of a pseudo-element, even after it was removed from the DOM the browser keeps on repainting the same portion of the page.
This can be a very intensive task, not only in older computers, especially when using larger GIFs. But even when using smaller ones, if the GIF is used as a background image or in a pseudo-element, IE9 repaints the whole area of the element, rather than just the area of the image.
That's why it keeps on repainting a huge area of 1750x1051 pixels in the screenshot. And I just used a crappy 64x64 spinner!
So... beware of spinners. And IE9.
Solution
I haven't found a simple and definitive solution yet (except ditching IE9 altogether). The first thing to avoid is using animated GIFs in background images and pseudo-elements.
If you have to show a spinner in IE9, you can either use a small one, or a static image. Alas, you have to animate it yourself because IE9 doesn't support CSS animations. And you can't rely on requestAnimationFrame either, just setInterval.
I just hope you can take advantage of jQuery. I couldn't...
For some reason, IE8 deals with animated GIFs much better, even if it's still not perfect.
I am optimizing my site for these higher resolution monitors (especially the new iPad). I have the site formatted the way I want, and I was just increasing the resolution of each image but still constraining it to the DIVs that I currently have. For example, I have an image with a resolution of 483x246 and I have it fitting a DIV with a set size of 188x96.
The images look great on Chrome, Firefox, and most importantly on the new iPad. Even zoomed in it's nice and crisp (as opposed to my old 188x96 image that looked blurry and pixelated when zoomed in)
The problem comes in when I open the page in IE. It displays the image at the correct size but it's jagged. See link to comparison below. I know it's an issue with the way IE resizes and renders pictures on the fly.
My question would be, is there a way to make IE display the picture nicely? If not, is there a way I can put in the code so that if it detects IE, it displays my old low res image? I've looked everywhere but haven't found anything that relates to my specific problem. I know this is a small example but my bigger images do the same thing and are more noticeable. I hope you all can help. Thanks. :)
Comparison:
Have you tried putting this in your CSS?
img { -ms-interpolation-mode: bicubic; }
There's also this https://github.com/adamdbradley/foresight.js which looks very interesting
Make sure IE9 isn't in compatibility mode or IE7/8 mode...
The reason this happends if because the bitmapdata is actually rendered completely different in the IE browser, the thing IE does is it "cuts" away pixels over a set ratio so like every 5 pixels it yanks a pixel and therefor makes it look like it misses certain gradient properties.
not much you can do about this except for keeping the aspect ratio set but I guess you would've known that by yourself already
On this page, the <body> element has a background color of #77BFBC. The image (rv-banner.jpg) set as the background of the <header> element also has a background color of #77BFBC.
On windows (either FF or IE), the two colors blend perfectly. However on FF on the Mac, there is a noticeable difference between the background color of the image and that of the <body> element. How can I fix this?
Thanks,
Don
With the release of Firefox 3.5, colour-correction was turned on by default, but its effect depends on your system profile:
http://hacks.mozilla.org/2009/06/color-correction/
In practice, this means images saved with colour profiles are corrected and could show up mismatched to CSS colours.
It's possible to turn off colour-correction in Firefox, which fixes the problem for you, but that still leaves all the other potential visitors out there. Seems like removing the colour profile from the image is the way to go. There is a GIMP plugin that does this, see here for a discussion.
When images are displayed, they are converted from their color space to the color space of the screen.
To make your JPEG images display with the same color conversion as the rest of the elements, you should convert the images to the sRGB color space before saving them.
Browsers that doesn't support color profile information in images always uses the sRGB color space, so if you use sRGB for the images the color profile gets correct even for those browsers.
If there is no color profile in an image file, the sRGB color space is assumed. This means that you can save your images without a color profile to minimise the file size.
Try to save image as png not jpg. And if you are using photoshop, then choose "save for web and devices" not "save as".
This isn't due to your code but color profiles, I don't know if you can change this.
On this test page: http:// www.onebagoneearth.com/ Products-test , where it says "oboe love series", "oboe kind series", etc, when you hover over that text (which is a background-image) in IE7 and IE8(at least on Vista, and also with IETester), the image blurs (not just by being opaque though...that would be the normal hover effect). Why is that?
The same thing doesn't happen on this page with similar CSS: http:// www.onebagoneearth.com /Products . If it's the zoom:1 bit of CSS, I don't understand why it would do that on one page and not the other.
I see what you mean, but on my computer it doesn't blur, it gets a noisy outline of dark gray pixels instead.
It's because you are using a PNG image with an alpha channel, and are applying a filter to it. Internet Explorer doesn't handle this correctly and draws the semi transparent pixels against a solid background instead of the actual background.
When this happens and how it appears exactly may vary from computer to computer, and even on the same computer in different situations. That's why some people experience it and some don't.