Jump to content

Jose A

  • Content Count

  • Joined

  • Last visited

About Jose A

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @Roger Simon Hey again. Now I understand! From your description it seemed to me that Mac's would only support the software type of calibration, but being them good monitors, and a good integration of color management in the OS level, make it quite an effortless thing to change between profiles. And although I know that at the moment I might have some deviations from the proper profiles (the colorimeter is on its way) I still would regard my monitor as calibrated, as it is closer to a correct representation of sRGB and adobeRGB than 99% of the monitors out there. I wonder if the changes will be noticeable at all when I do a recalibration. It does not change the fact that something wrong is happening when it comes to color management between AP, windows and other apps. I do not understand how this can happen, unless if you keep the number of bits of the file. But as usually sRGB is in 8 bit and ProPhoto in 16 (I mean, if you keep using 8 bit scales on a ProPhoto colorspace...i mean...that makes no sense) you never destroy any information. Apart from maybe some really, really really small correction term, which in the end it does not matter either way because a space divided into 256 just has such a big step between adjacent values. I tried to find relative volumes of ProPhoto and sRGB but I couldnt find any kind of easy answer, but the "average maximum" correction term would be (2^-8)(Prophoto_volume/sRGB_volume)^1/3. In other words the correction term would be how many times bigger ProPhoto is than sRGB then divided by 256 (in terms of ProPhoto color space). This would be quite a small number. Now going from adobeRGB 16 bit to ProPhoto 16 bit then yes I would understand if the colors would shift, but then due to how big the colorspaces are and due to the really small stepping, I guess this shift would probably be imperceptible. And yes I am aware that the rendering intents are important in that case. I will soon print a couple of pictures and will have to do some soft proofing . Thanks again for all the input everyone! I am deeply appreciated by this. However I still think that I need someone from Serif to chime in!
  2. Hello again, I am currently on a work trip and have very limited free time. In relation to the monitor and what I mean by hardware calibration, because it is different than what you described, as what you described is what I would call software calibration. I will give a general definition of both and then a kind of example. Hardware calibration: Signal from computer to monitor is standardized, independent from computer, OS, etc, which is defined by the standard ICC profile and the monitor itself applies a correction curve. Software calibration: Signal from computer is first adjusted, by software, in accordance to the calibrated/modified ICC profile, and monitor takes values "as is", i. e. just displays those values. This kind of calibration requires the computer to have the specific corrected ICC profile for the monitor as it needs to be applied to the OS. My monitor is capable, of course, of both types of calibration. However, at the moment it is still only running on the hardware calibration mode. What is the actual difference between both. Imagine that I have an image that should be displayed with sRGB and it is just an RGB signal of 50 70 90 in 8bit, which is a very well defined point in the L*a*b space. The calibration type you described above, is a software type of calibration, what happens is that the computer has a modified ICC profile installed, which was calculated from the data the colorimeter software gathered. This means that the modified sRGB profile takes the value 50 70 90 and converts it to the values your monitor needs to display the color defined in the sRGB as 50 70 90. Lets say this is for your monitor 45 72 96. Your OS will do this change and send this value to your monitor, so your monitor gets a signal which is 45 72 96, and it will display the 50 70 90 of the sRGB profile. In a hardware calibration though, what happens is that the ICC profile is not changed, there is no correction to any RGB point. So the OS just uses the standard ICC profile and sends to the monitor 50 70 90. Now with hardware calibration, the monitor knows, as it has the calibration curves installed in its own memory that when it gets a value of 50 70 90, it needs to display 45 72 96 of its own rgb scale, and in the end the displayed color is exactly the same as the sRGB of 50 70 90. In both cases the display is giving 45 72 96 to its pixels, but in one case (software) the conversion is done in OS (software) level and in the other it is done in the monitor (hardware) itself. What my monitor can do, is use a supported colorimeter, and a specialzed software to upload the correction curves to the monitor. Like this I could change computers easily without needing to carry around, or have an icc profile in a cloud. Whichever computer I connect my monitor to, I know I can get a calibrated image. I can of course still do a standard (software) calibration, just using the xrite/spyder/whichever colorimeter I would choose and create a modified ICC profile. I hope I was I clear enough... I don't know, I am a physicist and this seems quite straightfoward to me, but I would understand if someone would find this quite confusing if not used to stuff like this. Just tell me if you think you got it, and I can try and make a better analogy if needed. This type of calibration of course is independent of OS, if you have a monitor capable of hardware calibration, which there aren't many. I know and I understand this. What seems weird for me is that when I go to the dialog this seems to change/set itself back to sRGB when I do not want that. Besides, if I start a new document from a fresh start from AP, and I want that documento to have an adobeRGB profile I need to do this: New document->choose sRGB (I cannot choose any other profile at the new document dialog)->create document->File: import ICC profile (import adobeRGB)->Document: Convert documento to adobeRGB. While supposedly, after importing an ICC profile it should be possible to select one at all times (e. g. at the start of a new document). Yes, I knew all this and I also agree with you regarding the color picker. I thought of this and I tried to find an actual driver from Benq but I wasnt able to do it. I am not even sure I found the driver (I found a driver but it seemed that it was a driver for something else regarding the monitor, not the monitor itself). This is true, but it is not me who sets the default working space to ProPhoto....adobe does, by making it their default working color space. I do understand that you in "theory" do not need to supposedly convert lower gamuts to higher gamuts, but if you do, then you are able to do more manipulation and pull data from the lower gamut, which is smaller than the human eye can see, to higher gamuts where the human eye can still perceive them and printers are also able to actually print. It kind of makes sense to me, as you can make more realistic (and as well irrealistic) photos. My camera cannot access some gamut, but I was there in location and I for example know that the cyan was way more cyan than my monitor/gamut can display, then being able to pull the data from a lower gamut to a higher one makes sense. Rendering intent should not change a pixel value, should only change the way it is displayed, and there I can agree that if it is not standardized it may display things slight differently. And rounding errors from lets say adobeRBG to ProPhoto makes no sense to me if its more than 1 for an 8 bit scale (as it is in the differences I see between AP and LR. I would accept values which would be X±1, but not more). This is simply because adobeRGB with certain illuminant are very well defined in the L*a*b color space for a certain illuminant. Therefore there are no significant rounding errors. There should be only one way to do it. Maybe I am underestimating how easy/hard it is, but from what I understand L*a*b space are very well defined quantities and the points of the adobeRGB/sRGB/ProPhotoRGB are also well definied in this space, there should be no wiggle room.
  3. (EDIT: I did not know that the pictures would not keep the filenames. The first picture is called "experiment-1.jpg" and the second is called "experiment-1-2.jpg". If you open them with a widegamut monitor and with a computer which manages colors/browser, you can see that -1.jpg renders as sRGB, even if the preview in the bottom is (to me in chrome) adobeRGB and the second renders just like the preview, in adobeRGB. The bottom 3 pictures are self explanatory when reading the text) Ok, I did a lot of tests, lot of tries with different things, I guess this will be a long answer, but even so I dont think I will cover everything I saw. First off, talk about my monitor. (Monitor talk I) So, I am still not entirely sure whether my OS is in adobeRGB or not. It is not easy to say if it is, but, I would assume it is, because of one of the tests. Although, most of it is in sRGB, but it does not comunicate that to anything else (by anything else, I mean graphics card and monitor), it seems that they do not transfer this kind of data. My monitor always assumes that whatever comes to it is in adobeRGB. So, when I see an sRGB file which is just displayed as is, whithout taking into account that I had set up the OS to adobeRGB and needed the conversion, I just see it super saturated. So, it seems that everything is hyper saturated in my OS. I noticed it right when I first turned it on when I bought it, but back then I knew I would have to do some color management and since then I got convinced that everything is ok. But it seems that things are much harder than what I thought. So, the first thing I did was to create the "experiment-1.jpg" file in AP. There the greens are just from 255 down to 36 in steps of 36. The cyans are 0 255 255, 0 255 230 and 0 230 255. The document was done in adobeRGB. I proceeded to export it with embedded .icc profiles. the "experiment-1.jpg" with sRGB and "experiment-1-2.jpg" with adobeRGB. Checking them in "windows fotos" seems that the app ignores .icc profiles, however, I found out that "windows photo viewer" does not. With windows photo viewer I was able to correctly display the images. I was also not thinking it was real, because I was now used to the hyper saturated greens and it seemed that the green was too flat/yellowish. But after using my phone with an image of 0 255 0 as a reference I noticed it was correct. So, this allowed me to conclude that somewhere, Windows is indeed knowing it should be in adobeRGB, and this application knew about this and did the conversion. Monitor talk II - My monitor has a fast switch to change between 3 custom profiles. As default they come as adobeRGB, sRGB and B&W. this is not important, but I switched the B&W for a night mode, low brightness, less blues mode. Either way, I found out, by this images, that the monitor always assumes an adobeRGB input and when I switch to sRGB it does the conversion internally to display sRGB. This is how it seems to me, because when I view the same images but with the sRGB mode on, the pic with the sRGB profile gets even less saturated, and the one with the adobeRGB is correctly displayed. Continuing with the tests I made. Then I did a lot of testing with real images and some test images from another thread ( ) What I saw is that LR also manages color. As I import the "experiment-1..." jpegs I see that they are different. But unfortunately, as with the rest of most things with the OS, AP shows the same image, be it the sRGB one, or the adobeRGB one. Then I tried to export the same photo (now a real photo, which I had done some editing in LR and from which I created a tif file and did not temper with) both with LR and AP. Here I got some weird results. So first I did some adobeRGB export and loaded it into AP. It showed correctly that the color space was adobeRGB but immediately the colors were different from LR. I then proceeded to export the image as .jpg with embedded adobeRGB and did the same in LR to compare exports in an external viewer. Weirdly, I had mixed results in the sense that the exported versions were exactly the same, but the colors did not seem to match neither AP or LR in "windows fotos". But it seemed much much closer to AP than to LR. It can also be that then, as I did not have neutral colors everywhere and my color perception was slightly different when looking to one photo on the left side and the other on the right side. It seemed that switching the viewers around was switching the color difference (i. e. the "warmer" picture always was the one on the left side, regardless if it was AP-left, windows fotos-right or vice-versa). So I would prefer to assume that although they seemed different, my color perception was being altered by the inhomogenous and strong color separation within the photo (was looking at some red mountains and blue sky). However, in the color managed windows photos, the colors now also did not seem to match, but were much closer to LR (i. e. they were quite different from AP). The tests with ProPhoto just showed what I had already seen above which was that the pixel values are changed, as they should be (not meaning that its being done to the correct ones). So, if I then used "experiment-1-2.jpg" and converted it to ProPhoto, both LR and AP do change the pixel values, albeit to different ones, as seen above. So, the before 0 255 0 from adobeRGB was now 138 237 78 (edit, read ahead) in AP and in LR 37.1% 92.3% 30.1%, which in 8 bit is 95 235 77, which is a huge difference in the red channel specially. Also strange is that if I instead export the LR file with the embedded ProPhoto and load it in AP, now AP reads 77 230 60... (you can see the 3 cases in the attached pics) (EDIT: I realized now that I made a mistake and loaded "experiment-1.jpg" into AP and then did the conversion, so from sRGB to ProPhoto and not from adobeRGB to ProPhoto. By loading the correct file "experiment-1-2.jpg", I get 76 230 60, which complies with the exported version from LR and loaded into AP). What this is telling me is that somehow AP renders everything as sRGB (as proof of the experiment-1.jpg which has an sRGB as embedded profile, but renders the same as a pure adobeRGB), but of course, as I said above, my monitor takes that whatever is being given to it is adobeRGB and hence the color discrepancies. Then, as it does not take into account the differences between sRGB and adobeRGB the conversion to ProPhoto goes a bit off, as well as then the rendering. I did some other tests in between, but the ones that really got me thinking were some with gradients. I wanted to see the effects of render intents. First I did a conical gradient where I went like 255 255 0 - 0 255 0 - 0 255 255 - 0 0 255 - 255 0 255 - 255 0 0 - 255 255 0. Somehow this whole gradient is out of gamut for both sRGB and adobeRGB according to the soft proof. However I was still seeing the colors even if I chose relative colorimetric (which is ok, I would just be seeing all the saturated colors) and then if I chose perceptual there was just a tiny small change in the render (now I cannot really remember if it was changing the intents or changing the target space). Either way, I was expecting that if I switched to perceptual I might have a bigger difference in display of the colors as all the colors would be compressed into the gamut. But even more impressive and here I definitely expected to see a difference was with a linear gradient only in the green, while having the soft proof showing when I would be starting to clip adobeRGB, and it seems that at a value of 0 14 0, AP tells me that I am clipping adobeRGB (it might be true, I do not know, but this tells a lot about how huge ProPhoto is). Then I did a linear gradient across my whole document from 0 10 0 to 0 16 0 and changing intents did nothing. I was expecting to see saturated greens in a relative colorimetric intent (as from what I understand out of gamut colors are just represented as saturated colours, instead of compressing the color space into the target space as in perceptual). Maybe the color transformation is done instead in LAB and it preserves part of the L in a LAB space and this is why the whole thing stayed so dark (I was naively thinking I would see bright greens). Oh well, Its super late now, I took many hours today on this matter, I need to go to bed. All the best -JA
  4. Hey guys, Thanks again for your comments and suggestions. Unfortunately in the end last wednesday I was not able to be home and do the testing. Tonight I will have time for sure though and I will do lots of tests, the ones suggested here and some others I thought of. The way I understand my monitor (Benq SW2700pt), the calibration is in the monitor itself. I can either do it "old style" with a colorimeter and correct the .icc profile, or use a colorimeter that is supported by the monitor and use a software to communicate with/calibrate the hardware instead (so, instead of correcting the .icc profile, I can keep windows on adobeRGB and the monitor knows that for example for an input for pixel X of (110,110,110) it needs to output (108,110,111) at pixel X for example). I have both possibilities. Although I still do not have a colorimeter, I am in the process of getting one, but the monitor comes factory calibrated, with a spec sheet and I did not use it for more than 60 hours I would guess. But soon I will be able to regularly calibrate it. You are correct in the assumption although I must point out 2 things: 1-I downloaded the profile from the ICC website because I wasnt aware at the time that LR was embedding the profile itself, although in the export options it was selected as the export profile (it could have been that it used the profile to encode the image, but would not embed the profile itself). Later I realized that LR is indeed embedding the profile and AP is actually using the embedded profile and not the one I downloaded, because they have different names. The one from LR just ProPhotoRGB and the one from ICC is called ROMM RGB. 2-AP only allows me to select a work RGB profile if I have a document opened, and at that point I can select between the default sRGB profile, the profiles I have in the past imported into AP (although I must say that the list of the icc's I imported is random. For example, right at the beginning I imported both adobe RGB and the ProPhoto from the ICC website, and sometimes only adobeRGB appears, sometimes only ProPhoto, sometimes both, sometimes none. Whenever I open AP and go directly to the color profile tab in the settings, the work space is always sRGB and I cannot choose any other profile if I do not open a document. So I still do not know what will happen when I open a document without an assigned icc profile, and this is one of the tests I will do. I am aware of this, and I own a sony alpha 6000 which has a 14 bit depth for adobeRGB (in which I shoot). I am in the process of choosing whether to post process always in ProPhoto, to be able to take full advantage of the color space, even in the future, but complicate the softproofing either for the web or printing, or if to just do everything in AdobeRGB to simplify softproofing and to know that I will have displayed either on the web (if someone used of course a calibrated adobeRGB monitor) or on a print the same I see on my monitor, without having to think that there will be more or less colours in prints for example. Unfortunately I did not find any tab on LR to change the rendering intent. The only place I can change between just perceptual or relative intents is in a softproofing dialog of LR. I am now thinking that maybe this is the case, but changing intents should not change pixel values, as I understand, it should only change how the image is being displayed while going from the bigger color space of ProPhotoRGB to the lower spaces of the monitors. I would guess, but maybe I am wrong, that LR uses a relative intent to display the ProPhoto file, I want to test this further, as I tried with an actual photo doing some green saturation, etc. but I want to try with "fake" images filled with these color gradients (I do not know their names) and see if it keeps the gradation or if it clips the most saturated greens. What I also do not understand, if the working space if for example ProPhoto, why are pixel values given in 8 bit depth in AP. Actually even if I would be working in any 16 bit depth work space. In LR at least it appears in percentage, which then makes sense. Thank you Leigh, I really appreciate it. I also hope that my tests of tonight will help to understand where the mistake is, if mine, or somewhere else. I still think I might have done something wrong somewhere. I also do not understand the full talk between computer<->graphics card<->monitor, if they ever exchange which profile is being used or not. I also do not know as of now if my monitor is working with 10bit depth or 8, because it can use 10, but I think my HDMI cable does not support 10 bit (I do not know which version of the HDMI cable I have, as at the beginning I was connecting the HDMI to my old laptop and my laptop only has an HDMI slot, and I kept it for the new desktop I have). I will exchange it for the DisplayPort that came with the monitor which I hope should support 10 bit color depth. Then I will need to figure out what the graphics card will do, as supposedly it does support 10 bit depth, but from forums it seems that nVidia does not make it easy to set, I will see. Once again, thanks for all of you who chimed in, I am truly appreciated. -JA
  5. Hey, Thanks, I hope I did change the profile of the OS, at least I tried, and on the color management window it seems that adobeRGB is my default icc profile. My monitor is hardware calibrated, so I just need to use the profile directly at the OS. Now, if windows is truly respecting my choice is hard to say, I guess I will do a small test using a 0 255 0 field and set my monitor to sRGB and see if I see a difference when I change the profiles between sRGB and AdobeRGB in the windows dialogues. In the screenshots you can also see that yes they have the 16bit ProPhotoRGB as the file's icc profile. (top left corner). At least I understand that the small dialog there means in which color workspace I currently am. No, I still did not try that, but I want to do some more tests tonight and I will try that as well, thanks!!
  6. Hello guys, although in the meantime I read way more about color management and my knowledge is now higher, I still want to take a deeper look at this topic as now Im in a rush, but you guys think that I might be seeing the same problem? (I also use a wide gamut monitor) Thanks in advance, -JA
  7. Hello everyone, just a quick introduction: José Andrade from Portugal and currently living in Germany. I feel in love with photography and I am learning everyday on how to enhance my post-editing skills, as well as how to shoot photographs properly! I am really enjoying the software (Affinity Photo for windows) so far, although I am running into some problems regarding color management, but hopefully all will be sorted out soon. But the experience has been quite great nonetheless! All the best, -JA
  8. :Bump: I really need to see this issue resolved! Why are the colors different in each program??
  9. Actually this is probably not a color management problem (as you can see on the attached screenshots). 1. AP keeps on changing the to default color workspace (it does not matter if I select ProPhoto as work profile) after restarting AP it gets back to sRGB 2.The colours are indeed different. As you can see from this zoomed in image, the image on the right was generated by lightroom and directly opened in AP, after being sure that I chose ProPhoto RGB (as I say above, during that session, as if I restart AP it will get back to sRGB) as work space. However, the two images are showing completely different renders of the same image in terms of colours. The pixel that I chose was one easy to identify, and in LR it read R: 24,0%; G: 24,7%; B: 14,8%. This would correspond in an 8 bit (as the one shown in AP) as R=69, G=63, B=38. However in AP the pixel values are R=64, G=55, B=33. I also find that whichever deep shadows I can see in Lightroom, will be basically black in AP. I would like to understand what is the problem and if I am doing something wrong. All the best, -JA
  10. Hello everyone, I currently own a monitor which is used for color management, but unfortunately I am still very confused on how everything works. I read so many articles, etc., and I still don't feel that things are clear to me, mainly because when I try to experiment with these things I get mixed results. My monitor is capable of 99% adobeRGB and I set it in windows to always use adobeRGB. My concern is that the colours I see in Affinity photo differ quite a lot to those I see in lightroom (I use a standalone version of lightroom to do cataloging and some pre-editing). I read that lightroom used ProPhoto RGB as its main icc profile for the develop module. Well, I set the "RGB color profile" in the AP's color profiles as the same (I downloaded it from the icc website). Nonetheless the colors are still different. Is this somehow a conversion from the higher gamut ProPhoto RGB to adobe RGB (screen's icc profile) that uses different engines and therefore the colours are different? What are the steps between the photo's RGB values->screen when in AP? I need guidance or someone to really dumb down the information and feed it to me, because I am very confused with this ordeal. Thanks for anyone's time, all the best, -JA
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. These are the Terms of Use you will be asked to agree to if you join the forum. | 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.