NextGen Galleries Strip Color Profile Data

Hi again, and a reply to your other post.

A jpg file can contain colour profile information in up to three places. (1) The EXIF segment, (2) An Adobe EXIF copy segment, and (3) in a specific colour profile segment. In general, we would expect any use of Adobe software to maintain (1) and (2) identical, but it is easy to see that colour management by one piece of software can give a different result from another if they read the profile data from different places. That is additional to what may happen if the software finds no profile data at all, when it is supposed to assume sRGB but may do nothing.

The implementation of colour management by different browsers has evolved over the years and there are still definite differences between them. By and large, modern browsers will manage the conversion from AdobeRGB and ProPhotoRGB, but none will manage grayscale profiles, and they vary in handling images with no profile at all.

I have just checked a couple of my own image files as my source and as Nextgen loaded. There is a reservation because I always preprocess my image files using FastStone Viewer to be the size I want them shown in the NG Gallery, and I have NG set to not resize anything. Therefore NG may not process my images on upload the same way as for other users.

In Explorer my pre-upload images flag as being in sRGB as I would expect from my workflow. On analysis, they have an APP1-EXIF segment and an APP13-Adobe EXIF copy segment, but no specific profile segment. After upload to NG, the image files are identical in every respect: size and contents. Specifically, NG did not strip EXIF data or even minimise it. Some EXIF is always required in order to decode the image segment. What I cannot tell is what NG does to a jpg file if it does have to process it during upload eg, for display size.

I would say it is undesirable to load images in any profile other than sRGB. It is not what your own browser may do, the internet is viewed by everybody and it’s what another viewer’s browser may do. That is quite separate from the merits of other colour spaces for other purposes. There is a reason for using 16-bit data in ProPhotoRGB (or Lightroom Melissa) for editing. There is a reason for not doing that for web publishing.

To continue, I have run some tests uploading a large image and having it resized on arrival. The original large image included an APP2-ICCProfile segment as well as EXIF and Adobe-copy of EXIF.
When an image is resized after upload, the resizing library shuffles some of the segments and does remove any APP2-Profile segment. An APP2-Profile segment contains either a fairly brief reference to s standard profile such as sRGB or can contain a full profile if it is not standard eg, a printer profile. Removing the APP2-Profile segment still leaves any profile statement within the EXIF segment.
Given that a jpg processing library is used by NG, there may be little control over what the library does beyond resizing to new dimensions and selection of a saving quality.

https://www.dropbox.com/s/nmdjrmmjzr507zv/Screen%20Shot%202019-01-04%20at%2012.02.39%20PM.JPG?dl=0

I opened both images in photoshop and looked at both of the raw metadata. The NextGen gallery clearly strips the color profile form the image. When I opened the NExtGen version of the image, I get a warning in PS that there is no embedded profile, and that is confirmed in the raw data. The image in the NextGen is the same size as what was uploaded to my media library in WP.

If you want to view the two galleries and how they handle color, you can look here: https://www.bfrankphoto.com/?page_id=8192

The upper is the NextGen gallery, the lower is the built-in WP gallery. The warmer color in the WP gallery is correct. Since the color is different in the galleries within the same browser, I’m confident that it is not a browser issue, but a NextGen one.

I am not sure I can explain that any further. I don’t get ‘no profile’ when opening an image copied back from NG gallery (by FTP) after upload even though resizing an upload does strip an ICC Profile segment from the file. The EXIF colour space definitions remain.

If one of your images in NG really does have no colour space definition, then it is well known that browsers may not show the file the same as if sRGB is embedded.

You could try turning off any automatic resizing in NG options, and doing any required resizing before upload. That way, NG does not modify the image file at all.

I have run another test. As follows.
New image (Canon 750D, 6000x4000px) in AdobeRGB space. jpg file shows colour space in Explorer as ‘Uncalibrated’; Photoshop shows embedded AdobeRGB profile; Elements records AdobeRGB as the space; no APP2-ICC profile segment in the file, so the space is only recorded in EXIF. Hex-editor view of file shows that space is encoded ie, not written as ‘AdobeRGB’ in clear.
NG options set to resize 800×600 after upload. File uploaded and therefore resized. NG uses the GD image library for processing.
File viewed in gallery (Chrome browser) alongside colour managed view of original file. No colour shifts, saturation or density differences.
File recovered from gallery folder (FTP download).
Recovered file still has no APP2-ICC profile segment, so any space will be only in EXIF. Photoshop shows embedded AdobeRGB profile; Elements records AdobeRGB as the space.
I would conclude that the GD image library used by NG to resize images does not strip EXIF colour space data, nor does it change that data eg, by converting to sRGB. A jpg file which originated in AdobeRGB space remains in that space when stored in an NG gallery, and is colour managed by my browser when the result matches the original.

Overall, I would not agree with your assertion that NG strips colour space data.

This has been an interesting voyage of discovery.
The EXIF tag ‘Colour Space’ has only two valid hex values: 0001 = sRGB and FFFF = Uncalibrated. That explains why Explorer lists an AdobeRGB file as uncalibrated.
However, there are other colour reference tags in EXIF which are not needed if Colour Space = 0001, but presumably are if Colour Space = FFFF. I am guessing that these other tags allow interpretation as of eg, AdobeRGB or ProPhotoRGB.
The experiment reported above allowed an AdobeRGB file to be uploaded to NG, then be resized, and it still showed AdobeRGB when recovered by FTP. I have to assume that the GD library does not modify any of the colour space data although the exact details of that data are unclear.