[BigMackCam]

Actually, by researching again the documentation of Silkypix Dev 9, I found that all this is also possible, I just didn't know it was in the print module since I don't have a printer at home (not printing directly from SPD9).
The contributions here helped me to refine my search. The "out of gamut warning" in SPD9 also warn when parts of the image color is at the edge of the color space. When there is no OCG warning, all of the image colors are inside the target color space. The tolerance between warning and no warning is about one to two step of the saturation slider.

Both Darktable and the latest version of RawTherapee also offer out-of-gamut warnings. They're extremely capable and cost nothing. I mention this only in case you want an alternative to Slikypix Dev...

[biz-engineer]

Both Darktable and the latest version of RawTherapee also offer out-of-gamut warnings. They're extremely capable and cost nothing. I mention this only in case you want an alternative to Slikypix Dev...

Already having 7 different software installed for image processing. I've installed , uninstalled RT many time alreay, I'll give it a go when I need. I was not quite understanding what was in SPD9 already, but progressed a bit in the right direction. What happens if tweak my image with an sRGB monitor and export it to a file with Adobe RGB or ProPhoto RGB and get it printed by an inkjet printer having a gamut larger than sRGB? Will all colors be off the chart on the Inkjet print or I can trust that the color space interpolation software is good enough to keep a perceptually decent print output?

[stevebrot]

What happens if tweak my image with an sRGB monitor and export it to a file with Adobe RGB or ProPhoto RGB and get it printed by an inkjet printer having a gamut larger than sRGB?

Your monitor gamut and the editor colorspace are two different things. Intended gamut for output (embedded in the file) is something else as well. That is where gamut warnings come into play. The general rules go something like this:

• Do RAW capture (no colorspace)
• Edit in as broad a gamut as possible using a calibrated monitor supporting as broad a gamut as possible
• Export to the color profile of the target device. For inkjet printers, it will be an icc profile specific to the printer model and paper being used. These are generally supplied for download by the paper manufacturers. Service bureaus and other professional print services will often accept TIFF in broad gamut. Most online print makers accept JPEG with sRGB.

Hopefully, this will clarify a little.

FWIW, I personally would not pay extra for "full" sRGB, given that it is the lowest common denominator for display and output devices.


Steve

[TonyW]

What happens if tweak my image with an sRGB monitor and export it to a file with Adobe RGB or ProPhoto RGB and get it printed by an inkjet printer having a gamut larger than sRGB? Will all colors be off the chart on the Inkjet print or I can trust that the color space interpolation software is good enough to keep a perceptually decent print output?

What will happen potentially is CHAOS and confusion .

Best case you are making a 'Voodoo move' if you are dropping an sRGB file into the much larger colour spaces of Adobe RGB or worse ProPhoto RGB - you now have the potential to stretch the data too much within the larger colour space and cause banding artifacts - there is no point in doing this, but...

If you are editing from raw then use Adobe RGB or better yet Prophoto RGB for your file manipulation and then convert to whatever your print lab asks for - ideally they will tell you to edit and apply a specific ICC paper profile to your image. Worst case they will insist on sRGB

Do not send a lab either an Adobe RGB file or Prophoto file if they are assuming sRGB (many seem to!) then you will get wrong colours.

---

Last edited by TonyW; 02-07-2020 at 05:34 PM.

[pschlute]

I was not quite understanding what was in SPD9 already, but progressed a bit in the right direction

Just a couple of tips on using Silkypix (I use DSPro 7)

1. VIEW/DISPLAY SETTINGS........Make sure ENABLE DISPLAY COLOR MANAGMENT is ticked, and that your calibrated monitor profile is the one showing in the drop down box.

2. SETTING/FILE OUTPUT SETTINGS..... It is a good idea to set these up and save them as a preset. In the two images below you can see my JPEG and TIFF default settings. So when I want to create a 16 bit TIFF image in AdobeRGB space I simply select the TIFF settings I have saved in the DEVELOP dialogue box.

[biz-engineer]

Hopefully, this will clarify a little.

