SRBG, Adobe RGB, What to use ?

[Patrick Op de Beeck]

On the my Lumix is the choice between Adobe RGB and sRGB.

What are the advantages/disadvantages of both settings ?
What should I use with Digicam ?
Does it have any effect on RAW pictures ?

Patrick  
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Remco Viëtor]

on Sunday 26 June 2011, Patrick Op de Beeck wrote:

> On the my Lumix is the choice between Adobe RGB and sRGB.
>
> What are the advantages/disadvantages of both settings ?
> What should I use with Digicam ?
> Does it have any effect on RAW pictures ?
>
> Patrick  
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

To start with the last question: No, your choice of colour space doesn't have
an effect on your RAW files.
And, You can use both with Digikam.  (that was easy ;) )

Now for the harder bit:

The main difference between the 2 colour spaces is that Adobe RGB has a larger
gamut (can express more colours) than sRGB. BUT: most screens and printers can
only use/display sRGB, so an image using Adobe RGB will not display/print
correctly in such a case. At best you will get a transformation to sRGB 'on
the fly', at worst your images will look very flat and dull.

If, like most people, you have your photos printed commercially, your best
(only?) bet is to stick to sRGB.

Only if you print your images yourself and you have a printer capable of
printing Adobe RGB, you could study the differences and decide what to use.

The above is just a very quick answer, you'll need to search for more in-depth
texts to really understand what's going on.

Remco
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Rinus]

Common usage is sRGB. It is safe for posting on the web, and gives the best chance that all colors are repodused the same on pc, printer etc. If you know what you are doing you can experiment with other colorspaces, but confusion is quickly introduced, so to start with choose everywhere in workflow sRGB. It will not effect the raw images itself, only the way you see them.

Have a nice day,
Rinus

Patrick Op de Beeck <[hidden email]>schreef:

>On the my Lumix is the choice between Adobe RGB and sRGB.
>
>What are the advantages/disadvantages of both settings ?
>What should I use with Digicam ?
>Does it have any effect on RAW pictures ?
>
>Patrick  
>_______________________________________________
>Digikam-users mailing list
>[hidden email]
>https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Rinus]

sorry Remco, you message wasn't there when I started typing. Your's was anyway better than mine.
Have a nice day,
Rinus

Remco Viëtor <[hidden email]>schreef:

>on Sunday 26 June 2011, Patrick Op de Beeck wrote:
>> On the my Lumix is the choice between Adobe RGB and sRGB.
>>
>> What are the advantages/disadvantages of both settings ?
>> What should I use with Digicam ?
>> Does it have any effect on RAW pictures ?
>>
>> Patrick  
>> _______________________________________________
>> Digikam-users mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users
>>
>
>To start with the last question: No, your choice of colour space doesn't have
>an effect on your RAW files.
>And, You can use both with Digikam.  (that was easy ;) )
>
>Now for the harder bit:
>
>The main difference between the 2 colour spaces is that Adobe RGB has a larger
>gamut (can express more colours) than sRGB. BUT: most screens and printers can
>only use/display sRGB, so an image using Adobe RGB will not display/print
>correctly in such a case. At best you will get a transformation to sRGB 'on
>the fly', at worst your images will look very flat and dull.
>
>If, like most people, you have your photos printed commercially, your best
>(only?) bet is to stick to sRGB.
>
>Only if you print your images yourself and you have a printer capable of
>printing Adobe RGB, you could study the differences and decide what to use.
>
>The above is just a very quick answer, you'll need to search for more in-depth
>texts to really understand what's going on.
>
>Remco
>_______________________________________________
>Digikam-users mailing list
>[hidden email]
>https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Martin (KDE)]

Am Sonntag, 26. Juni 2011 schrieb Remco Viëtor:

