All posts related to V2
#359518
The HP and some others can (I attached a gamut chart earlier) display Adobe RGB (1998) easily. And then some. Because one can treat Maxwell Render like a real digital pro camera (which is why we all love it), it would be a shame using it only to render into the limited 8-bit sRGB colour space, unless that's all one needs of course.

But but but... :mrgreen:

Do they have the monitor itself set to the (probably default from factory) sRGB mode, OR, have they set it to AdobeRGB mode as well? If you've left your high end monitor in sRGB mode, and hoping to work well with colors in PS, even if its working space is set to AdobeRGB....you won't actually have those wide gamut colors displayed.

I'm not sure how it works exactly but depending on the monitor, some wide gamut monitors emulate sRGB space better than others, because they have to restrict the colors they display somehow, to fall within sRGB gamut. And in fact they will display a more accurate sRGB emulation (and your calibrated sRGB monitor profile will work better) if you set the monitor to sRGB mode, if you intend to work in that color space.
#359539
Maxwell shows corrected color space for me on my monitor if I switch between sRGB and Adobe RBG 1998, so long as I use matching monitor modes (which my monitor has built in).

Photoshop is somewhat more of a hit-or-miss proposition because as I use "save for web" after converting to sRGB I get a very garish result -- but the result does work OK in non-color managed browsers (and sRGB only monitors).

I do notice an overall "grayness" (by that I mean middle values, not low chroma) that shows up in direct Maxwell output (particularly in jpegs) -- I think this may come from whatever rendering intent (and possibly BPC as well) Maxwell is using trying to squash everything into the tiny sRGB gamut. My solution is simply to only use high bit-depth images out of Maxwell for final output... which allows me to tweak the image to my hearts content in whatever image editing package I care to use.

The web is a mess -- so I have resigned myself a long time ago to poor online representations -- my concern is for print work (because that actually costs and makes money).