Yes, I think it's clear for me now. The inconsistant Silkypix behaviour with JPEGs/TIFF managed to totally confuse my shaking understanding. I was able to figure out conversions between colors spaces and figure that Silkypix only color manage previews and display out of gamut areas properly and when working from with RAW files, in other words it's only a raw converter.

Do RAW capture (no colorspace)Edit in as broad a gamut as possible using a calibrated monitor supporting as broad a gamut as possible

Yep. The smallest color space used on the workflow is what defines the maximum color gamut in the final output. Going from a wide space to a smaller space clip colors to fit the smaller space based on rendering intent. Going from smaller space to larger space just linearly remap clipped colors into the larger space.

- Sending JPEG/sRGB files to the photolab is the safest approach but also give the lowest color gamut in print not using the full range possible with the development or prints process.
- Sending ProPhoto exported files to the photo lab allow to fully exploit the color gamut of any c-type dev / inkjet printer / paper gamut, but it leave the photo lab to decide what rendering intent they will use.
- Sending file exported with the typical colors space of the printer+paper (even if the icc profile is old) strongly reduces the gap between the typical icc of printer+paper model and the icc from the most recent calibration the lab performed on their printers, so whateven rendering intent option is selected will make negligeable difference on the print.

---------- Post added 08-02-20 at 15:53 ----------

So when I want to create a 16 bit TIFF image in AdobeRGB space I simply select the TIFF settings I have saved in the DEVELOP dialogue box.

I see. It is a good thing to use 16bits for larger color spaces. One of the options in SPD9 is the 16bits for printing.

---------- Post added 08-02-20 at 16:00 ----------

Do not send a lab either an Adobe RGB file or Prophoto file if they are assuming sRGB (many seem to!) then you will get wrong colours.

The cheap labs likely don't have much time to spend on these things as they must save every cents out of the cost to still be able to make money. For 30% higher price, I could see the jump in quality when I sent the same files to 4 different labs for comparison. That's probably no a good idea to send files with a fancy embedded color space to the cheap lab.

[biz-engineer]

Further investigations lead me to think that good understanding of color spaces should imply the recommandation that if your image color gamut fit within the sRGB color space there is no need to use a larger color space. Using ProPhoto RGB for an image that fit within the sRGB or Adobe RGB color space bring no benefit at all , on the contrary ProPHoto RGB take a lot more data for nothing. I've check from my image library what images wouldn't fit in sRGB , Adobe RGB, 90% of images completely fit well in sRGB, the 10 images that don't fit in sRGB can fit mostly within Adobe RGB and when they don't the parts of the image out of Adobe RGB gamut is very small. ProPhoto RGB over TIFF 16bits (400Mb per file) is usable when the printer is next to the computer, no so much usable when uploading 10 images to an online photo lab.

[BigMackCam]

Further investigations lead me to think that good understanding of color spaces should imply the recommandation that if your image color gamut fit within the sRGB color space there is no need to use a larger color space. Using ProPhoto RGB for an image that fit within the sRGB or Adobe RGB color space bring no benefit at all , on the contrary ProPHoto RGB take a lot more data for nothing. I've check from my image library what images wouldn't fit in sRGB , Adobe RGB, 90% of images completely fit well in sRGB, the 10 images that don't fit in sRGB can fit mostly within Adobe RGB and when they don't the parts of the image out of Adobe RGB gamut is very small. ProPhoto RGB over TIFF 16bits (400Mb per file) is usable when the printer is next to the computer, no so much usable when uploading 10 images to an online photo lab.

I'm not sure if what I'm about to say will address or challenge your thoughts and conclusions, but it might be useful (bear in mind, what I say is based on my understanding which, itself, is limited)...

When you shoot JPEG in-camera, you are constraining the available image data by choosing both the output quality (bit depth and compression) and rendering intent (colour space) which is "baked in".

When you shoot raw, you're not constraining the data or choosing rendering intent... you're just capturing sensor data at whatever bit depth is supported by the hardware. There is no colour space, no gamut - just data.