> on Sunday 26 June 2011, Patrick Op de Beeck wrote:
> > On the my Lumix is the choice between Adobe RGB and sRGB.
> >
> > What are the advantages/disadvantages of both settings ?
> > What should I use with Digicam ?
> > Does it have any effect on RAW pictures ?
> >
> > Patrick
> > _______________________________________________
> > Digikam-users mailing list
> > [hidden email]
> > https://mail.kde.org/mailman/listinfo/digikam-users
>
> To start with the last question: No, your choice of colour space
> doesn't have an effect on your RAW files.
> And, You can use both with Digikam.  (that was easy ;) )
>
> Now for the harder bit:
>
> The main difference between the 2 colour spaces is that Adobe RGB
> has a larger gamut (can express more colours) than sRGB. BUT: most
> screens and printers can only use/display sRGB, so an image using
> Adobe RGB will not display/print correctly in such a case. At best
> you will get a transformation to sRGB 'on the fly', at worst your
> images will look very flat and dull.

Just some small additions: The advantage of AdobeRGB only depends on
the output system supporting colour management or not. This is very
unlikely for most "normal" users and many printing labs. There are
some out there doing a consequent colour management. And there are
some users using wide gamut displays and colour management. They can
use AdobeRGB and they can see the benefits of if (if available). Not
every picture needs a wider gamut.

A big disadvantage of AdobeRGB (and other colour spaces) with jpeg
files is the limited range of available bits. For standard jpeg you
have 8 bits per colour channel (RGB). The wider your gamut the bigger
the steps between two values.

If you use a colour space with double range of blue compared to sRGB
(as an example) you still have only 256 different types of blue. If
your photo uses the complete range your are fine. If your photo uses
only the range defined in sRGB you have only 128 different steps of
blue So you loose quality. (This assumes the colour spaces are linear
which they are not but it is easier to compare).

AdobeRGB is only a little bit bigger than sRGB so the advantage is
only limited. If you need bigger colour spaces shoot raw photos and
use a really big colour space (ProPhoto or similar) with at least 16
bit.

>
> If, like most people, you have your photos printed commercially,
> your best (only?) bet is to stick to sRGB.
>
> Only if you print your images yourself and you have a printer
> capable of printing Adobe RGB, you could study the differences and
> decide what to use.

Or you can be sure the photo lab uses colour management.

Martin

>
> The above is just a very quick answer, you'll need to search for
> more in-depth texts to really understand what's going on.
>
> Remco
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Patrick Op de Beeck]

Thanks to Remco and Rinus for answering my question.
I shall stick with sRGB then.

Patrick
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Patrick Op de Beeck]

Martin,

you speak of 16bit and Profoto or simular but is this available under
GNU/LINUX ?

Since I like photgraphy, and I shoot also in 3D I am wondering how far you can
get on a GNU/Linux system with the quality.

A lot of people are focused on the kernel and windowmanagers but in the
applicationprogramming area we have still a lot to catch up.

I would like that for example digikam can also handle
3D photographs. I took several  3D photographs with my Lumix GH2  and saw it
on a P50VT30 plasma television. I must say that the images are stunning and
not compare to viewmasters 3D from the previous century.
These 3D images are really good. And soon I think they will be as normal a a
tv for us. It's one of those revolutions that will stay. (B/W TV, colour TV,
Stereo, THX sound, Flatscreen TV and now  3D. The standard is recently fixed so
there is no excuse anymore not to incorporate it.

Although I can imagine 'photoshopping' will be much more difficult ;-)

Patrick

PS thanks for the good explication.

> unlikely for most "normal" users and many printing labs. There are
> some out there doing a consequent colour management. And there are
> some users using wide gamut displays and colour management. They can
> use AdobeRGB and they can see the benefits of if (if available). Not
> every picture needs a wider gamut.
>
> A big disadvantage of AdobeRGB (and other colour spaces) with jpeg
> files is the limited range of available bits. For standard jpeg you
> have 8 bits per colour channel (RGB). The wider your gamut the bigger
> the steps between two values.

> Or you can be sure the photo lab uses colour management.
>
> Martin

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Martin (KDE)]

Am 26.06.2011 21:36, schrieb Patrick Op de Beeck:
> Martin,
>
> you speak of 16bit and Profoto or simular but is this available under
> GNU/LINUX ?

