mbsharp

Yes, you can collect all the galleries and their images using FTP. They are in wp-content/gallery

Personally, I assemble all my gallery images locally before I upload them, so I have them anyway.

seems to be fixed in version 3.1.5
Note that ransom selections for a widget are cached for some time

seems to be fixed in version 3.1.5

Seems to be fixed in version 3.1.5

Seems to be fixed in version 3.1.5

Try version 3.1.5 now. Seems to have fixed random selections

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.

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.

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.

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.

There is a limit unless you turn off automatic resizing in ‘Other Options’ > Image Options.
The question would be why you want to upload images which must be much larger than any likely viewing area.

I would ignore that complaint. jpg files are going to be around for a while.

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.

Image files carry a rotation flag, which is then used during display to orientate the image. An external editor will adjust that flag if you rotate the image. Possibly the flag was not modified when you rotated your images before.

I am not sure which gallery (upper v lower) is which on your page. I would agree that there is a colour shift. This is most clearly seen in the macaw and in the foreground hand of the Perry image. One gallery is shifted more to red and less to blue than the other. That’s not going to be detectable in an essentially blue image like the balloons.

Browsers are renowned for colour shifts even if they say they are colour managed. All images put on the web should be in sRGB colour space and never in AdobeRGB or ProPhotoRGB. In theory, images with NO colour space should be interpreted as sRGB but that is where browsers tend to mess up.

I guess the question is whether either WP gallery or NextGen gallery is stripping the EXIF data and hence the colour space information. The only way to tell would be to save and examine an image being viewed in your browser, but at the moment all the images are protected from saving.

There are websites available to test your browser’s colour awareness. You might do that.