Continuing with the raw file... to do anything with this, you need to convert it into usable image data. To do so, there must be "intent". When you load the raw file into software such as Lightroom, the intent is editing at the best possible quality without losing important data, so the raw is converted to a wide-gamut working colour space, such as ProPhoto RGB using 16-bit colour depth - the combination of which provides a wide range and resolution of tones. Working within such a large colour space, and to 16-bit depth, maximises the representation of tones and minimises the possibilities of posterising during the editing process. By comparison, older versions of Photoshop Elements and GIMP (for example) used 8-bit sRGB working spaces, which could often result in posterising (e.g. coarsely-graduated deep blue skies).

What you see on your screen during editing is itself a "rendering intent" of the image currently stored in the software's working space, converted again to the display profile your application is using - which might be the same as the operating system, or a different one chosen by you (if you use a colour managed approach with your system and editing, this display profile would be one you created using a colorimeter and software such as DisplayCAL, or that provided with the colorimeter device).

When you're done working on your raw image within the software's wide-gamut working colour space, you'll want to do one or more things with it... create files for online viewing, printing, archiving etc. For these different intents, you'll export to different file formats using output profiles that are appropriate to the individual rendering intent. For online viewing, you might choose a resized and somewhat-compressed 8-bit JPEG with sRGB output profile. For professional printing, you might choose a full-resolution 16-bit TIFF with AdobeRGB (or even a profile specified and/or supplied by the printing company). For archiving... well, I guess it depends on what you want from your archives. If you simply want a small file size and something you can view on your computer or phone some time in the future, then the same JPEG you created for online viewing would do the trick. If you want the maximum possible quality and versatility and don't care too much about file size, it would make sense to choose (perhaps) lossless-compressed 16-bit TIFF with a wide-gamut output profile such as ProPhoto RGB, as this places minimal constraints on the image data and you'll be able to do more with it in future (you could, of course, archive the unconstrained raw file and editing logs, but that would mean you'd need software that could read the raw, apply the edits correctly and export to different file types).

In summary:

- capture your images in raw format
- work on your raw images in the widest colour space and with the greatest bit-depth available (which might influence your choice of editing software)... ProPhoto RGB is very good for this
- export images using resolutions, file types and output profiles (sRGB, AdobeRGB, custom supplied etc.) appropriate to individual rendering intents (online viewing, home or professional printing, archiving etc.)

Alternatively, if you're shooting JPEG in-camera, use the highest quality setting available and choose the output profile (sRGB, AdobeRGB etc.) that best matches your primary rendering intent. With either output profile it will be limited in the range of colours it can represent due to 8-bit depth and lossy compression, and much useful image data is lost for good compared to raw... but at least it will be appropriate for the target device.

Again, my disclaimer... This is my understanding. I'm sure others with greater knowledge will correct me if I've mis-understood or mis-represented anything above (like anyone else, I'm constantly learning ).

You might want to read the following useful article:

https://photographylife.com/srgb-vs-adobe-rgb-vs-prophoto-rgb

[biz-engineer]

When you shoot JPEG in-camera, you are constraining the available image data by choosing both the output quality (bit depth and compression) and rendering intent (colour space) which is "baked in".When you shoot raw, you're not constraining the data or choosing rendering intent... ... ... This is my understanding. I'm sure others with greater knowledge will correct me if I've mis-understood or mis-represented anything above (like anyone else, I'm constantly learning ).You might want to read the following useful article:https://photographylife.com/srgb-vs-adobe-rgb-vs-prophoto-rgb

Thanks for providing this feedback. This is the same as my understanding, except for a few things and for practical considerations.

When you shoot raw, you're not constraining the data or choosing rendering intent... you're just capturing sensor data at whatever bit depth is supported by the hardware. There is no colour space, no gamut - just data.

There is a color space in RAW. That color space is defined by the wavelength of each primary colors of the CFA installed on the top of the CMOS sensor + adjusted by whatever in camera processing is applied to sensor data to make is the RAW we have access to. Converting the RAW data to an image file in whatever color space (ProPhoto, sRGB, Adobe) starts for the initial color space bounded by the CFA, the image color gamut is contained within that CFA defined color space. Any real world colour outside of the CFA color triangle will be clipped

What you see on your screen during editing is itself a "rendering intent" of the image currently stored in the software's working space

Sure. Now, the rendering intent is only a consideration when the range of colors in an image exceed the color space we want to code the image in (JPEG sRGB for example) or exceed the color space of a display or exceed the color space of a printer. The rendering intent (if I understood correctly), is the choice of how the range of image colors are going to be fit into the color space that is too small to just code image colors by use of a simple proportion. For example, a gray scale image occupy a straight line in the Lab coordinates, that image will fit any color space and there is no need to consider any rendering intent.

When you're done working on your raw image within the software's wide-gamut working colour space, you'll want to do one or more things with it... create files for online viewing, printing, archiving etc. For these different intents, you'll export to different file formats using output profiles that are appropriate to the individual rendering intent. For online viewing, you might choose a resized and somewhat-compressed 8-bit JPEG with sRGB output profile. For professional printing, you might choose a full-resolution 16-bit TIFF with AdobeRGB

THAT is the key point! Now, still considering a gray scale image (a color image with satuation = 0), there is no advantage at all to use a color space larger than sRGB, no matter where is image will be displayed. For a gray scale image larger color spaces such as Adobe and ProPhoto will just make the image file larger but bring no benefit for how the image will be rendered on display or print. If the image a not a gray scale image, there is a range of saturation for which the image colors will fit perfectly into sRGB. It could be also that the image is one of a deep red flowers bouquet, the red won't fit into the realm of sRGB, not even Adobe, it's fit into Prophoto and if the intent is to print that photo with an modern Inkjet printer than ProPhoto 16bits will be the best choice because the print will display the red flower with a red closer to the actual red than it would be if the image was coder over an sRGB colors space (the red would have be clipped in sRGB).

- work on your raw images in the widest colour space and with the greatest bit-depth available (which might influence your choice of editing software)... ProPhoto RGB is very good for this

Yes, in theory, the larger color space over 16bits per channel is the best (ignoring quantization consideration in case of small image gamut coded into a large color space). If my connection bandwith was unlimited, and my laptop would happily like to carry 400Mbytes files from disk to memory to CPU and back, then ProPhoto RGB 16bits would be just fine, everyone would be happy to use it.

But now there is only a small practical problem... the size of a TIFF 16bits file from a Pentax K1 is 400Mbytes large (I didn't check how large would the TIFF 16bits file be from a 645z... suppose to be the camera for people who want the best possible image quality), I am not sure is I should upload a dozen of 400Mbytes files to the photolab server (I have to start the upload before going to bed, maybe in the morning the files reached the photo lab). So I might want to check the color gamut of my images, then decide if sRGB is enough to contain all colors, or if I need to use adobe RGB or if the file is about colorfull flowers to be printing by inkjet I use the 400Mbytes 16bit TIFF.

Finally, the very reason of my previous comment is for archival: if I don't want to inspect each image for color gamut, and if I don't know what I will do with an image in the future, I might consider ProPhoto TIFF 16bits to be on the safe side... I'll have to archive those 400Mbytes per file. But if I don't know what I might do with an image in the future, how about keeping the .PEF or .DNG files that are 10 times smaller than the ProPhotoRGB 16bits TIFF files. If I'd use a medium format camera, manipulating 16bits TIFF files for all my photos would be unthinkable (my computer would disagree or would get really hot), yet I would spend my money into a MF camera and use sRGB for colorfull photo. That's where knowing the color space used by an image is key to deciding what workflow would be appropriate.

[BigMackCam]

There is a color space in RAW. That color space is defined by the wavelength of each primary colors of the CFA installed on the top of the CMOS sensor + adjusted by whatever in camera processing is applied to sensor data to make is the RAW we have access to. Converting the RAW data to an image file in whatever color space (ProPhoto, sRGB, Adobe) starts for the initial color space bounded by the CFA, the image color gamut is contained within that CFA defined color space. Any real world colour outside of the CFA color triangle will be clipped

Yes, agreed. What I meant - and perhaps explained poorly - is that the raw file is as unconstrained as it can possibly be, coming in its native form from the camera without having any standardised colour spaces applied to it (such as sRGB, AdobeRGB, ProPhoto RGB). It's just sensor data, encoded into a raw file.

Sure. Now, the rendering intent is only a consideration when the range of colors in an image exceed the color space we want to code the image in (JPEG sRGB for example) or exceed the color space of a display or exceed the color space of a printer. The rendering intent (if I understood correctly), is the choice of how the range of image colors are going to be fit into the color space that is too small to just code image colors by use of a simple proportion. For example, a gray scale image occupy a straight line in the Lab coordinates, that image will fit any color space and there is no need to consider any rendering intent.

I'm going to have to think this part through... I've read it a couple of times and I'm still not quite grasping it...

THAT is the key point! Now, still considering a gray scale image (a color image with satuation = 0), there is no advantage at all to use a color space larger than sRGB, no matter where is image will be displayed. For a gray scale image larger color spaces such as Adobe and ProPhoto will just make the image file larger but bring no benefit for how the image will be rendered on display or print. If the image a not a gray scale image, there is a range of saturation for which the image colors will fit perfectly into sRGB. It could be also that the image is one of a deep red flowers bouquet, the red won't fit into the realm of sRGB, not even Adobe, it's fit into Prophoto and if the intent is to print that photo with an modern Inkjet printer than ProPhoto 16bits will be the best choice because the print will display the red flower with a red closer to the actual red than it would be if the image was coder over an sRGB colors space (the red would have be clipped in sRGB).

Yes

Yes, in theory, the larger color space over 16bits per channel is the best (ignoring quantization consideration in case of small image gamut coded into a large color space). If my connection bandwith was unlimited, and my laptop would happily like to carry 400Mbytes files from disk to memory to CPU and back, then ProPhoto RGB 16bits would be just fine, everyone would be happy to use it.

But now there is only a small practical problem... the size of a TIFF 16bits file from a Pentax K1 is 400Mbytes large (I didn't check how large would the TIFF 16bits file be from a 645z... suppose to be the camera for people who want the best possible image quality), I am not sure is I should upload a dozen of 400Mbytes files to the photolab server (I have to start the upload before going to bed, maybe in the morning the files reached the photo lab). So I might want to check the color gamut of my images, then decide if sRGB is enough to contain all colors, or if I need to use adobe RGB or if the file is about colorfull flowers to be printing by inkjet I use the 400Mbytes 16bit TIFF.

Finally, the very reason of my previous comment is for archival: if I don't want to inspect each image for color gamut, and if I don't know what I will do with an image in the future, I might consider ProPhoto TIFF 16bits to be on the safe side... I'll have to archive those 400Mbytes per file. But if I don't know what I might do with an image in the future, how about keeping the .PEF or .DNG files that are 10 times smaller than the ProPhotoRGB 16bits TIFF files. If I'd use a medium format camera, manipulating 16bits TIFF files for all my photos would be unthinkable (my computer would disagree or would get really hot), yet I would spend my money into a MF camera and use sRGB for colorfull photo. That's where knowing the color space used by an image is key to deciding what workflow would be appropriate.

PEF or DNG files - plus the associated sidecars - are indeed much smaller than even lossless-compressed 16-bit TIFFs; but you need to be confident that you'll always have software capable of reading the PEF or DNG and any sidecar files and correctly re-applying the stored edits such that your images look the same as when you archived them. With TIFF, your edits are baked in (bad for further editing, but good for finished-article archival) and it's one of the most supported image formats in existence, so it's certain to be easily readable many years from now.

What it boils down to is, you're going to have to come up with an archival approach that meets your needs in terms of image data quality, archival format convenience, and disk space / bandwidth.

[biz-engineer]

What it boils down to is, you're going to have to come up with an archival approach that meets your needs in terms of image data quality, archival format convenience, and disk space / bandwidth.

Agreed.

Along with that thread, I've found that Silkypix was very limited regarding soft proofing, color spaces and it didn't perform color management (with calibrated monitor profile) when viewing JPEG or TIFF files, color management is only performed in DNG/PEF processing preview. However, I've discovered that GIMP offers it all for free, both for the image and displaying, that was playing with GIMP features with various cases that really help me nail my understanding. So now that's great, I can still convert my RAWs with Silkypix and use GIMP to do anything related to image embedded color space, printer & paper icc profiles, monitor profiles, soft proofing and out of gamut warning. No only that, but GIMP can also work with 8bits, 16bits, 32bits integer and floating point data.

[kaseki]

Thanks for providing this feedback. This is the same as my understanding, except for a few things and for practical considerations.
...

But now there is only a small practical problem... the size of a TIFF 16bits file from a Pentax K1 is 400Mbytes large (I didn't check how large would the TIFF 16bits file be from a 645z... suppose to be the camera for people who want the best possible image quality), ...

I can report that the PEF files from my Z are in the 55 MB to 65 MB range. I have only begun to mess with Darktable, and haven't kept many experimental results. I found one TIFF that is 293.4 MB, but I don't recall what parameters I set on the conversion. I assume that either it was a simpler scene than the 400 MB K1 example, or I unintentionally used some parameter that reduced detail in some respect.

[biz-engineer]

I assume that either it was a simpler scene than the 400 MB K1 example, or I unintentionally used some parameter that reduced detail in some respect.

TIFF file sizes are fixed regardless of image content, detail, noise etc. For the K1 original pixel dimension (7360x4812), an 8bits TIFF file is 103Mbyte large, and the 16bits version is 206Mbytes. 444Mbytes is the size of a the 16bits TIFF file when the image is upsampled at 300DPI for a 24"x36" photo print.

[Dartmoor Dave]

I'm finding this a fascinating and thought provoking discussion about a subject I've never given much thought to. Just the sort of thing that makes this such a good forum.

I've always edited in 16 bit sRGB on the basis that I'm primarily taking shots to be viewed as 8 bit jpeg, which means the shot will end up as sRGB anyway. So I've assumed that there would be no benefit to editing in a wider gamut than that. For printing I've just converted to the ICC profile provided by the online print company I use (DSCL), then soft-proofed and sent it off, and I've always been happy with the results.

This thread is making me think that I should switch to editing in at least AdobeRGB, but here's my question: Will I see any colour shift when I finally convert from AdobeRGB in Photoshop to sRGB jpeg for general viewing on screen? My assumption is that I will because I'm re-rendering from a bigger colour space into a smaller one, and since I'm very sensitive to colour rendering that's making me nervous.

I'll try to find time to re-edit some old raw files using AdobeRGB and see for myself what happens when I finally convert to sRGB, but in the meantime I'd be very grateful for any advice about whether there will or won't be any visible colour shift.

[biz-engineer]

I've always edited in 16 bit sRGB on the basis that I'm primarily taking shots to be viewed as 8 bit jpeg, which means the shot will end up as sRGB anyway.

Well, the bit depth and color space are independant. It is possible to have image data coded within an sRGB or AdobeRGB or whatever fancy color space, with 16bits per channel, or 8bits per channel. Although Silkypix isn't that well featured on the matter, the documentation clearly explain that selecting Adobe RGB for 8bits JPEG export create less smooth tone transitions than using sRGB.

Now I imagine I'd buy this super expensive Fuji GFX100 because I want the ultimate image quality (which would justify that much money spent) while I'd actually cut off some colors out of well saturated color images in to sRGB JPEGs because exporting the GFX100 file as 16bits TIFF (Adobe RGB or ProPHoto) would just be insane *. Such large file would make my processing laborious and it would use up so much of my storage space. Now I think our computers are not ready to deal comfortably with such large files. I guess 50Mpixels is the maximum with state of the hart PC / Mac technology. Digital cameras are ahead of computer and display tech.

(*) Insane? The photo lab say they don't accept image files larger than 650Mbytes