In general yes. You can use ProPhoto with 16 bit. Digikam is capable of
handling this. Krita can handle this as well.

Sadly one of the most important graphics software on Linux is not. Gimp
can handle 8 bit depth only (currently). But it is very good in colour
management handling.

>
> Since I like photgraphy, and I shoot also in 3D I am wondering how far you can
> get on a GNU/Linux system with the quality.

I don't know of any 3D software for Linux. As I don't use 3D photos my
knowledge on this is limited. I once shot stereo photos in the old days
with analogue film cameras and was very pleased with the results. But I
never tried with digital.

>
> A lot of people are focused on the kernel and windowmanagers but in the
> applicationprogramming area we have still a lot to catch up.
>

This is a mixed bag. Without a good base you can not write good and easy
to maintain software. There were many good software out there which are
lost as no one is interested to maintain. And with a cluttered GUI and
desktop no one will use the software.

> I would like that for example digikam can also handle
> 3D photographs. I took several  3D photographs with my Lumix GH2  and saw it
> on a P50VT30 plasma television. I must say that the images are stunning and
> not compare to viewmasters 3D from the previous century.
> These 3D images are really good. And soon I think they will be as normal a a
> tv for us. It's one of those revolutions that will stay. (B/W TV, colour TV,
> Stereo, THX sound, Flatscreen TV and now  3D. The standard is recently fixed so
> there is no excuse anymore not to incorporate it.

That may be true, but it has to be done by someone who has a major
interest in it. Four years ago there were only two usable (almost)
pieces of software for raw photo development on linux. Now you can chose
out of several very interesting (and very good btw.) programs. Time will
tell if 3D is as important as raw development.

Martin

>
> Although I can imagine 'photoshopping' will be much more difficult ;-)
>
> Patrick
>
> PS thanks for the good explication.
>
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Andreas T. Ege]

Hi there

Am 27 Jun 2011 um 06:56 schrieb "Martin \(KDE\)" <[hidden email]>:

> Am 26.06.2011 21:36, schrieb Patrick Op de Beeck:
>> Martin,
>>
>> you speak of 16bit and Profoto or simular but is this available under
>> GNU/LINUX ?
>
> In general yes. You can use ProPhoto with 16 bit. Digikam is capable of
> handling this. Krita can handle this as well.
>
> Sadly one of the most important graphics software on Linux is not. Gimp
> can handle 8 bit depth only (currently). But it is very good in colour
> management handling.

Cinepaint can handle 16bit.
>

--
Andreas Ege

24 The Birches
Shobdon
HR6 9NG

Mobile: [phone]
Phone: [phone]

Mail: [hidden email]
http://spheniscid.net
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Sebastian Schubert-2]

On Sonntag 26 Juni 2011 19:31:14 Martin (KDE) wrote:
 

> A big disadvantage of AdobeRGB (and other colour spaces) with jpeg
> files is the limited range of available bits. For standard jpeg you
> have 8 bits per colour channel (RGB). The wider your gamut the bigger
> the steps between two values.
>
> If you use a colour space with double range of blue compared to sRGB
> (as an example) you still have only 256 different types of blue. If
> your photo uses the complete range your are fine. If your photo uses
> only the range defined in sRGB you have only 128 different steps of
> blue So you loose quality. (This assumes the colour spaces are linear
> which they are not but it is easier to compare).
>
> AdobeRGB is only a little bit bigger than sRGB so the advantage is
> only limited.

How severe is the problem of only 8bit in jpg using AdobeRGB? My monitor
shows AdobeRGB almost completely, so I wanted to use AdobeRGB jpgs (so
far only browsing and creating RAW development settings).

Cheers
Sebastian

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[david-vj]

CONTENTS DELETED

The author has deleted this message.

[Ignatius Reilly]

Hello,

I'm in the market for upgrading my monitor. Main requirement is to do
photography.

I work on Ubuntu:
- Digikam
- Rawstudio
- Gimp

I shoot raw and work mostly in 16 bit (GIMP 2012?)

Budget <1000 EUR

Any advice will be appreciated!

Thanks
Ignatius
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Rinus]