Best,
Jason.
#359548
Well, it's not hit-or-miss, really. No matter if you assign sRGB in Save for Web & Devices... or if you convert to sRGB in Convert to Profile..., a ProPhoto or Adobe RGB (1998) image will look worse on most peoples' non-colour managed screens; the ICC says that that's close to 99%. Only Safari and Firefox can evaluate at least an sRGB profile. IE9/10 can evaluate the ICC profile - but does not use a user's monitor's screen profile, which is ridiculous.
Photoshop is somewhat more of a hit-or-miss proposition because as I use "save for web" after converting to sRGB I get a very garish result -- but the result does work OK in non-color managed browsers (and sRGB only monitors).
Yes, that's why I recommended rendering always at least 16bit/channel Adobe RGB (1998) so one can derive the lesser CMYK printable and other on-screen output from it. Maxwellians rendering to sRGB have booked 1st class tickets and then decide sitting in economy, middle seat, no tomato juice :)
I do notice an overall "grayness" (by that I mean middle values, not low chroma) that shows up in direct Maxwell output (particularly in jpegs) -- I think this may come from whatever rendering intent (and possibly BPC as well) Maxwell is using trying to squash everything into the tiny sRGB gamut. My solution is simply to only use high bit-depth images out of Maxwell for final output... which allows me to tweak the image to my hearts content in whatever image editing package I care to use.
If the ICC is correct, and they would be, then one can only attach sRGB and then hope for the few with the right browsers. Right now, average users prefer otherworldly colours, like they prefer XL green tea almond nougat bubble tea :(
The web is a mess -- so I have resigned myself a long time ago to poor online representations -- my concern is for print work (because that actually costs and makes money).

Best,
Jason.
#359551
feynman wrote:IE9/10 can evaluate the ICC profile - but does not use a user's monitor's screen profile, which is ridiculous.
But since you applied a calibrated profile as a system profile....this affects everything you see on the screen. Why would IE need to use the profile if the OS already corrects what you see displayed?
#359553
My reasons for saying the web is a mess has less to do with non-color managed browsers and more to do with the fact that the vast majority of web users will not have quality monitors, which will most likely not be calibrated, and will often not even achieve the full range of sRGB (which is a pitiful lowest-common-denominator colorspace).

So even if you do everything correct (in regards to color workflow), the end user is still not likely to see what you do on your screen... artifacts like color banding, blowout and hue shifts are all too common.

All of which you already know... color management isn't a complete solution (as far as displaying work on the web goes) -- there really isn't one. So IMO it's best to take a more philosophical approach about it, and treat work meant for display on the web as if you are working with "horseshoes and hand grenades" (meaning getting "close" is still good enough).

For the record I consider 16-bit PNG AdobeRGB 1998 my baseline standard output from Maxwell.

Best,
Jason.
#359562
Very simple :D

If YOUR IE9 displays an image to which I attached an sRGB profile (taking MY screen's capabilities into account), it should take MY profile and, taking YOUR screen's display profile into account, calculate the correct display via CIE-Lab and show MY image to YOU as I saw the image.

What IE9 does instead is to read MY image's ICC profile, says "wow, thanks for the bonus, mate", but then uses only YOUR screen's display profile to display MY image. MY screen's sRGB profile is disregarded. That's why IE9's colour management is known as "pseudo colour management" - there isn't any.

Again, let me try to explain why CALIBRATION and PROFILE are two totally different things:

Step one - CALIBRATING means YOUR screen is linearised and adjusted for brightness, white balance and gamma. This CALIBRATION will, by way of YOUR graphics card, change everything displayed on screen - which you see right away by toggling before and after. Here, people make a big mistake: That looks nice, MY screen displays correct colours now. Wrong! CALIBRATION does not adjust YOUR graphics card to display a certain working colour space (sRGB, Adobe RGB (1998), whichever) on your screen. One does not CALIBRATE a screen to sRGB or Adobe RGB (1998) - only the screen's raw colour space is optimised! The display of images on a CALIBRATED screen is not correct at all - for that to happen, colour management must come into the equation.

Step two - based on YOUR screen's CALIBRATION, an ICC display profile is created, it contains the technical capabilities, or quirks, or PROFILE of YOUR screen. This is YOUR screen's profile (wrongly called monitor profile) which is then used by the system (OSX/Windows 7) on YOUR computer. Only now, colour managed applications (Safari, Firefox, Photoshop, Illustrator, Bridge, etc.) can use an image's/rendering's attached ICC profile (sRGB, Adobe RGB (1998) to convert that image/rendering into YOUR screen's colour space in order to display it correctly.

So, CALIBRATION of YOUR screen is only the primary stage - but not the most important one. Correct colours can only be displayed in applications supporting the ICC's colour management, meaning: to use YOUR screen's profile to temporarily convert (= while being displayed) the image's/rendering's colours to YOUR screen's colour space. Applications without ICC colour management can never display colours correctly, no matter if YOUR screen is CALIBRATED and also PROFILED.

I sat through many painful colour management and offset printing sessions in my short miserable life :D
Mihai wrote:
feynman wrote:IE9/10 can evaluate the ICC profile - but does not use a user's monitor's screen profile, which is ridiculous.
But since you applied a calibrated profile as a system profile....this affects everything you see on the screen. Why would IE need to use the profile if the OS already corrects what you see displayed?
#359568
feynman wrote:Very simple :D
If YOUR IE9 displays an image to which I attached an sRGB profile (taking MY screen's capabilities into account), it should take MY profile and, taking YOUR screen's display profile into account, calculate the correct display via CIE-Lab and show MY image to YOU as I saw the image.
That doesn't make sense..... :?: These color spaces are not device dependent...

When I save an image from PS using sRGB, or AdobeRGB or whatever, I save it using that standard color space, it's not MY sRGB space. It's an ICC standard profile attached to it, which specify a certain way to encode color information in the file. You don't embedd your DISPLAY profile into an image, you embedd a standard profile. Which doesn't have anything to do with your calibrated monitors profile.

I think you're confusing the issue with device independent color encoding standards (sRGB, AdobeRGB, etc), vs device dependent color profiles...We are talking monitor to monitor here, not monitor to printer or printer to monitor.

Think about it...

- YOU calibrate your monitor so it displays accurately the sRGB color space
- I calibrate my monitor so it displays accurately the sRGB color space
- You send me an image that's 0 255 0 and color encoding is set to sRGB - my monitor will display 0 255 0. Makes sense?

We are both calibrating our devices to display perfectly a certain STANDARD color space. These color spaces, or working spaces as they are called in PS are !!! device independent !!!. This is different than calibrating our monitors to a specific output device, like a printer in which case the printer has it's own color space, it is device dependent. And I would have to load that printers profile in PS and Soft proof with it, to get an idea of what my AdobeRGB, sRGB or whatever would look like when printed on it.
#359571
I always like these types of conversation... Just to throw a comment in there for interested users who are not very up on this stuff (but want to know more) -- there is a big difference between hardware calibration and software calibration (I'm talking monitors here).

Ideally you want a hardware calibrated solution (Eizo is a great brand for this) as it will be much better than a software calibrated solution -- by hardware calibration I'm referring to the ability to have the monitor interface directly with the calibration eye and change the settings inside the hardware (completely separate from your video card, OS and software).

By way of comparison, most normal calibration eye solutions only "software calibrate" -- meaning that, aside from some superficial stuff, your monitor is the same as it was before calibration and the software is simply using the data read through the eye to "compensate" for how off the monitor may be. The problem here is over time the monitor keeps getting more and more out of whack and your software profiler has to do more to compensate.

When you are talking color management you begin the conversation with your monitor... and until you have that issue straight nothing else really matters.

IMO this is vital for print/video work, but much less so for work meant to be seen on the web -- which is a far less controlled viewing environment (massive understatement).

Best,
Jason.
#359577
No, sRGB is not a device profile! With the help of MY CMM, which uses MY screen's ICC display profile, YOUR sRGB tagged image you've emailed ME or put on YOUR website is rendered to my screen so it looks identical on YOUR and MY screen, and vice versa. But - if YOU attach an sRGB profile, taking your screen's capabilities into account - meaning YOUR ICC display profile - I don't look at an sRGB profiled image, I look at an image taking YOUR screen as reference. That's the mistake that many make when they believe "to calibrate the screen to sRGB". Again, most designers attach their screen display profile to images, believing that after "calibrating the screen to sRGB", that is an sRGB profile. Wrong!

Regarding IE9, please search for "microsoft internet explorer 9 color management" and you will see that the whole colour community disrespects MS for lying when claiming that IE9 is colour managed. I quote: Internet Explorer 9 is the first Microsoft browser to partly support ICC profiles, but it does not render images correctly according to the Windows ICC settings (it only converts non-sRGB images to the sRGB profile) and therefore provides no real color management at all.

Nevertheless, all we wanted to establish at the outset is that the render preview is not colour managed, meaning only our screen display profile in OSX/Windows 7 is used, so we use Photoshop to evaluate our renderings properly.

Now the question: how do renderings with profile attached look under iOS :D
Mihai wrote:
feynman wrote:Very simple :D
If YOUR IE9 displays an image to which I attached an sRGB profile (taking MY screen's capabilities into account), it should take MY profile and, taking YOUR screen's display profile into account, calculate the correct display via CIE-Lab and show MY image to YOU as I saw the image.
That doesn't make sense..... :?: These color spaces are not device dependent...

When I save an image from PS using sRGB, or AdobeRGB or whatever, I save it using that standard color space, it's not MY sRGB space. It's an ICC standard profile attached to it, which specify a certain way to encode color information in the file. You don't embedd your DISPLAY profile into an image, you embedd a standard profile. Which doesn't have anything to do with your calibrated monitors profile.

I think you're confusing the issue with device independent color encoding standards (sRGB, AdobeRGB, etc), vs device dependent color profiles...We are talking monitor to monitor here, not monitor to printer or printer to monitor.

Think about it...

- YOU calibrate your monitor so it displays accurately the sRGB color space
- I calibrate my monitor so it displays accurately the sRGB color space
- You send me an image that's 0 255 0 and color encoding is set to sRGB - my monitor will display 0 255 0. Makes sense?

We are both calibrating our devices to display perfectly a certain STANDARD color space. These color spaces, or working spaces as they are called in PS are !!! device independent !!!. This is different than calibrating our monitors to a specific output device, like a printer in which case the printer has it's own color space, it is device dependent. And I would have to load that printers profile in PS and Soft proof with it, to get an idea of what my AdobeRGB, sRGB or whatever would look like when printed on it.
#359596
No, of course your screen MUST be calibrated and then also profiled - you can't do colour correct video editing work or go Photoshopping without that!

Anyway, Maxwell Render renders perfectly fine! It's only the render preview that is not colour managed. When you render, you select in the Tone Mapping section of the Camera panel, which colour space you want to use; I'd go for 16bit/channel ProPhoto or Adobe RGB (1998) - as large as possible. Unless you render only for display online, then you chose sRGB. If you want to properly judge a rendering so created, just open it with Photoshop, soft-proof to the desired target colour space while you retouch, etc. and after that's done finally convert to the desired colour space and save that as a new file so you always have the best original if you need it again. In Vray and other renderers (not Lightwave) you need to worry about "linear workflows" and such boring things, but not in Maxwell Render, which outputs just like a real camera device.

That's all.
render engines and Maxwell

"prompt, edit, prompt" How will an AI r[…]