I am looking at the top comment on this page:
https://www.php.net/manual/en/imagick.setimagecolorspace.php
It has sample code for converting a CMYK image to RGB. However, there are two things I do not understand:
It uses the profileImage function twice. Once to set the profile to CMYK if the image does not currently have a profile. The second use of the function adds the RGB profile to the image. Apparently, this means that the image now has at least two image profiles attached to it.
Question 1: Why would you want the image to have both a CMYK profile and an RGB profile? What exactly is being done here? How exactly does adding a second profile convert the image from CMYK to RGB?
The very last line in the code is using the stripImage function which removes the profiles completely along with other things such as EXIF data.
Question 2: Why are we removing the profiles? Doesn't that undo everything that we just did?
If the input image is CMYK and does not have a profile, then you can convert it two ways. The first is to simply use -colorspace sRGB. But that is not so accurate. A better way is to use two profiles. The first defines the input colorspace as CMYK and gives it a precise definition of its gamut and the second specifies it wants to convert to sRGB. There are a number of CMYK type profiles that can be used. Without more knowledge, I prefer USWebCoatedSWOP.icc. Likewise there are several sRGB profiles. See http://www.color.org/srgbprofiles.xalter and https://github.com/ellelstone/elles_icc_profiles/tree/master/profiles for profiles.
Related
I'm using Imagemagick to resize large images (jpgs, pngs and tiffs) and convert to jpg for use in the browser.
I use -strip to remove all unnecessary information and keep my images nice and clean.
But in the process I'm removing colour profiles. This is really noticeable when it's an AdobeRGB 1998 image as it becomes really flat.
Is there a way to strip everything unnecessary except for the colour profile? Lots of people have asked this on forums before but I've never seen a solid answer.
OP here, answering my own question for anyone who needs it in the future:
I've swapped -resize for -thumbnail and have removed -strip. All seems good.
-thumbnail strips the exif data, but leaves the colour profile intact.
It sounds like it's just for making small images, but you specify dimensions in exactly the same way as with -resize so it's appropriate for any size of image.
I've had this live for about three weeks without problems so far, so happy to say this is a solid solution.
I wanted to batch-convert some JPG images to PNG, so I used the following ImageMagick command:
convert before.jpg after.png
However, things didn't go as smooth as I planned. See two images below - first is before.jpg, second is after.png:
You can see that the second one is quite darker than the original.
I'm using ImageMagick 6.9.9-19.
Opening JPEG image in GIMP and exporting it as PNG gives expected result - output image is identical to original.
What am I doing wrong?
Edit: re-saving after.png with GIMP also makes the image identical to original.
Edit: even after I saved after.png with GIMP, re-converting with ImageMagick breaks colors again (convert after-gimp.png after-gimp-and-im.png).
Edit: converting to sRGB or CMYK TIFF, or even again to JPG, does not give this problem. However, I still need PNG.
The two images you posted are identical according to IM 6.9.9.20 Q16 Mac OSX compare -metric rmse GBooF.jpg geDxn.png null: Which produces: 0 (0). It is possible your viewers may display jpg and png differently, since neither have an sRGB profile. Though, png is usually assumed to be sRGB.
Also my viewer shows both of your images as the same --- no difference, in your post on Mac Safari and using Mac Preview.
Try adding an sRGB profile to your jpg. Then convert.
convert GBooF.jpg -profile path2/sRGB.icc GBooF2.jpg
convert GBooF2.jpg GBooF2.png
See if those view the same.
Some related questions around Display P3 (wide gamut) image handing:
Is there a file name convention for wide gamut images, like there was for retina (#2x, #3x)?
Is there a way to add wide gamut versions to xcassets?
If we have have sRGB MyPic.png in our Xcode project, how do we use UIImage to load a P3 version?
Or...
Should we simply replace our sRGB images with Display P3 images, and let older sRGB-based devices do their best to display them?
The answers, from Apple, are here: https://developer.apple.com/videos/play/wwdc2016/712/ with PDF here: http://devstreaming.apple.com/videos/wwdc/2016/712ugi7vg8jznn3pc3u/712/712_working_with_wide_color.pdf
Some notes:
Photoshop:
Use Convert to Profile to convert to Display P3 profile
Don't use Assign Profile
Save for Web doesn't work with wide color.
Use Save As -> PNG from 16-bit source doc
Export assets as 16bit PNG files with embedded “Display P3” ICC profile
Xcode:
16-bit PNGs can be dragged into XCAssets.
Xcode will auto-generate the 8-bit sRGB derivative (or you can supply it yourself)
UIImage will automatically load the correct image for your device's display.
App Slicing will cause only the correct images to be included in your app when downloading to a device.
Way more info in that WWDC session.
Naming:
There's no standard I could find, though Webkit's page of examples uses "-P3", e.g. "MyPic-P3.png". This'd be a useful convention if you want both types of file on a server.
Guys i have 2 images one with CMYK color model and other with sRGB.. I would like to find out which color model is better to use while dealing with image processing like resizing, cropping, color filling etc..
Thanks in advance guys.. !
CMYK color space is used for print, (s)RGB is used for screens (web, monitors, tvs etc). If one were to open a CMYK document in a viewer/program that doesn't support the color profile (which is not uncommon, since CMYK isn't as widely supported as RBG) the colors would appear to be extremely over-saturated. If you are altering the images for use on the web, or in an application, I would highly recommend that you use some variant of RGB.
In short, neither is really better than the other in general, it all depends on where you will be using the images (apples and oranges, comes to mind). CMYK is better for print, and (s)RGB is better for screens.
UPDATE in response to OP's comment:
Just to be clear (forgive me if you already know this) color space/profiles do not affect the resolution of an image, they only affect how the colors are handled/encoded. Resolution is only affected by file dimensions, DPI/PPI (dots/pixels per inch) and compression.
UPDATE 2 in response to OP's comment:
I'm not familiar with "Imagemagick", but in general, I can tell you that I've converted thousands of documents to RGB from CMYK (and vise versa) and never noticed any degradation in quality, when the file is viewed in a program that supports the color profile. The only exception is when converting to CMYK FROM RGB, it is possible to lose a wee bit of vibrancy (due to the fact that CMYK is a smaller color space. Like I said before, if by "quality" you mean "resolution" the color profile won't effect it, the image won't suddenly lose clarity, when switching color profiles. Let me know if you have any other questions.
Neither is "better" for these purposes. In general you should use the color space/model that best aligns with your output device, like CMYK for paper and sRGB for screen, but for manipulations (such as resize, crop) they are the same.
the best is sRGB because is larger and the color are better preserved. AdobeRGB is even better. But remember that if you want to distribute you graphic image you have to know what kind of device will be used to print/view. You may use also a AdobeRGB but when you print it, you'll be sad, because many colors of AdobeRGB cannot be seen on a paper.
Cheers
For a dynamic imaging application I'm building, I have to take an image created by a rendering package and place it in an InDesign file. Because it needs to be CMYK with transparency, TIFF is the only possible format to use. The difficulty I'm having is that the renderer is generating an image with an unassociated alpha channel, which InDesign seems to have trouble understanding.
I'm working with the renderer manufacturer to see if they can change their output format, but in the mean time I would like to find some automated workflow to convert a CMYK TIFF with unassociated alpha to have associated (premultiplied) alpha.
I tried using GraphicsMagick's command-line tool (which would be easily scriptable), but the closest I could get simply forced the TIFF flag to get written as premultiplied--it didn't actually perform the premultiplication. The effect is a working alpha but with washed out color:
gm -convert <infile> -define tiff:alpha=associated <outfile>
Does anybody have other suggestions on how to achieve this conversion? My primary requirement is that it needs to be automatable in a Linux server environment, ideally via either scripting or a PHP library (since that's already being used elsewhere in the workflow), but I'm flexible on the PHP bit.
Edit:
For reference here are the two files (42MB each):
Original TIFF with unassociated alpha
Modified TIFF from GM with pseudo-associated alpha and washed out color