Although I as a photographer are satisfied with a far cheaper model for
those who are going realy serious there is:
http://www.eizo.com/global/products/coloredge/index.html
don´t know nothing about the prices.

Rinus

Op 27-06-11 19:03, Ignatius Reilly schreef:

> Hello,
>
> I'm in the market for upgrading my monitor. Main requirement is to do
> photography.
>
> I work on Ubuntu:
> - Digikam
> - Rawstudio
> - Gimp
>
> I shoot raw and work mostly in 16 bit (GIMP 2012?)
>
> Budget<1000 EUR
>
> Any advice will be appreciated!
>
> Thanks
> Ignatius
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Remco Viëtor]

on Monday 27 June 2011, David Vincent-Jones wrote:
> There can be substantial losses between the 16 bit data of a raw file
> and an 8 bit version. Compare the histograms of a converted 16 bit file
> and the 8 bit version, they will frequently show 'gaps' in the data post
> conversion, especially if any data stretching has been done. Those gaps
> will invariably show as banding on a finished, decent sized, print.

Fiirst, a correction: to my knowledge, RAW formats are NEVER 16-bit...
Most commonly, the data is 12 bit, and some high-end cameras use 14 bit.

Next, if you convert a 16-bit format to an 8-bit format, of course there's
information loss. However, a histogram that shows no gaps for a 16-bit image,
will NOT show gaps for the corresponding image in 8-bit format. Gaps could
possibly occur if there's another conversion done while converting to 8-bit
e.g. a colour space conversion after the conversion to 8-bit format.

Of course, if you start editing the converted 8-bit image, all bets are off...

> Add to this the irretrievable data losses incurred in creating the 8 bit
> jpg format. One cannot, for instance, reopen a jpg file and tweek the
> image later without possible serious information loss. IMHO the whole
> jpg scene is one to avoid. jpg is a nice compact format for snapshots
> but one that I would advise others to avoid at any cost for serious
> photography.

Here also I disagree:
properly encoded JPEG* is a good format for _finished_ images (note the
"finished"!), which by definition don't need additional editing or
conversions. For such images it is the most compact way of storing the
information, with no visible artifacts. It's also the format most commonly
accepted for printing images (the alternative would be TIFF, with all the
problems that format has due to its different dialects).

To be complete, I agree that you should never use jpeg for images that need
further tweaking. Editing jpeg files can lead to very visible artifacts. For
any image that might need further work (including changing size) I use either
PNG (16-bit or 8-bit), or the gimp's native format.

And for what it's worth, I know of some photographers that produce outstanding
work with 8-bit formats all along their workflow, using the GIMP for their
'detailed' processing, and JPEG as their final format for display or printing.

Remco

*i.e. picking the optimal quality setting for the purpose of the file, and
NEVER re-encode a jpeg.

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Rinus]

And for what it's worth, I know of some photographers that produce
outstanding
> work with 8-bit formats all along their workflow, using the GIMP for their
> 'detailed' processing, and JPEG as their final format for display or printing.
>
> Remco
I completely agree with that. Itś almost the same discussion as if you
can hear difference between audio cd and audio dvd, I certainly can not,
and I wonder on what media and for who it is possible to see difference
between 8 and 16 bit images al long as one is used consequently during
workflow, but of course it is just one opinion.

Related to the discusions going on, this could be interesting:
http://mail.kde.org/pipermail/digikam-users/2011-March/012566.html

Rinus

> *i.e. picking the optimal quality setting for the purpose of the file, and
> NEVER re-encode a jpeg.
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Martin (KDE)]

Am Montag, 27. Juni 2011 schrieb Sebastian Schubert:

> On Sonntag 26 Juni 2011 19:31:14 Martin (KDE) wrote:
> > A big disadvantage of AdobeRGB (and other colour spaces) with
> > jpeg files is the limited range of available bits. For standard
> > jpeg you have 8 bits per colour channel (RGB). The wider your
> > gamut the bigger the steps between two values.
> >
> > If you use a colour space with double range of blue compared to
> > sRGB (as an example) you still have only 256 different types of
> > blue. If your photo uses the complete range your are fine. If
> > your photo uses only the range defined in sRGB you have only 128
> > different steps of blue So you loose quality. (This assumes the
> > colour spaces are linear which they are not but it is easier to
> > compare).
> >
> > AdobeRGB is only a little bit bigger than sRGB so the advantage
> > is only limited.
>
> How severe is the problem of only 8bit in jpg using AdobeRGB? My
> monitor shows AdobeRGB almost completely, so I wanted to use
> AdobeRGB jpgs (so far only browsing and creating RAW development
> settings).

Most likely you will not notice it. the difference is visible in
saturated colour only. If you are able to read german please take a
look at http://foto.beitinger.de/adobe_rgb/index.html This article
shows advantages and disadvantages of sRGB-AdobeRGB very well.

And: the AdobeRGB does not help that much if your printing-lab can not
handle the AdobeRGB range.

To my point of view the best is to use the raw data as long as
possible. If you need to postprocess your photos, use a 16bit ProPhoto
colour space in i.e. png format. At the end of your process, convert
the photo to the medium and colour space your enduser (printing-lab,
webpage ...) can handle best. For web pages this will most likely be
sRGB and jpeg as well as for printing labs (except for very large
prints). This is a similar way Adobes Lightroom is working.

I heard rumours that some users do not use integer base photo formats
but floating point one instead. At a first glance this sounds
ridiculous. But you will get an infinite amount of colours. The next
round will come: integer vs. float.

Martin

>
> Cheers
> Sebastian

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Rinus]

It seems the link in the message is broken by the archive, hier is the
correct one:
http://ninedegreesbelow.com/2011/imaging/color-management-tutorial/color-management-tutorial-table-of-contents.html
Op 27-06-11 19:59, sleepless schreef:

> And for what it's worth, I know of some photographers that produce
> outstanding
>> work with 8-bit formats all along their workflow, using the GIMP for their
>> 'detailed' processing, and JPEG as their final format for display or printing.
>>
>> Remco
> I completely agree with that. Itś almost the same discussion as if you
> can hear difference between audio cd and audio dvd, I certainly can not,
> and I wonder on what media and for who it is possible to see difference
> between 8 and 16 bit images al long as one is used consequently during
> workflow, but of course it is just one opinion.
>
> Related to the discusions going on, this could be interesting:
> http://mail.kde.org/pipermail/digikam-users/2011-March/012566.html
>
> Rinus
>
>> *i.e. picking the optimal quality setting for the purpose of the file, and
>> NEVER re-encode a jpeg.
>>
>> _______________________________________________
>> Digikam-users mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users
>>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Martin (KDE)]

Am Montag, 27. Juni 2011 schrieb sleepless:

> And for what it's worth, I know of some photographers that produce
> outstanding
>
> > work with 8-bit formats all along their workflow, using the GIMP
> > for their 'detailed' processing, and JPEG as their final format
> > for display or printing.
> >
> > Remco
>
> I completely agree with that. Itś almost the same discussion as if
> you can hear difference between audio cd and audio dvd, I
> certainly can not,

Of course you can, everybody can. Take a cruel record pressed on CD
and a qualified re engineered one on DVD-Audio and you will hear the
difference in CD and DVD-Audio. I must confess that it works the other
way around as well.

Honestly, this is more of the part what do I need and what do I want.
I for my part can perfectly live with sRGB on final jpegs. And my
"old" (this sound strange to me, calling a four year old photo camera
old - I used my really old Olympus OM-4Ti more than 10 years and the
OM-2 even longer) EOS 30D may be limited but I can make great photos
with it.

> and I wonder on what media and for who it is
> possible to see difference between 8 and 16 bit images al long as
> one is used consequently during workflow, but of course it is just
> one opinion.

And this opinion the the only one that counts for your work. If
someone can proof your work to be better with better technical setup
it may be a good idea to change. But this is still your choice.

Regards
Martin

