X3Photo Gallery Forums

Before I answer this in depth, please can you tell me, did you use the panel upload-resizer when uploading your images? Or do you resize your images yourself before upload? I want to exclude this factor, because it does not use the same resize-methods as the X3 internal resize-mechanism ... When resizing-on-upload, the images are in fact resized on the client through javascript.

Apart from the above factor, I can immediately tell you, X3 is not doing anything to your original images. The image that displays here https://www.stefanhagen-fotografie.de/c ... e_0019.jpg, is IDENTICAL to the same full size image that displays in the X3 popup window: https://www.stefanhagen-fotografie.de/? ... deine-0019. So this, which you refer to as "desaturated", must be the way you want them to display for the visitor. 

sHagen wrote:This is what I think happens:
The imagevue resizer gets active when the /render/ is in the path. The resizer throws away the exif data, so every browser shows the image in the standard/native color space.

I have never seen or heard this reported before, but once I know more, I can diagnose further.

sHagen wrote:One more thing...
I have noticed that "some" full size images are also resized using the imagevue renderer. What is the condition for this?

This is entirely logical, and something we spent a lot of time optimizing with X3. If your original image is 1600px (or larger), and the visitor is on a 1024px screen, then why load the original? X3 will load a 1024px version, which is often half the file-size and consumes much less memory. Of course, there are mobile devices also, which will wish to load smaller images also for the POPUP ... Add another factor: modern RETINA devices (mobiles), and also new laptops like macbook pro, which have "double pixel density", and will want to load larger (up to 2x) images. There are other factors also: landscape vs portrait ... If you are viewing from a desktop screen, it is obvious that you will be able to display a much larger LANDSCAPE image than you will for a PORTRAIT image ... The portrait image is limited to the height of your screen, and thus will be much smaller, and thus often served a resized image instead of original. All handled by X3, but I can't explain all the math logic to you here.

sHagen wrote:Does this happen when I check the "resize" option when uploading?

No. The upload resizer option simply resizes images on upload from the panel. You should never upload massive images to the web (say 3000px +), because 1) Filesize will be massive, 2) Will take too long to download for visitor, 3) consumes too much memory for browsers, and 4) web hosts will fail to create resized versions because. Thus, all uploaded originals should be within reasonable size 1280px - 2000px ... You should either do this locally prior to upload (if you are concerned about resize quality), or use the upload resize.

sHagen wrote:Usually I export a web-version, which is 2048x2048 max in width and height. Facebook plays best with that.

In imagevue I did *not* use the upload resizer.

Ok, but the images in your examples in the previous post were 1600px. So you resized locally, to 1600px, before uploading?

sHagen wrote: One further thing I noticed is that portrait size images are handled differently. Lets use these two images:

• https://www.stefanhagen-fotografie.de/c ... n_0003.jpg
• https://www.stefanhagen-fotografie.de/c ... n_0015.jpg

First of all, now we are speaking of some ENTIRELY different from the COLOR issue, but ok. I already explained the differences in aspects in my previous email, and was hoping to not go into detail. Ok, look at the portrait images on my macbook 13". As you can see, maximum height is 699 PX, and based on THAT aspect, the TARGET WIDTH for this image is 466px. X3 will round that number to 480px, and CORRECTLY load /render/w480-q90/1.index/LenaBertan_0003.jpg.


Lets take a look at the LANDSCAPE image. Also limited to 699px height, TARGET WIDTH is 1048px (YES more than twice the target width of the portrait image, because of the accumulation of factors SCREEN aspect and IMAGE aspect). Based on the target width, X3 will round that value to 1024px, and load /render/w1024-q90/1.index/LenaBertan_0015.jpg

sHagen wrote:My resolution here is 1920x1080.

OK, so let's do some quick math here: 1080px height, with perhaps 100px used by browser navigation and topbars, that leaves 980px available height. TARGET WIDTH for the portrait image therefore becomes 654px (980/1.5 = 654 ... see screenshot below). X3 will round this number UPWARDS to 800px, and load the image /render/w800-q90/1.index/LenaBertan_0003.jpg. Everything is correct.


