How to preserve colorspace? #5445
Replies: 7 comments 29 replies
-
|
See A Word About Color Spaces at https://imagemagick.org/script/formats.php where it says that HDR only supports linear RGB. May not be relevant if your Rec2020 color space is linear RGB or it could be an oversight. But you would be better assigning profiles for it rather than rely upon it being copied as such. See the list of colorspaces at https://imagemagick.org/script/command-line-options.php#colorspace. I do not see Rec2020. So it likely is not supported and is subsituted with RGB. However, you could request an enhancement for it. But again a profile may be better. The IM developers will need to comment further about this |
Beta Was this translation helpful? Give feedback.
-
|
Just a shortcut for what you should get from
in order to see what profile is imbedded. |
Beta Was this translation helpful? Give feedback.
-
When I use the following (with the good ICC profile I extracted), the result is an HDR file which opens showing as sRGB in Photoshop: If I put a typo in the ICC name, it throws an error. So it seems like it is trying to use the profile, but not producing the expected result. |
Beta Was this translation helpful? Give feedback.
-
|
Is that sRGB the profile or the color mode in PS? The color settings shows the default, not the actual imbedded profile, I believe. So where did you see sRGB.icc as the imbedded profile in PS? See what EXIFTOOL says for the profile for you file? |
Beta Was this translation helpful? Give feedback.
-
Shows as REC2020 GAMMA2.2 (Linear RGB Profile) from my 32-bit TIF, same as I see in PS
|
Beta Was this translation helpful? Give feedback.
-
When I mentioned sRGB, I meant ImageMagick reporting "Colorspace: sRGB". In Photoshop, sRGB is just a profile. If you use the default PS profile, it means sRGB IEC61966-2.1, but there are of source other versions of sRGB. But any way you look at it, it would be a specific color model without ambiguity when the profile is embedded, which is the case with my test image. In Photoshop, when you refer to the color model, that's part of the image "mode". Any RGB profile would use the image mode. But a specific color profile (whichever flavor of sRGB this is) would include details on the primaries, gamma, etc that are more detailed than the mode. sRGB would never be a reference to the generic mode (Rec2020 is used in the RGB mode but it is not related to the sRGB profile) So "Colorspace: sRGB" jumps out at me because it's definitely a reference to a color space (albeit ambiguous in the details of which sRGB if you really dig into it) and is definitely not the color space of the source image (which was the linearized Rec2020 that Photoshop created automatically from my Rec2020 gamma2.2 color space, which came from an ICC profile from Eizo). |
Beta Was this translation helpful? Give feedback.
-
|
Regarding colorspaces and profiles: IM has those two methods for defining in metdata what pixels values mean, and converting pixel values from one meaning to another. Two systems is not better than one, but they came about in the long evolution of IM. We are where we are. Most "colorspaces" are really colour models, such as XYZ, YIQ, HCL and so on. But some such as Adobe98, RGB, sRGB are real colorspaces, in the sense that they have colorimeric definitions. IM does some limited automatic conversion between colorspaces, for example, IM knows that CMYK data can't be stored in PNG files, so will automatically convert it to sRGB first. But most operations are purely numeric. For example, we might subract an sRGB image from a HCL image, to get a (probably) meaningless result. Near the top of verbose info we have: That refers to the "-colorspace" setting. It has no connection to any embedded profile. IM has no "colorspace unknown" setting. Unless it knows otherwise, it assumes the colorspace is sRGB. For example, we might convert to a XYZ profile, and the "colorspace" setting will still claim the image is sRGB. If we want, we might "-set colorspace XYZ". |
Beta Was this translation helpful? Give feedback.
-
|
Any idea what would need to be done for the command above to convert from the 32-bit TIF to an HDR file which does not alter the embedded color space or the actual pixels? The shift I see is substantial. |
Beta Was this translation helpful? Give feedback.
-
|
Did you try to add the profile as I suggested above.? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, our exchange got a bit complicated. My reply above is #5445 (reply in thread) The extracted profile is good, running the command executes without out, but the resulting HDR file does not have the requested profile. I just tried again and this command generates an HDR without using the requested external ICC profile I had extracted: |
Beta Was this translation helpful? Give feedback.
-
|
But do you not have the previously extracted profile on your system in the working directory? If so, it will be used. If not, the output may be generated but without the profile. Did you check the HDR to see if it had that profile embedded? |
Beta Was this translation helpful? Give feedback.
-
|
I'm using the correct path. When I try to use a bad path, I can confirm via an error message such as: When I use the correct path and generate an HDR, inspecting that file with Magick lists not profile in the HDR However, it now appears to me that the HDR format does not support an embedded profile (must use some standard). If I change the profile in PS and save as an HDR, that new file from PS won't show a profile through Magick and will reopen in PS with the generic sRGB profile listed - not the one I converted to in PS. |
Beta Was this translation helpful? Give feedback.
-
|
ImageMagick should probably show a warning or error when requesting a profile for an HDR file, to indicate that it is not a valid option. |
Beta Was this translation helpful? Give feedback.
-
|
I'm trying to find some format I can send to and back in order to confirm preservation of the data, but having no luck. If I send to JXL and back, the result shows significant loss of color (looks like clipping to sRGB gamut). The over-range HDR values are close enough but also changed during the round trip to JXL and back to 32-bit TIF. If I try to send to PSD or PSB (which are nice because they perfectly preserve the data in Photoshop, including the profile), ImageMagick is converting my 32-bit source to 16-bits when using the following commands: |
Beta Was this translation helpful? Give feedback.
-
|
You say you are using "7.1.0-45 Q16-HDRI x64".
If your source is 32-bit integer, then IM will rescale the values in memory to 16-bit integer.
IM doesn't request a profile for any particular file format. Perhaps what you mean is "When writing an image with embedded profile to HDR format, IM should warn that the profile won't be written." Well, perhaps, but most file formats do not record all the metadata that IM has about an image. If IM warned about metadata that would not be written, IM would become very complex, and people would complain about the large number of messages. |
Beta Was this translation helpful? Give feedback.
-
|
Shouldn't it preserve the 32-bit data or warn the user? It isn't something which preserves image quality like a conversion from 32-bit integer to 16-bit floating point. The resulting 16-bit PSB/PSD file is significantly degraded. Good points on complexity for the interface, I wouldn't expect warnings for many conversion scenarios. However in this case it is an explicit request which is being ignored. Shouldn't there be a warning when the user is requested a feature flag (or combination of flags) which is invalid? |
Beta Was this translation helpful? Give feedback.
-
|
can you post a small example 32-bit tiff that you want to convert. Photoshop may rescale the values to the range 0 to 1, which when brought back to IM may still be in that range rather than 0 to 32-bit range. A rescale may be needed. |
Beta Was this translation helpful? Give feedback.
-
|
When I run the instructions below starting from the attached source (smallHdrTest.tif), the round trip files are significantly different.
Source image (and my conversions): https://drive.google.com/drive/folders/1DPqOc6nviGzOq-39T0lx2LvgRDWuGGTy?usp=sharing If you open the TIF files in PS and use the 32-bit color picker, you can see the data clearly. To visualize the HDR data on any monitor, try the 32-bit exposure slider or add an exposure adjustment layer with -3 exposure. Or if you have a true HDR monitor, MacOS, and the latest PS (v23.4.2), go to PS prefs / tech previews, enable the HDR option and restart PS and then open the image. |
Beta Was this translation helpful? Give feedback.
-
|
Do JXL and AVIF support 32-bits and moreover does Imagemagick support that in those formats? I do not know. One of the IM developers will need to answer. Have you checked those format's documentation? |
Beta Was this translation helpful? Give feedback.
-
|
The JXL and AVIF format specifications support HDR content (though I don't recall if they are encoded at 32-bits or use a different encoding at a lower bit-depth to approximate the same data). Not clear on ImageMagick's support, that's what I'm trying to learn here. |
Beta Was this translation helpful? Give feedback.
-
What explicit request is being ignored? In your command ... ... the input file is read into memory. Then if the image has an embedded profile it is converted to a new profile, otherwise the profile is assigned to the image. Then the image is written to a file. These operations all succeed. No request is ignored.
Wikipedia suggests the defining document is https://floyd.lbl.gov/radiance/refer/filefmts.pdf , which describes the "Picture File Format", which has no facility to record ICC colour profiles. Each pixel is recorded with a total of 4 bytes (32 bits). It says:
I would regard an accuracy of 1% as totally horrid. It is similar to 8-bit integer. Okay, HDR format has a wider dynamic range, but at great cost. |
Beta Was this translation helpful? Give feedback.
-
My ultimate goal here is to get a conversion from a 32-bit TIF to an HDR image which can be viewed in a web browser. I don't plan to use the HDR format but had tried it merely as a way to test conversions I could review in Photoshop to see if I was at least getting to and from another 32-bit format without loss of data (since I'm new to ImageMagick, not confident with it, and have seen loss of quality with all my tests so far using JXL or AVIF). Given what I've learned and limits around color, HDR is not a file format I need to explore further. What I'd really like to do is generate valid JXL or AVIF files with HDR content, as those are compact file formats which support HDR in theory. Browser support for HDR content isn't something I've found documented anywhere. I know that FireFox and Chrome support HDR video and they support these file formats, but I do not know if they support HDR versions of these image formats. Chrome support appears to be ahead of FireFox. So far I'm not seeing any HDR values in Chrome when viewing JXL or AVIF files in Chrome. My hypothesis is that Chrome is not supporting HDR content for JXL as I seem to be getting to and from JXL with HDR data in the round-tripped TIF. I don't know on AVIF as it does not look like I am getting HDR in the AVIF based on the round-tripped TIF - but I have been told that Chrome will support HDR content from AVIF (I just haven't found a test image or been able to create my own to confirm - let alone find a way to convert images to a format if it is supported in Chrome). |
Beta Was this translation helpful? Give feedback.
-
Okay, I see what you mean. IM performs each operation separately. An image can be assigned or converted to an ICC profile, and the profile is embedded. An image (with or without an embedded ICC profile) can be saved to a file. If the file format doesn't support ICC profiles, then any embedded profiles won't be saved in the file. The same applies to other metadata; not all file formats can record all metadata. These are separate operations. When an image with embedded profile is saved to a file, IM doesn't know or care if the profile was embedded earlier in the same command, or in a previous IM command, or by a camera, or whatever. |
Beta Was this translation helpful? Give feedback.
-
|
@snibgo Thank you for that explanation, makes sense. Ultimately, I think the ideal solution for HDR processing will be to have support for JPG / AVIF gain maps with standard profiles (which in the case of an AVIF HDR base image includes PQ / HLG EOTF with common primaries, probably encoded as CICP rather than an ICC profile). At this point, those gain map formats are much more relevant than 32-bit TIF for tools intended primarily to support online sharing of images (I would not use 32-bit input or output with ImageMagick now, re-processing of an existing gain map is more relevant now to provide much better adaptation to displays of different capabilities). Request for gain map support: #6377 |
Beta Was this translation helpful? Give feedback.
-
|
@gregbenz Pardon my ignorance, but why is an ICC profile not adequate and what are PQ / HLG EOTF these files and how are they used. |
Beta Was this translation helpful? Give feedback.
-
|
@fmw42 32-bit implies HDR (with linear encoding). There is currently no ICC standard for HDR and to the extent you can work around that in ICC (or embed CICP into an ICC profile), you'd have a niche profile that won't be well supported by browsers. PQ and HLG are common EOTFs designed for HDR (you'd typically think of "gamma" for SDR images). This is part of a profile to describe how an image is encoded (a complete profile also needs to specify things like the color primaries, ie P3, sRGB, etc). |
Beta Was this translation helpful? Give feedback.
-
|
Thanks |
Beta Was this translation helpful? Give feedback.
-
|
FWIW, the ICC has had an active working group looking into HDR for quite some time. Let's hope for movement soon. |
Beta Was this translation helpful? Give feedback.
-
I'm doing some testing with a 32-bit TIF image with an embedded Rec2020 colorspace. When I convert my image using the commands below to create a JXL and then bring it back to TIF, the image has been significantly degraded. I'm doing a double conversion to help confirm that things are working properly, as well as to test some image formats which I cannot validate in Photoshop (ie, if it comes back the same then I know the export is good even if I cannot view it currently).
What I see is that "converted.hdr" has changed from my Rec2020 embedded color space to an sRGB colorspace. It does show HDR data, but with substantial loss of data (very crude highlights and other tonal shifts).
The "reversedToConfirm.tif" is further degraded and has no embedded profile at all.
What commands should be used to keep the exact same colorspace and pixels when converting from HDR to TIF and back?
Note: I am using ImageMagick 7.1.0-45 Q16-HDRI x64 e32676e:20220731
Beta Was this translation helpful? Give feedback.
All reactions