>
> Related to the discusions going on, this could be interesting:
> http://mail.kde.org/pipermail/digikam-users/2011-March/012566.html
>
> Rinus
>
> > *i.e. picking the optimal quality setting for the purpose of the
> > file, and NEVER re-encode a jpeg.
> >
> > _______________________________________________
> > Digikam-users mailing list
> > [hidden email]
> > https://mail.kde.org/mailman/listinfo/digikam-users
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Rinus]

Op 27-06-11 20:32, Martin (KDE) schreef:

> Am Montag, 27. Juni 2011 schrieb sleepless:
>> And for what it's worth, I know of some photographers that produce
>> outstanding
>>
>>> work with 8-bit formats all along their workflow, using the GIMP
>>> for their 'detailed' processing, and JPEG as their final format
>>> for display or printing.
>>>
>>> Remco
>> I completely agree with that. Itś almost the same discussion as if
>> you can hear difference between audio cd and audio dvd, I
>> certainly can not,
> Of course you can, everybody can. Take a cruel record pressed on CD
> and a qualified re engineered one on DVD-Audio and you will hear the
> difference in CD and DVD-Audio. I must confess that it works the other
> way around as well.
>
> Honestly, this is more of the part what do I need and what do I want.
> I for my part can perfectly live with sRGB on final jpegs. And my
> "old" (this sound strange to me, calling a four year old photo camera
> old - I used my really old Olympus OM-4Ti more than 10 years and the
> OM-2 even longer) EOS 30D may be limited but I can make great photos
> with it.
>
>> and I wonder on what media and for who it is
>> possible to see difference between 8 and 16 bit images al long as
>> one is used consequently during workflow, but of course it is just
>> one opinion.
> And this opinion the the only one that counts for your work. If
> someone can proof your work to be better with better technical setup
> it may be a good idea to change. But this is still your choice.

absolutely right Martin. I have seen stunning pictures taken with a
praktika (any living being out there who knows what that is) and I know
people carrying around kilos of hightech but hardly able to produce a
decent picture. So what I try to point out is first of all it´s being at
the right time at the right place, and your eyes.  Hightech can wash the
charm out of your pictures. Photography has never been as popular as
since whe started to take realy bad pictures with our phones. How came
we so obsessed with better equipment. It was because someone succeeded
to let us believe that we needed it to be able to make nice pictures.

Rinus

> Regards
> Martin
>
> ce
>> Related to the discusions going on, this could be interesting:
>> http://mail.kde.org/pipermail/digikam-users/2011-March/012566.html
>>
>> Rinus
>>
>>> *i.e. picking the optimal quality setting for the purpose of the
>>> file, and NEVER re-encode a jpeg.
>>>
>>> _______________________________________________
>>> Digikam-users mailing list
>>> [hidden email]
>>> https://mail.kde.org/mailman/listinfo/digikam-users
>> _______________________________________________
>> Digikam-users mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-users
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Elle Stone]

Sorry to be so late posting to this thread. Sleepless, thank you for
pointing to my color management tutorial. Hopefully the following
might be useful:

"Tones for editing": imagine that you have 256 pebbles (8-bits), each
1 inch across, laid out so they touch each other. The total length of
your line of pebbles is 256 inches. Imagine that those pebbles are
then spread apart to fill a line that is 700 inches long. Now there
are gaps between the pebbles. Imagine instead that you have 65536
pebbles (16-bits). The gaps are smaller. (Careful, this analogy can
only take you so far.)

These "gaps between the pebbles" represents the effect of using a
larger color space (AdobeRGB) compared to using a smaller color space
(sRGB).

The gaps between the pebbles also represent the effect of using curves
to increase contrast between shadows and highlights - you spread the
pebbles farther apart regardless of what color space you are using.

sRGB and AdobeRGB are both RGB color spaces. RGB color spaces are each
defined by a red, a blue, and a green "primary" which dictate the
reddest red, bluest blue, and greenest green you can get from each
respective color space. (See
http://ninedegreesbelow/2011/imaging/color-management-tutorial/all-the-colors.html
for details.)