For the landscape image, which is still limited by the height of your available browser area (approx 980px), TARGET WIDTH for the image would be 1470px (980 * 1.5 = 1470px, see screenshot below). Anything above 1280px will always be rounded to the ORIGINAL image, thus X3 will load the original un-resized image "content/1.index/LenaBertan_0015.jpg" ... Everything correct. Why X3 doesn't serve resized images around 1600px or higher? 1) Why should it? This should be the original "BIG" image. 2) Its pointless to start resizing images past this point. Your ORIGINAL images should be uploaded at the appropriate size to be considered LARGE (>1280px width). 3) MOST servers (if you are on shared hosting), simply don't have the capacity to resize images past some point around 1400px ... An error will be created on image output "memory exhausted".


So as you can see in the examples, the math is correct for image sizing. You must also understand, a portrait image with /w640-q90/ is BIGGER than a landscape image with /w800-q90/ ... (portrait w640: 640*1.5 = 640 x 960), (landscape w800: 800/1.5 = 533 x 800). So understanding this, in addition to the fact that your SCREEN itself supports MUCH larger landscape images than portrait images, YES you will often see portrait-images with a resize factor in the URL. It's all correct.

Nice  :thumbsup: It's late here, but I will read through all the info tomorrow. My knowledge of colorspaces could be improved.

Ehy guys, I've lost you ! :scream:

sHagen wrote:I've just checked my gallery again. On the Mac, everything looks just fine in all Browsers (Chrome/Firefox/Safari). So the issue is windows specific.

Did you try different browsers in Windows? Also Chrome? I would have through the issue to be browser-related ...

sHagen wrote:I don't know what X3 is doing to fix the issue for thumbnails, but right now I wish to be able to force X3 to display all pictures through the /render/ engine.

I don't think X3 is "fixing" anything for the resized images ... Instead, the resized images are simply not inheriting some very specific colorspace settings in your images, which some browsers support, while others don't.

• That is why the resized images look the same across ALL browsers/OS, as the color profile is probably dumped.
• That is why you see variations on your originals across browsers, because some browsers support your colorspace on the original image, while others do NOT.

sHagen wrote:Windows 7 -> MS IE: OK
Windows 7 -> Chrome: NOT OK
Windows 7 -> Firefox: NOT OK (after enabling the color management support in about:config: OK)

Actually, Chrome and Firefox are probably showing your original images correctly, while Explorer is NOT ... Explorer is probably showing the SAME colors as the resized version, simply because its ignoring colorspace.

Personally, I use an image-optimizer that strips ALL color profiles anyway. I am not sure why spend time on a specific colorspace, when you have no idea how that image will display on the visitors specific screen anyway ... certainly when browsers don't support the color profile.

You definitely should read what imageoptim has to say about it:
https://imageoptim.com/color-profiles.html

Device-dependent color

How “raw” RGB colors really look like depends on capabilities of the monitor they are viewed on. Some monitors display more saturated colors, some monitors are brighter, etc.

Color profiles are supposed to help even out the differences. When a profile is embedded in an image, it describes in exact physical terms how the colors are supposed to look like. Then, the software that displays the image — if it knows exact physical capabilities of the monitor — may adjust image colors to display according to the color profile.

That's the theory. In practice:

• The majority of typical consumer monitors have a color profile similar to the standard sRGB profile, and can't display any “better” profiles.
• Almost all images, especially on the Web, were designed to be displayed in the sRGB color profile. When displayed correctly, they look the same on a high-end “wide gamut” monitor as on an average sRGB monitor.
• Not all browsers and image viewers support color profiles correctly. While basic support has improved in recent years, there are still cases where it's buggy or misconfigured, so it can't be relied upon for anything fancy.

As a result, for most users, embedded color profiles provide no value. Even for the users of high-end monitors there's rarely any benefit, because most images don't contain extremely saturated colors that require a special profile.

However, the use of embedded color profiles has a substantial cost in file size — the profiles can balloon an image by over 100KB! For small images that may multiply their file size.

The solution

Convert images to the sRGB profile, but don't embed it
Save images in the sRGB profile with gamma 2.2, but don't embed any profile in the image. That's the most compatible and most efficient solution.

Software that supports color profiles will assume that images without an embedded profile are in the sRGB profile. Software that doesn't support color profiles will use monitor's profile, which is most likely to be sRGB as well.

Color profiles can be embedded only in PNG and JPEG. GIF images don't have any color correction capability. Stripping color metadata from PNG and JPEG makes their colors consistent with GIF as well as with colors in CSS/HTML.

Configuring software for accurate color

If you're using color-profile-aware software, make sure to configure it to work in the sRGB color space. In Photoshop use Convert to Profile… and choose sRGB IEC61966. When “Saving for Web” check the Convert to sRGB option.