If I open a 16 Mpix jpg image as base layer in PL, when I save as a .pld file the file size is comparable to the original .jpg.
Now, if I change the layer type from RGB to CMYK and then save again as .pld, I got a significant increase in size (6 times bigger).
If I then save this back to .jpg, the jpg file is also 6 times bigger than the original ...
Why ?
Original.jpg = 5831 Kb
Original.pld = 5928 Kb
Original_CMYK.pld = 36988 Kb
Original_CMYK.jpg = 31865 Kb
Can you explain ?
Have a nice week-end.
Philippe
CMYK strange findings
-
- Mitglied
- Beiträge: 171
- Registriert: Do 28 Mai 2015 18:00
- Wohnort: Belgium
-
- Mitglied
- Beiträge: 564
- Registriert: Mo 05 Dez 2016 08:33
Re: CMYK strange findings
JPEG is not a valid format for CMYK images.
JPEG is RGB, that means 3 color channels and a more or less high compression factor.
PLD, TIFF and PNG are valid formats for CMYK and — as the name implies — feature one more color channel which adds bits and bytes.
PLD, TIFF and PNG store 100% of everything: each pixel, color, layers, color profiles.
PLD, TIFF and PNG can use 24 bit (3 or 4 colors x 8 bit per color) for color or 48 bit (3 or 4 colors x 16 bit per color) or even 3 x 32 bit per color. JPEG is limited to 24 bit color depth. Depending on the compression ratio JPEG doesn't store the values for each pixel, but a cluster of pixels.
Chances are that your JPEG is 72 dpi, while the PLD or TIFF or PNG use 300 dpi, because they are for printing purposes. Some JPEGs store the original resolution, and when converted, that one is used.
More info: https://www.cambridgeincolour.com/tutor ... etypes.htm
and here: https://www.richardphotolab.com/blog/po ... hers-guide
JPEG is RGB, that means 3 color channels and a more or less high compression factor.
PLD, TIFF and PNG are valid formats for CMYK and — as the name implies — feature one more color channel which adds bits and bytes.
PLD, TIFF and PNG store 100% of everything: each pixel, color, layers, color profiles.
PLD, TIFF and PNG can use 24 bit (3 or 4 colors x 8 bit per color) for color or 48 bit (3 or 4 colors x 16 bit per color) or even 3 x 32 bit per color. JPEG is limited to 24 bit color depth. Depending on the compression ratio JPEG doesn't store the values for each pixel, but a cluster of pixels.
Chances are that your JPEG is 72 dpi, while the PLD or TIFF or PNG use 300 dpi, because they are for printing purposes. Some JPEGs store the original resolution, and when converted, that one is used.
More info: https://www.cambridgeincolour.com/tutor ... etypes.htm
and here: https://www.richardphotolab.com/blog/po ... hers-guide
Nur wenige wissen, wie viel man wissen muss, um zu wissen, wie wenig man weiss.
Only few know how much you have to know to know how little you know.
— Werner Heisenberg [German theoretical physicist]
Only few know how much you have to know to know how little you know.
— Werner Heisenberg [German theoretical physicist]
-
- Mitglied
- Beiträge: 1525
- Registriert: Mo 23 Dez 2019 15:21
- Wohnort: Ukraine
Re: CMYK strange findings
To clarify some mystification from "experts":
JPEG is just a compression format. It can handle RGB CMYK Grayscale models and any color space and DPI that user will select.
It is 8bit only and compressed, but at higher quality of compression is visually lossless. 8 bit is more like delivery format but it may be enough until you work in linear log gamma and wide color spaces. CMYK is not a wide color space but if possible it is always better use 16 bit source to avoid possible banding issues during image editing.
JPEG XR is nice, fast and friendly to PLD image format that support compression and 16 bit depth. See some tests here https://www.pl32.com/forum3/viewtopic.php?f=3&t=6299
Now back to question:
PLD file can handle internally original file format unchanged in very smart way. So if you import JPEG it attempt to keep original bit depth and JPEG compression inside PLD file until you change something in really fundamental, like RGB to CMYK convert or bit depth convert. When you transform color model to CMYK it just rebuild source file and start to use default lossless PNG compression. That's why you see changes file size.
There is also Layout->Image->JPEG Compression option to manually change compression for JPEG sources inside PLD files, but it is better don't touch that option until you need to shrink file size and lower quality for some reason.
JPEG is just a compression format. It can handle RGB CMYK Grayscale models and any color space and DPI that user will select.
It is 8bit only and compressed, but at higher quality of compression is visually lossless. 8 bit is more like delivery format but it may be enough until you work in linear log gamma and wide color spaces. CMYK is not a wide color space but if possible it is always better use 16 bit source to avoid possible banding issues during image editing.
JPEG XR is nice, fast and friendly to PLD image format that support compression and 16 bit depth. See some tests here https://www.pl32.com/forum3/viewtopic.php?f=3&t=6299
Now back to question:
PLD file can handle internally original file format unchanged in very smart way. So if you import JPEG it attempt to keep original bit depth and JPEG compression inside PLD file until you change something in really fundamental, like RGB to CMYK convert or bit depth convert. When you transform color model to CMYK it just rebuild source file and start to use default lossless PNG compression. That's why you see changes file size.
There is also Layout->Image->JPEG Compression option to manually change compression for JPEG sources inside PLD files, but it is better don't touch that option until you need to shrink file size and lower quality for some reason.
PhotoLine UI Icons Customization Project: https://www.pl32.com/forum3/viewtopic.php?f=3&t=6302
-
- Mitglied
- Beiträge: 564
- Registriert: Mo 05 Dez 2016 08:33
Re: CMYK strange findings
OK, you claim that CMYK JPEG is suited for printing. Would you please be so kind and give me the brand name of one single offset printing RIP that accepts and handles CMYK JPEG files?
Would you please post a link to a CCITT document where it specifies that CMYK in JPEG files can be printed with a CMYK (offset) print process?
You claim that TIFF, PNG and PLD are not suited for wide color spaces. Would you please be so kind and explain why not? If I use »ProPhoto«, »Adobe Wide« or »ECI v2« and then convert the file to CMYK, the wide color space is retained and will print depending on the paper used (glossy material shows more color depth). However, it is recommended for fidelity reasons to use 16/48 bit when using CMYK, because only TIFF, PNG and PLD (or even PSD) can handle this information absolutely lossless. A wide color space with a limited bit depth like in JPEG doesn't make any sense at all.
It is obvious that you don't know the difference between an additive and a subtractive process. The world is printing with 16/48 files for very specific reasons. It seems you have never been involved in a print project, otherwise you would not make these crude and misleading statements.
Some extensive information about i.e. the ECI CMYK and ICC color profiles is located here: http://www.eci.org/_media/downloads/eci ... _1_eng.pdf
This document clarifies everything.
Would you please post a link to a CCITT document where it specifies that CMYK in JPEG files can be printed with a CMYK (offset) print process?
You claim that TIFF, PNG and PLD are not suited for wide color spaces. Would you please be so kind and explain why not? If I use »ProPhoto«, »Adobe Wide« or »ECI v2« and then convert the file to CMYK, the wide color space is retained and will print depending on the paper used (glossy material shows more color depth). However, it is recommended for fidelity reasons to use 16/48 bit when using CMYK, because only TIFF, PNG and PLD (or even PSD) can handle this information absolutely lossless. A wide color space with a limited bit depth like in JPEG doesn't make any sense at all.
It is obvious that you don't know the difference between an additive and a subtractive process. The world is printing with 16/48 files for very specific reasons. It seems you have never been involved in a print project, otherwise you would not make these crude and misleading statements.
Some extensive information about i.e. the ECI CMYK and ICC color profiles is located here: http://www.eci.org/_media/downloads/eci ... _1_eng.pdf
This document clarifies everything.
Nur wenige wissen, wie viel man wissen muss, um zu wissen, wie wenig man weiss.
Only few know how much you have to know to know how little you know.
— Werner Heisenberg [German theoretical physicist]
Only few know how much you have to know to know how little you know.
— Werner Heisenberg [German theoretical physicist]
-
- Mitglied
- Beiträge: 171
- Registriert: Do 28 Mai 2015 18:00
- Wohnort: Belgium
Re: CMYK strange findings
You are right Shijan. JPEG supports CMYK.
My last saved file "Original_CMYK.jpg" is a CMYK model file.
You might wonder why I am changing color model.
Nothing to do with printing or color space.
I recently took portraits of two girls. One clear skin Caucasian (with a little sun burn) together wit her Asian friend.
I had a hard time fine tuning skin tones.
I learned that it is a lot easier in CMYK model because the axis are more "independent".
You can change "Cyan" without having to adjust/compensate on the other channels.
Thanks Shijan for your clarification and contribution.
Best regards.
Philippe
-
- Mitglied
- Beiträge: 1525
- Registriert: Mo 23 Dez 2019 15:21
- Wohnort: Ukraine
Re: CMYK strange findings
1. I didn't claim that TIFF, PNG and PLD are not suited for wide color spaces.der_fotograf hat geschrieben: ↑So 18 Okt 2020 09:24 You claim that TIFF, PNG and PLD are not suited for wide color spaces. Would you please be so kind and explain why not? If I use »ProPhoto«, »Adobe Wide« or »ECI v2« and then convert the file to CMYK, the wide color space is retained and will print depending on the paper used (glossy material shows more color depth). However, it is recommended for fidelity reasons to use 16/48 bit when using CMYK, because only TIFF, PNG and PLD (or even PSD) can handle this information absolutely lossless. A wide color space with a limited bit depth like in JPEG doesn't make any sense at all.
It is obvious that you don't know the difference between an additive and a subtractive process. The world is printing with 16/48 files for very specific reasons. It seems you have never been involved in a print project, otherwise you would not make these crude and misleading statements.
2. Question was not about printing.
PhotoLine UI Icons Customization Project: https://www.pl32.com/forum3/viewtopic.php?f=3&t=6302
-
- Mitglied
- Beiträge: 1525
- Registriert: Mo 23 Dez 2019 15:21
- Wohnort: Ukraine
Re: CMYK strange findings
I don't use CMYK for many reasons but probably some adjustments may work better in this model. Transformation from RGB to CMYK model is a lossy process if your source use sRGB color space. A lot of saturation will be clipped. To transform from RGB to CMYK without colors loss you should use at least Adobe RGB color space as starting point. And you need to do the same when you back from CMYK to RGB. CMYK -> AdobeRGB -> sRGB for web delivery. Even so you will also lost a lot of colors because CMYK model use rather tiny color space.PhilM hat geschrieben: ↑So 18 Okt 2020 12:45 You might wonder why I am changing color model.
Nothing to do with printing or color space.
I recently took portraits of two girls. One clear skin Caucasian (with a little sun burn) together wit her Asian friend.
I had a hard time fine tuning skin tones.
I learned that it is a lot easier in CMYK model because the axis are more "independent".
You can change "Cyan" without having to adjust/compensate on the other channels.
CMYK used only for offset printing process for mass magazines or books. All laser or hybrid photo lab photo printers use RGB source and transform it directly to their native printing color space. This is another reason to use large RGB color spaces from start.
I can only suggest to work in wide color space like ProPhotoRGB and in 16 bit from start and avoid additional transformations to CMYK. In most cases color problems and saturation clipping during color correction are caused by too small sRGB color space.
Also you may just try to switch color model in individual PhotoLine tools to make them response in different way.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
PhotoLine UI Icons Customization Project: https://www.pl32.com/forum3/viewtopic.php?f=3&t=6302
-
- Mitglied
- Beiträge: 564
- Registriert: Mo 05 Dez 2016 08:33
Re: CMYK strange findings
So you want to say that 281.474.976.710.656 shades/nuances of color in a 16/48 bit RGB image are not sufficient for you to get the correct colors in your portraits?
I can't believe it. Maybe you should update your imaging process, get a new sensor or start painting with water colors.
I can't believe it. Maybe you should update your imaging process, get a new sensor or start painting with water colors.
Nur wenige wissen, wie viel man wissen muss, um zu wissen, wie wenig man weiss.
Only few know how much you have to know to know how little you know.
— Werner Heisenberg [German theoretical physicist]
Only few know how much you have to know to know how little you know.
— Werner Heisenberg [German theoretical physicist]
-
- Mitglied
- Beiträge: 171
- Registriert: Do 28 Mai 2015 18:00
- Wohnort: Belgium
Re: CMYK strange findings
Hi Shijan,
You are right, CMYK gamut is smaller than sRGB and Adobe.
The saturation clipping is clearly perceptible when you compare side-by-side the original RGB with the converted CMYK.
As far as using Prophoto, I don't.
My camera produces Adobe RGB images.
And my screen display gamut is somewhere between Adobe and sRGB, nearer to sRGB than Adobe.
So I don't see the effect of my post-process on the most saturated colors.
My printer is an Epson R2000 (near to Adobe gamut).
Thanks again for you contribution.
Best regards
Philippe