I have a requirement to work with CMYK. Any recommendations for how we could pass fill color CMYK instead of RGB or HEX. I use the Konvajs library.
Example
HTML and therefore I assume (happy to be corrected) CSS and HTML5 canvas do not support CMYK. Certainly, it is unlikely to be supported cross-browser in any meaningful way natively. W3Schools provide some kind of JS based conversion library approach and there are undoubtedly others and the logic to do the conversion both ways is out there, for example here.
So you could achieve something with JS where you get the RGB equivalent and use that in the fill.
However, CMYK colors when converted to RGB do not tend to give like-for-like visual effect and if you are trying to do any kind of web-to-print you need to give careful consideration to how you intervene in the interpretation of CMYK to RGB so that your users accept what they see as the color they want.
Related
Before exporting my image to the web, I want to convert them to sRGB and then remove the sRGB profile from the image (to reduce it's size, as sRGB is the default profile to use if there is no embedded icc profile). I was thinking that there is only one sRGB icc profile, but I discovered there are many variants! For example on color.org, there is sRGB v4 (which is included in distribution of Imagemagick) and sRGB v2.
So with sRGB profile I need to choose the correct one to convert my picture for exporting to the web? Why are there so many different sRGB profiles. (https://ninedegreesbelow.com/photography/srgb-profile-comparison.html) ?
Technically, the accepted answer is a bit off
It may not matter much in this particular case. Nevertheless, as this page pops up prominently in searches, we probably should set things right, ya?:
There is just one sRGB
Incorrect. The original sRGB specification from the IEC discusses two flavors of sRGB, and later years saw the addition of a number of sRGB variants. BUT WAIT THERE'S MORE and I am going to discuss them below.
Most browsers recognize just ICC v2
Not Relevant. The OP said he is stripping the profiles, so it does not matter at all what version profile he uses. Not at all, as there will not be any profile to read!
sRGB has well defined ... "gamma"...
Not Really. The sRGB TRC encoding is specified with a piecewise tone response curve, which is not a "gamma" function, though the spec does permit EOTF using a gamma curve with a 2.2 exponent. Yes, even the spec has more than one transfer curve indicated.
AND: it is important to know that there is further variation in the various ICC profiles. More below.
...and it predates ICC,...
Incorrect. The ICC was formed in 1993, and sRGB was created in 1996. 1993 predates 1996. The ICC published the v4 spec in 2001 but that's irrelevant.
Answering the OP
I want to convert to sRGB & then remove the sRGB profile from the image
Okay, this is a common practice and has some advantages. Up to CSS3, sRGB is the default colorspace for web content, meaning that the specified page colors are relative to sRGB, and untagged images should be interpreted as sRGB, and therefore remain relative in color to the CSS colors chosen in your styles. This is probably the biggest factor in favor of using untagged sRGB images.
As it happens, some browsers that do read embedded profiles do NOT adjust the CSS colors to a given output intent. I.e. there are some cases where the image is adjusted, but the page colors are not.
Human color perception is endlessly fascinating (at least to me, LOL) and we have a feature we call "color constancy". The truth is, it is less important that the monitor emit exact, absolute color combinations.
It is more important that everything DISPLAYED on the monitor maintains the same consistent colors relative to each other (all the content on the monitor.) I.e., you design a page with a color scheme, and you want the image to maintain the same relative color distances to the page.
If your sRGB image has an embedded profile, then if the browser adjusts the image but not the page colors, the relative colors will shift. This is the behavior of many browsers. (One exception is MacOS Safari, which is color correct/color managed for everything.) CSS4 in the near future is going to add other color spaces, though sRGB is expected to remain the default.
So which sRGB profile [is] correct to convert my picture for the web? Why so many different sRGB profiles?
The answer here is... use your monitor profile.
Wait... WUT?
It is more important that your workspace is calibrated for sRGB and that your test browser uses/assumes sRGB for all colors on the page, both the CSS colors and the images.
As you are going to strip your profiles out of the images, using your monitor profile for your working space means your photo editor window needs to (and should) match the CSS colors in your browser windows. Then WYSIWYG. What you see is what you get, and with everything untagged, the relative colors should be consistent everywhere.
But what about wide gamut monitors? Yea, things may look more saturated on them, but again, color constancy effect. You want all the colors between your images and your CSS styles to remain relative.
Under No Management...
Did you know that when you watch TV, there is no color management? Programs are color corrected on calibrated systems in studios, adjusting the look in a "WYSIWYG" environment, and then streamed out to the world with no color management.
When you design a webpage, your CSS colors are not color-managed in most user's browsers, and if your image colors are also not managed, then they should remain the most consistent as a total page of content.
But this does require that you set up your work environment for consistency, and also test your content on several different browsers on several kinds of devices.
But what if you still want a color managed working space...
Fair enough. Then you want your final working space to be your delivery space, sRGB. The profile I like for a TRC encoded working space is sRGB-elle-V4-srgbtrc.icc
When I say "final working space" what I mean is, if you are prepping images for multiple destinations, some web, some print, etc, then you might be needing to work in a larger space for the main image editing (such as ProPhoto, Rec2020, or ACES, etc — and importantly, at a higher bit depths, as in 16bit or 32bit float).
From your larger space, the print images get converted to CMYK, and the web images get converted to sRGB using sRGB-elle-V4-srgbtrc.icc. Then do some final adjustments if needed, and output to 8bit with no embedded profile.
Final Thought
Reading the above, you might think I didn't appreciate color managed workspaces, but I definitely do. I use color management most of the time. But if your destination is a non-color-managed environment with a defined standard colorspace, then it is more important to be in a calibrated version of that colorspace.
Best of luck!
ICCv4 is better if it does use parametric curve encoding. Profiles from ICC even in v4 do not use that. ICCv2 (does not support para) will only use 1024 1DLUT that does have linear part but still worse than para curve. Use this: https://github.com/saucecontrol/Compact-ICC-Profiles/issues/6
https://github.com/saucecontrol/Compact-ICC-Profiles/blob/master/profiles/sRGB-v4.icc?raw=true
There is just one sRGB. The version you see, it is the version of ICC. The version of the standard not of the profile. Most browsers recognize just ICC v2, only on last period they start to support ICC v4, but not yet complete implementation.
sRGB has well defined chromacities and "gamma", and it predates ICC, so both versions can support well sRGB.
Assuming that the SVG is the standard for still vector images, there is an equivalent for animated vector-based images too ?
The problem I'm trying to solve can't be solved by pixel-based formats such as APNG or GIF, they don't scale at all on different displays, and they also get really really heavy pretty quick, vector images are what I need but I need a standard way to provide a file with an animated vector entities in it.
To be clear I'm not trying to animate a webpage or part of it, I'm asking for a filetype or standard that is good for just this task.
You can animate SVG graphics... they don't have to be static. That said, SVG is the only vector graphics format the web supports (natively) so I guess the answer is SVG! ;-)
The SVG specification includes SMIL as an animation mechanism. IE9/10/11 do not support SMIL, although other UAs do. There's a javascript library called fakesmile that can enable SMIL on UAs for which support is lacking.
There's also CSS animations which IE does support, although overall support for CSS animations is somewhat less complete in most UAs.
I heard that only premultiplied alpha is needed when doing layer blending etc. How do I know if my original image is premultiplied alpha?
You can't.
The only thing that you can check is if it's not premultiplied. To do it go over all the pixels and see if there is a color-value that has a higher value than the alpha would permit if(max(col.r,col.g,col.b) > 255*alpha)//not premul. Any other cases are ambiguous and could or could not be premultiplied. Your best guess is probably to assume that they aren't as that's the case for most PNGs.
Edit: actually, not even the code that I posted would work as there are a lot of PNGs out there with white matte, so the image would have to include parts that have an alpha of 0 to determine the matte color first.
Android Bitmap stores images loaded from PNG with premultiplied alpha. You can't get non-premultiplied original colours from it in usual way.
In order to load images without RGB channels being premultiplied I have to use 3rd party PNGDecoder from here: http://twl.l33tlabs.org/#downloads
How to convert HSV color directly to CMYK color?
Bonus points for mentioning JavaScript library that does that.
I've seen only solutions that convert HSV to RGB and then RGB to CMYK.
The only solution I'm aware of is to convert to RGB as a middle tier and then convert it out to the format you want (CMYK->RGB->HSV Or HSV->RGB->CMYK) like you mentioned. I'm not sure if it's something to do with the math or another reason entirely but here is a library from the web tool kit that will at least let you get the conversion done.
A little more reading on my part turned up this:
HSL and HSV are defined purely with
reference to some RGB space, they are
not absolute color spaces: to specify
a color precisely requires reporting
not only HSL or HSV values, but also
the characteristics of the RGB space
they are based on, including the gamma
correction in use.
Source
Essentially from what I can gather HSV and HSL can't be directly converted because they're not absolute colour spaces as they need elements of RGB space that they are based upon to be meaningful. Now I'm not a color expert but I would venture that this could be why you can't directly convert between HSV and CMYK and I would assume that this is the process that goes on under the covers of conversion engines (like the web based ones) that seem to convert directly.
I noticed when I saved my menu background image from jpg to gif that gif takes almost one fourth of the size that jpg does.
jpg = 25kb
gif = 7kb
Is there any downsides to using gif?
Its GIF 256 colors BTW. NOT interlaced. Not transparent.
Just want to be sure!
Thanks
If you're not using it for interlacing and transparency, the only real upside would be the compressed file size.
However, you may want to look into using the PNG format. You can find an overview of the three file types here (Surrey University)
Over the past 5 years, PNG has been phased in to the web image standards, developers and designers always knew it handled compression better, but it wasn't fully supported by all browsers - causing it to be overlooked until said browsers were upgraded.
Nowadays, PNG is pretty much the most commonly used file format for images on modern websites.
There are no downsides to this as long as the graphics look good.
For menus and line drawings - in general, any mages with large homogeneous areas, i.e. many adjacent Pixels with the same color -, GIF (or PNG, note musicinmybrain's comment below) is usual the best choice as it compresses stronger, and the results look better (especially because of sharper edges).
For heterogeneous images like photos, GIFalmost always loses in both size, and quality, and JPEG is the better choice.
GIF it's not designed for photographic material, so a big photo comes out better and smaller in JPEG, but tt's probably more than apt for interface elements such as buttons, dividers, borders, etc.
The only caveat that comes to mind are gradients: even on a small area and with 256 colors, GIF will likely show visible banding. This is often very subtle and not a big issue, but you may want to check it, especially if you have lots of gradients and/or hate banding.
I'd second what Daniel May is saying about using the PNG format.
Although if you are solely concerned with image size and don't have a specific reason for using GIF remember that you can tweak the quality of a JPG file to turn a 25kb JPG into a 7kb JPG!
As you say the gif can only handle 256 colors, if you don't need more then that gif will be a good choice.
I would recommend gif over png because there are some issues with color profiles in webbrowsers and pngs. You might end up with png colors not matching the css color.
A few people have mentioned the PNG format. Its worth mentioning there are two different types of PNGs, 8-bit and 24-bit. Both types support transparent pixels, however the 24-bit variant supports alpha transparency.
Generally 8-bit PNGS will be slightly smaller than their GIF equivalents. However large 24-bit PNGs have quite large filesizes if they use alpha-transparencies.
It really all comes down to what is the right format for the image. Some will compress/display better in different formats than others. I wouldn’t try and use one single format, such as GIF for all images and pictures on a website (the original question) unless the images were all IU related.
You really need to understand a little about how these different formats work, rather than choosing one over the other. There is a very good article on the pros & cons of gif/jpg/png formats here:
http://www.websitetemplatedesign.com/oscommerce_tutorials/printer_136.shtml
As far as I am aware, if the image quality looks acceptable then go for the smallest image format you can find. You might find you save even more size using PNG.
To answer your question: NO. It's perfectly acceptable to use GIF files over JPEGs. Each format has its own pros and cons.
You can read about them here: PNG vs. GIF vs. JPEG vs. SVG - When best to use?