Jump to content
You must now use your email address to sign in [click for more info] ×

Panorama-Color-Issue: still there...


Recommended Posts

Hi,

some time ago I reported a color issue with panorama-stitching.
(https://forum.affinity.serif.com/index.php?/topic/96399-color-issue-with-panoramas/&tab=comments#comment-518723)

Back then I was satisfied with the answer, that my screen can not handle the working-profile (ROMM-RGB) properly.

By now I own a 10-bit Display but the issue is still there:

I use several standard JPGs to make a panorama.
Individually each of the JPGs is displayed properly  (keep an eye on the sky-color..)

1029783939_2020-05-2012_02_24-AffinityPhoto(Klein).png.4b5cebcd1d1e66b66cf716b14d24b5f0.png

 

Even the Panorama-Preview looks good:

1519992960_2020-05-2012_03_13-AffinityPhoto.png.a82417c97b473bddf2939cd095663021.png

 

Also the Stitching and Rendering looks good:

558536402_2020-05-2012_03_29-AffinityPhoto(Klein).png.0670af71ef5531825bae6f627c31cc25.png

 

But in the very last step of the process the colors change and the final image looks like this:

1370315803_2020-05-2012_03_37-AffinityPhoto(Klein).png.2bd17933c5453035b37e5d5c27614aa4.png

 

Please don´t tell me again that it´s the calibration, the gamut, the screen etc...

I use images that are each displayed correctly.
Therefore I expect the panorama also to be fine - but it´s not.

In my old posting (mentioned in the beginning) it was a Nikon P7800 (JPGs), this time its a Smartphone (Xiaomi Mi A1 - JPGs)
= the issue is not related to the camera.

Thanks in advance for fixing this issue.

kind regards
Fritz

Link to comment
Share on other sites

  • Staff

Hi @Fritz_H, the issue is not related to a 10-bit panel, wide gamut display, anything like that. I simply think it's your colour preferences and how your workspace colour settings are configured.

I appreciate you want to work in ROMM RGB for more intense colours, but because you have changed the default colour profile (rather than changing it on a per-image basis whenever you develop a RAW file), you must take into consideration how this affects all imagery you bring into Affinity Photo.

Normally, with panorama stitching, the colour profile will be inferred from the images you provide during the stitching process. For example, if you are stitching JPEGs tagged with Adobe RGB, the final panorama document will be in Adobe RGB. This is true, even if your default RGB Colour Profile in Preferences>Colour is different.

However, there are circumstances when your RGB Colour Profile choice will be used: if the images do not contain any colour profile tagging (you will typically receive a message in the top right explaining your image has been assigned a colour space), or if you have explicitly enabled Convert opened files to working space in Preferences>Colour.

The only way I could reproduce your issue with panorama stitching is by going to Preferences>Colour and enabling the Convert opened files to working space option—could you check your own preferences? If that option is enabled, disable it, then see if your colours are correct. Note that it is disabled by default, so at some point I suspect you may have manually enabled it?

Hopefully that will solve your issue. However, do be aware that I'm unsure as to whether your Xiaomi smartphone JPEGs are intended to be in sRGB or a wider colour space—similar to iPhones and how their images are tagged with Display P3. If you open a single JPEG image, what does the colour profile entry read in the top left?

Product Expert (Affinity Photo) & Product Expert Team Leader

@JamesR_Affinity for tutorial sneak peeks and more
Official Affinity Photo tutorials

Link to comment
Share on other sites

First of all: I am honored that "Professor, Dr. Mr. Photo himself" Ritson answered my question :-)

"...
you must take into consideration how this affects all imagery you bring into Affinity Photo."
OK, .... so why is there no visible color-shift when opening the images individually?
To me that means: the images are converted from sRGB (Xiaomi) to my working profile (ROMM RGB) without noticeable issues.

"...Convert opened files to working space option—could you check your own preferences?"
done; as expected you are right. Changed that option: issue gone.

"If you open a single JPEG image, what does the colour profile entry read in the top left?"
the Metadata-Panel shows sRGB, top-left info too.  (after having changed the settings as you suggested)

image.png.09fccc3780f96514c14e2171f9981dba.png  image.png.a135af0064adce63d345ba403334758d.png
 

My thinking was/is:
ROMM RGB offers more colors. OK.
That feature is needed for HDR etc. and may also be useful when working with panoramas since the stitching will merge
multiple sources, each contributing its own range of used colors (depending on the contents of the picture..) into one final image.

Therefore my guessing is:  having a wider range of colors "available" may prevent losing color-information.