The red and blue primaries in sRGB and AdobeRGB are exactly the same.
Only the green primary differs. (See
http://ninedegreesbelow/2011/imaging/color-management-tutorial/pictures-of-color-spaces.html
for pictures comparing sRGB to AdobeRGB and also to a typical printer
color space and a typical camera color space.)

So the distance from reddest red to bluest blue, and also from
white/grey to reddest red and white/grey to bluest blue is the same in
sRGB and AdobeRGB. If you fill in the distance between reddest red and
bluest blue with your 256 pebbles (8 bits) or 65536 pebbles (16 bits),
the gaps between the pebbles is exactly the same for both color
spaces.

Your line of pebbles has to stretch farther in AdobeRGB to get from
reddest red to greenest green, from bluest blue to greenest green, and
from white/grey to greenest green.

So depending on how extreme of editing you plan to do, you are more
likely to get posterization, noticeable gaps between the pebbles, in
8-bits than in 16-bits, regardless of whether you are using sRGB or
AdobeRGB.

Likewise, you are more likely to get posterization in AdobeRGB than in
sRGB IF you are heavily editing areas that are predominantly green,
yellow, or cyan. Why yellow or cyan? In an RGB space, yellow is
composed of green and red - the yellowest yellow has 100% greenest
green plus 100% reddest red, and no blue at all). Pure cyan is an
equal mix of green and blue, with no red.

The sole advantage of AdobeRGB over sRGB is if your original or edited
image contains colors - certain greens, yellows, and cyans, that fall
OUTside sRGB color space and INside AdobeRGB color space.

If you want to post your AdobeRGB image to the web, you will need to
convert it to sRGB. Does this mean you have to throw all the extra
colors away? Yes, it does. But the trick is that you eliminate the
"out of gamut" colors away selectively and creatively, compromising
between conserving detail, brightness, and saturation. In short, you
use color management, specifically "soft-proofing" (which has its home
in making color conversions for printing, but applies equally well to
color conversions for display on the web) to do creative color
conversions.

See http://ninedegreesbelow/2011/imaging/color-management-tutorial/color-management-tutorial-introduction.html
and http://ninedegreesbelow/2011/imaging/color-management-tutorial/assign-assume-convert.html
for a bit more detail on the point of color management.

There is a question implicit in the above discussion regarding your
monitor profile. Every color-managed editing software that I've ever
encountered assumes that your monitor profile is sRGB UNLESS you tell
the software to use a different monitor profile.

If your monitor is not adequately characterized by sRGB, then you need
to either calibrate your monitor to match sRGB OR create and use a
monitor profile that actually characterized your monitor. Otherwise
the colors you see will be more or less wrong, depending on how poorly
your monitor "fits" sRGB.

If you are using an LCD monitor, it is NOT well-characterized by sRGB.
Why? Because sRGB describes the ideal CRT monitor in use in the
mid-1990s. And unless you have a wide-gamut LCD monitor you cannot
calibrate your LCD monitor to match sRGB primaries.

See http://ninedegreesbelow/2011/imaging/color-management-tutorial/srgb-no-color-management.html
for an example of what can happen when you "assume" your monitor is
well-characterized by sRGB.

See http://ninedegreesbelow/2011/imaging/color-management-tutorial/all-the-colors.html
and http://ninedegreesbelow/2011/imaging/color-management-tutorial/monitor-profile-calibrate-confuse.html
for more details about why sRGB is not a good monitor profile for LCD
monitors.

An aside: a 14-bit camera raw file has 16384 "pebbles" to spread
around in each Red, Blue, and Green channel, but your editing software
only does 8 or 16 bits, so you either have to collapse 16384 steps
down to 256 steps and thus throw information away, or increase it up
to 65536 steps.

A great discussion of sRGB vs. AdobeRGB can be found here:
http://www.cambridgeincolour.com/tutorials/sRGB-AdobeRGB1998.htm

For more information on the number of tones available for editing in
8-bit vs 16-bit images, see here:

http://ronbigelow.com/articles/posterization/posterization.htm
http://ronbigelow.com/articles/raw/raw.htm

Kind regards,
Elle Stone
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users