(Before you answer: I know: such detailed thoughts on one hand and using a cheap smartphone on the other does not match: true.
Usually I do not use a smartphone to take pictures, but it was a lucky situation to see this location with hardly any people around (#Corona)...)


kind regards
Fritz

Link to comment
Share on other sites

3 hours ago, Fritz_H said:

First of all: I am honored that "Professor, Dr. Mr. Photo himself" Ritson answered my question 🙂

"...
you must take into consideration how this affects all imagery you bring into Affinity Photo."
OK, .... so why is there no visible color-shift when opening the images individually?
To me that means: the images are converted from sRGB (Xiaomi) to my working profile (ROMM RGB) without noticeable issues.

"...Convert opened files to working space option—could you check your own preferences?"
done; as expected you are right. Changed that option: issue gone.

"If you open a single JPEG image, what does the colour profile entry read in the top left?"
the Metadata-Panel shows sRGB, top-left info too.  (after having changed the settings as you suggested)

image.png.09fccc3780f96514c14e2171f9981dba.png  image.png.a135af0064adce63d345ba403334758d.png
 

My thinking was/is:
ROMM RGB offers more colors. OK.
That feature is needed for HDR etc. and may also be useful when working with panoramas since the stitching will merge
multiple sources, each contributing its own range of used colors (depending on the contents of the picture..) into one final image.

Therefore my guessing is:  having a wider range of colors "available" may prevent losing color-information.

(Before you answer: I know: such detailed thoughts on one hand and using a cheap smartphone on the other does not match: true.
Usually I do not use a smartphone to take pictures, but it was a lucky situation to see this location with hardly any people around (#Corona)...)


kind regards
Fritz

The same obvious bug with panoramas is in AP on macOS if the option to convert to working space is enabled in the app's Colour preferences. When the app is supposed to be converting the stitched sRGB result to a different space, ROMM for example, it actually just assigns the ROMM profile without converting the pixel values into ROMM colour space.

Link to comment
Share on other sites

8 minutes ago, Fritz_H said:

Ah! Your explanation sounds very logical to me!
What is your workaround?

I don't enable the convert to working space option. When I do want to convert the colour space of a particular image/document, I use the convert command in Document menu. So, for a panorama stitched from sRGB JPEGs, let the app produce an sRGB stitched image and then, before beginning to edit the result, convert it to 16 bpc and the colour profile that you prefer for editing.

Link to comment
Share on other sites

1 hour ago, anon2 said:

I don't enable the convert to working space option. When I do want to convert the colour space of a particular image/document, I use the convert command in Document menu. So, for a panorama stitched from sRGB JPEGs, let the app produce an sRGB stitched image and then, before beginning to edit the result, convert it to 16 bpc and the colour profile that you prefer for editing.

@anon2 Thanks for your reply.
Based on that I tried the following:  no convert the final panorama but convert the individual images and then make the pano from them.

first I re-enabled the "Convert opened files to working space" - Option
then I opened all images individually, (they are auto-converted from sRGB to ROMM RGB) and saved them again (ROMM RGB).
after that I used the panorama-tool again with those converted images and the result was fine.

To me, this is evidence that you are right ("..just assigns the ROMM profile without converting the pixel values..")
and makes me more secure that no color-information is lost during the panorama-stitching since the ROMM-RGB gamut is wider/bigger than sRGB.

Thanks.
Fritz

Link to comment
Share on other sites

9 hours ago, Fritz_H said:

@anon2 Thanks for your reply.
Based on that I tried the following:  no convert the final panorama but convert the individual images and then make the pano from them.

first I re-enabled the "Convert opened files to working space" - Option
then I opened all images individually, (they are auto-converted from sRGB to ROMM RGB) and saved them again (ROMM RGB).
after that I used the panorama-tool again with those converted images and the result was fine.

To me, this is evidence that you are right ("..just assigns the ROMM profile without converting the pixel values..")
and makes me more secure that no color-information is lost during the panorama-stitching since the ROMM-RGB gamut is wider/bigger than sRGB.

Thanks.
Fritz

In case you weren't just experimenting, I don't think there will be an advantage to pre-converting the sRGB images to ROMM. Colour information shouldn't be lost by the stitching process, so you can stitch the sRGB images and then, if you want to edit the result in the ROMM space, convert to 16 bits per channel and ROMM.

Remember to not use ROMM profile with an 8 bits per channel image/document. The ROMM gamut is very wide and susceptible to distinct banding of both colours and brightness when that gamut is spread across only 256 levels per channel. 16 bits gives you 65536 levels per channel. 16 bpc is better than 8 bpc when editing in any colour space, and even more so when the gamut is wide.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.