Chromaticities of digital photo-exposer
Timo Autiokari
plenty of SpectroScan measurements of it, an overview of the spectras:
http://www.aim-dtp.net/aim/temp/frontier/overview.gif plenty of
spectras them... almost artistic (so not very informative).
So I put the spectras through derivative of step response in order to
find the valleys: http://www.aim-dtp.net/aim/temp/frontier/srd.gif
The valleys appears to be at about 450nm, 550nm and 650nm that are
blue, green and red, so the actual chromaticities of the dyes then
reside somewhere on the line at the other side of the whitepoint?
I then integrated each of the spectra by CIE and took the x,y
chromaticities: http://www.aim-dtp.net/aim/temp/frontier/chroma.gif
this chart also shows the 450nm, 550nm and 650nm valley lines and the
CMY extensions to them. Because of the form of the chromaticity map (a
triangle that is very close to Trinitron primaries) I believe that the
device is doing an ICC profile conversion? Since the chromaticities of
the dyes do not correspond with this triangle (except at cyan a
little) I believe it further indicates that the gamut of this system
is limited due to the ICC profile conversion and not by the
photo-paper so some of the available gamut is not taken into use?
The main question: is there a way to calculate or even approximate the
actual gamut of this system from this source data (RGB data sent +
their spectras)?
Timo Autiokari
Roger Breton
I've profiled many Fuji Frontier devices and they don't use any ICC profile,
as far as I know -- too sophisticated for them. It may come in the future
but I think the majority of consumers are not there yet. So, all I need to
do is tell the operator NOT TO MAKE ANY COLOR CORRECTION and I am sure my
caracterization target will be printed raw. From there it's straightforward.
Roger Breton
tlianza
The Frontier is a photoprinter and there is no reason to expect that ramps
of a single "hue" will plot as a straight line. As a matter of fact, they
most certainly don't. The analysis that you doing may be of use for
additive sources, but it doesn't make any sense for a subtractive product.
Also, you didn't mention, which light source you used to apply to the
spectra before you calculated the chromaticies. This will have a large
impact on the results.
The actual description of gamut is rarely done in xy space for subtractive
products. Once again, it is completely valid for devices such as monitors,
because the chromaticities of the primaries do not change with luminance.
If you plot the chromaticities of a single color ramp from a reflective
device, you will find that there is a tendency for the chromaticity to form
a line that is curved, often with a hook. In inkjet and dyesub printers
tend to have a greater degree of nonlinearity in hue than a photographic
printer. The dyes in the photographic process tend to be very transmissive
and this helps control hue constancy.
As far as your published data, I think that you have a problem with flare or
you might not have multiplied the spectra by a light source like d50 prior
to calculating the chromaticities. It has been my experience that the
chromaticities of the RA-4 processes and output from the Frontier generally
exceed the display gamut. You might look at the data presented at
look at his description of the "BETA RGB" color space . He plots the
resultant chromaticities for a d50 illuminant and multiple media.
--
Tom Lianza
Technical Director
Sequel Imaging Inc.- A GretagMacbeth Company
25 Nashua Rd.
Londonderry, NH 03053
Timo Autiokari
>The Frontier is a photoprinter and there is no reason to expect that ramps
>of a single "hue" will plot as a straight line.
Hello Tom, I was not expecting that. What I was expecting was gamut
edges that would look like a CMY device gamut.
>As a matter of fact, they most certainly don't.
Yes, I agree fully that they should not, when it is a question of a
native CMY output device (without 3D look-up-table profiles)
>The analysis that you doing may be of use for additive sources,
>but it doesn't make any sense for a subtractive product.
Why not? The chroma map does show the device chromaticities (e.g. for
evaluating the gamut size) exactly similarly as the chroma map shows
the gamut size for additive device.
>Also, you didn't mention, which light source you used to apply to the
>spectra before you calculated the chromaticies. This will have a large
>impact on the results.
The SpectroScan says Illumination=D50 and ObserverAngle=2 so I used
CIE1931 and D50.
>The actual description of gamut is rarely done in xy space for subtractive
>products.
That may be the case but what is the reason for that?
>Once again, it is completely valid for devices such as monitors,
Why would x,y chroma map be invalid for printers?
>because the chromaticities of the primaries do not change with luminance.
Aha. But that is the very same with additive devices also. You scale
an RGB code up or down and it will sit at the very same chromaticity
point. So for example:
RGB=1,2,3
RGB=10,20,30
RGB=50,100,150
all have the very same chromaticity. In case of adobeRGB (by Absolute
Intent using Correct XYZ scaling instead Bradford etc) this point is:
x=0.186001742
y=0.211460297
Adding and removing white (light) will change the chromaticity point
(as well as per channel adjustments of course).
>As far as your published data, I think that you have a problem with flare or
>you might not have multiplied the spectra by a light source like d50 prior
>to calculating the chromaticities.
The equipment was SpectroScan in its normal controlled production
environment and I double-checked the calculations, full data is here:
http://www.aim-dtp.net/aim/temp/frontier/frontier.zip in case you want
to take a look at it. I btw updated the chroma map to show the
Trinitron primaries triangle with the Frontier gamut:
http://www.aim-dtp.net/aim/temp/frontier/chroma.gif
>It has been my experience that the chromaticities of the RA-4
>processes and output from the Frontier generally exceed the
>display gamut.
I agree fully that most if not all the papers have larger gamut than
what the Trinitron gamut is. I'm just currently inspecting an other
Frontier device and that has rather similar performance.
>You might look at the data presented at >www.brucelindbloom.com
>look at his description of the "BETA RGB" color space . He plots the
>resultant chromaticities for a d50 illuminant and multiple media.
Thank you very much the location is:
http://www.brucelindbloom.com/index.html?BetaRGB.html
These x,y plots are for film and paper.
So, above you said: [quote]The analysis that you doing may be of use
for additive sources, but it doesn't make any sense for a subtractive
product.[/quote] How come Mr Lindbloom's x,y maps for the subtractive
product now are valid.
But the data that I'm inspecting is for the Fuji Frontier + the paper
(Fuji Archive something). So the paper very likely can do better but
why is the Frontier limiting the paper performance?
I think I was not clear enough in my earlier post. What I tried to ask
was: Does my results indicate that the Fuji Frontier is doing an ICC
profile conversion over the input data? It looks to me that it does.
And my main question was if it is somehow possible to estimate the
actual device gamut from this data.
So something appears to be limiting the Frontier output, could it be
the light source(s) that it is using? Or just that it does an ICC
profile conversion?
Timo Autiokari
Gerhard Fuernkranz
Timo Autiokari wrote:
>>The Frontier is a photoprinter and there is no reason to expect that ramps
>>of a single "hue" will plot as a straight line.
>>
>>
>Hello Tom, I was not expecting that. What I was expecting was gamut
>edges that would look like a CMY device gamut.
>
Hi Timo,
did you send CMY or RGB data to the Frontier?
In the latter case I would expect the gamut to be just the intersection
of the CMY gamut with the RGB color space gamut.
Gerhard
Timo Autiokari
>did you send CMY or RGB data to the Frontier?
Hello Gerhard, the source data was RGB. It is here:
http://www.aim-dtp.net/aim/temp/frontier/frontier.zip inside the zip
is an Excel workbook, in it the input data, spectras of the printed
patches and my conversion results in XYZ and Yxy.
>In the latter case I would expect the gamut to be just the
>intersection of the CMY gamut with the RGB color space
>gamut.
Well, it seems not to be the intersection either:
http://www.aim-dtp.net/aim/temp/frontier/chroma.gif
With a very good imagination one could possibly see a hint of the
would be C, M, Y "corners" of the paper chromaticities, but they are
not true CMY corners (in that case the paper gamut would be amazingly
large) but very just slight bending.
So, are the Frontiers native CMY devices? I had the understanding that
they use lasers in the RGB space.
Timo Autiokari
Gerhard Fuernkranz
Timo Autiokari schrieb:
> So, are the Frontiers native CMY devices? I had the understanding that
> they use lasers in the RGB space.
Timo,
basically it is NOT the laser light, which you will see, when you look at the
resulting prints. What I want to say is, the resulting medium which comes out
of the printer is undoubteldly a *reflective print*, and it surely uses cyan,
magenta and yellow forming dyes and subtractive color mixing (as Tom already
explained). The lasers just expose the photo paper.
The lasers, which expose the photo paper, are of course red, green and blue.
But you MUST NOT treat these red, green and blue lasers as a "classical"
additive RGB color space. In fact, the blue laser rather represents the yellow
channel, the green laser the magenta channel, and the red laser the cyan
channel of the resulting print. Furthermore, a negative image is required to
expose photo paper, i.e. the lasers need to project a negative image on the
photo paper -- bright laser light will result in high densities, i.e. dark
colors on the print.
Concerning the workflow, IMO the color space of the RGB image you send to the
lab for printing is not at all the color space of the RGB lasers which expose
the photo paper, but just an RGB working space (maybe sRGB or similar?). Given
the large gamut of digitally printed photos (see Tom's previous posting), I
would not be surprised, if this RGB working space would be a non-neglectable
limiting factor for the overall gamut in the workflow.
Regards,
Gerhard
tlianza
Hi Timo, you wrote:
"So, above you said: [quote]The analysis that you doing may be of use
for additive sources, but it doesn't make any sense for a subtractive
product.[/quote] How come Mr Lindbloom's x,y maps for the subtractive
product now are valid."
I know that I often give you a hard time, but I wasn't giving you a hardtime
about the xy maps, it was the previous analysis where you used the
derivatives and the then derived the straight lines based upon some notion
of predominant wavelength. The only point I wanted make is that analysis
may work well with additive sources, but it is really wrong when applied to
subtractive samples. The next time, I'll try to be more clear.
The problem that I see in the data is that it doesn't "square" visually with
my outputs from a Frontier. I sent some sRGB data to a Frontier and they did
exactly what I though they should do, RGB data was mapped explicitly to the
limits of the gamut of the output material. This is EXACTLY what should be
done for subjective viewing. The sRGB gamut should be mapped to the
extremes of the RA-4 media. This will always yield a print that has very
high percieved colorfulness when viewed under Interior lighting conditions.
In my case, the Frontier output was more colorful than either the monitor or
inkjet rendering.
One of the points that folks don't seem to get is that sRGB is NOT a color
space, per se, it is a RENDERED space. In a well designed digital camera,
the reproduction gamma will be higher than 2.2-2.4 element of the spec. In
fact, it will often be upwards of 2.6 to 2.8. The colorfulness will also be
exaggerated to accomodate the loss of visual colorfulness due to the low
adapting luminance. This is the same mechanism that has made transparency
media so popular. sRGB is a horrible space in which to perform editing (a
point that Timo is constantly pointing out, although not always for the
right reasons....) , but not because of the gamma, but the unknown rendering
intent and subjective changes. The final reproduction gamma of a reproduced
image from an sRGB image through a Frontier printer should have a relative
gamma of 1.2 to 1.6 and the extremes of sRGB should be mapped to the
extremes of print material. Anything less than that will yeild an image
that appears flat and lifeless when viewed at interior lighting conditions.
Under NO CIRCUMSTANCES, should an sRGB image be rendered in an absolute
colorimetric fashion on a print device. That would be just plain stupid. I
would argue, in terms of sRGB data, that you would never want to go back to
the PCS if your goal was to handle output specific sRGB data . It is a
maping that it is best handled by three 1 d luts... Tune the gamma a bit
and just map the extent of the gamut. You'll get no artifacts, colorful
images, and subjectively good tone reproduction.
Greg
news:LpjSb.143397$nt4.659733@attbi_s51...
> The problem that I see in the data is that it doesn't "square" visually
with
> my outputs from a Frontier. I sent some sRGB data to a Frontier and they
did
> exactly what I though they should do, RGB data was mapped explicitly to
the
> limits of the gamut of the output material. This is EXACTLY what should
be
> done for subjective viewing. The sRGB gamut should be mapped to the
> extremes of the RA-4 media. This will always yield a print that has very
> high percieved colorfulness when viewed under Interior lighting
conditions.
> In my case, the Frontier output was more colorful than either the monitor
or
> inkjet rendering.
In an ICC workflow, is a perceptual intent supposed to "fill out" the gamut
in
the way you describe? Perceptual intent is usually discussed in the context
of *reducing* the gamut of the working space, to that of the printer space.
But is it supposed to go in the other direction too, when required?
(and most working spaces *definitely* need to expand to fill out my inkjet
printer
gamut in *some* areas)
Greg.
Gerhard Fuernkranz
tlianza wrote:
>I know that I often give you a hard time, but I wasn't giving you a hardtime
>about the xy maps, it was the previous analysis where you used the
>derivatives and the then derived the straight lines based upon some notion
>of predominant wavelength. The only point I wanted make is that analysis
>may work well with additive sources, but it is really wrong when applied to
>subtractive samples. The next time, I'll try to be more clear.
>
Timo,
I fully agree with Tom, in this case the gamut comparison really should
be done in 3D. I've attempted to create a profile from your (spectral)
data points (assuming a D50 illuminant) and also to visualize the gamut
(in the PCS, using CIELAB) as VRML file, see
http://home.arcor.de/gfuer/frontier.wrl
The outer wireframe is the sRGB gamut, and the solid object in the
center is the gamut of your data points. Appearently, nearly the whole
gamut of your data is a subset of the sRGB gamut, only the yellow and
cyan/green corners slightly exceed the sRGB gamut hull.
>I sent some sRGB data to a Frontier and they did
>exactly what I though they should do, RGB data was mapped explicitly to the
>limits of the gamut of the output material. This is EXACTLY what should be
>done for subjective viewing.
>
Tom,
basically this means, they do print with "saturation" rendering intent?
But IMO it is rather questionable, whether this is exacly what *should*
be done. However, many people seem to like very colorful prints, and
appearently that's the reason why they do the gamut remapping it in this
way.
If I remember correctly, I can choose between automatic and
non-automatic color correction, when I send an digital image to the lab
for printing. Do I expect too much if I assume, that in the latter case
the printer still performs a perceptual, but *constant* color
transformation, which does not depend on the individual image contents?
>One of the points that folks don't seem to get is that sRGB is NOT a color
>space, per se, it is a RENDERED space. In a well designed digital camera,
>the reproduction gamma will be higher than 2.2-2.4 element of the spec. In
>fact, it will often be upwards of 2.6 to 2.8. The colorfulness will also be
>exaggerated to accomodate the loss of visual colorfulness due to the low
>adapting luminance.
>
I think I understand what you mean, but isn't such a "rendered space"
nevertheless still a "color space"?
My understanding is that sRGB *is a color space*, namely the color space
of a (virtual) CRT device.
And the camera captures the original scene and transforms the captured
image data with a *perceptual* (or even saturation?) rendering intent to
the sRGB space (taking the scene and the sRGB viewing conditions into
account). As you said, the transformation is certainly NOT a
colorimetric one. And depending on the camera and the camera settings -
the camera may even perform a different transformation for each shot.
>sRGB is a horrible space in which to perform editing (a
>point that Timo is constantly pointing out, although not always for the
>right reasons....) , but not because of the gamma, but the unknown rendering
>intent and subjective changes.
>
Tom, I think I can't follow you here. I agree, it is probably uncertain,
HOW the sRGB image was created by the camera from the original scene.
But why does this play a role for *editing*? Actually, I'm editing the
sRGB image from the camera *as is*, so I don't have to care how it was
created by the camera. All the changes I make to the image, I can review
on my monitor (if it is properly calibrated), and if I print the image
after editing, then of course the print is rather supposed to match
(more or less) what I see on the monitor, and not necessarily supposed
to match the originally captured scene (at least not colorimetrically).
>Under NO CIRCUMSTANCES, should an sRGB image be rendered in an absolute
>colorimetric fashion on a print device.
>
Fully agreed, of course this would not make much sense.
Regards,
Gerhard
Greg
news:401A8CCC...@icn.siemens.de...
> Tom,
> basically this means, they do print with "saturation" rendering intent?
Are there any strict definitions of the rendering intents? So far, none of
the descriptions
of the rendering intents really seem to match what Tom describes. For
example, isn't
saturation intent meant to *maintain* saturation, at the expense of hue? I
don't think
it's normally meant to increase saturation, is it?
Greg.
Gerhard Fuernkranz
Greg wrote:
> Are there any strict definitions of the rendering intents?
For the colorimetric intents, basically yes, especially the V4 spec describes
the required maths IMO pretty well. However, each profile vendor is free to
choose its preferred chromatic adaptation method (Wrong Von Kries, Bradford,
CAT02, ...). Prior to the introduction of the chromaticAdaptationTag, this
issue was also ambiguous and not well defined. With V2.4 and V4 profiles, the
vendor can (or must, with V4) now specify the chosen CAT method in the profile
(indirectly, in the chromaticAdaptationTag).
> So far, none of the descriptions of the rendering intents really seem
> to match what Tom describes.
Yes, that's true. However, "preceptual" and "saturation" are rather art than
science, and every vendor is cooking its own secret soup. In practive IMO the
only goals are just "pleasing" results, like a "nice" reproduction of photos
with the perceptual intent, or strong, vivid colors, e.g. for business
graphics, with the saturation intent. IMO virtually anything is allowed to
achieve these goals, since the results cannot be be judged objectively anyway.
> For example, isn't saturation intent meant to *maintain* saturation,
> at the expense of hue? I don't think it's normally meant to
> increase saturation, is it?
If you strictly follow the words in the spec, then probably it isn't. However,
see above. It's for example my understanding, that Argyll's icclink utility
also does expand the gamut, if saturation intent is used and if the
destination gamut is larger than the source gamut.
Regards,
Gerhard
Greg
Thanks again!
I wish I had come to this newsgroup a long time ago.
Greg.
"Gerhard Fuernkranz" <nosp...@gmx.de> wrote in message
news:401B0214...@gmx.de...
Timo Autiokari
>I know that I often give you a hard time, but I wasn't giving you a hardtime
>about the xy maps, it was the previous analysis where you used the
>derivatives and the then derived the straight lines based upon some notion
>of predominant wavelength. The only point I wanted make is that analysis
>may work well with additive sources, but it is really wrong when applied to
>subtractive samples.
Hello Tom, aha. But I was able to find those predominant wavelengths
for the paper, do you think that they are not correct? Why would they
not be correct? How would I measure the chromaticities of the dyes
more directly?
But we do agree that chromaticity maps are useful for what ever
device.
>The problem that I see in the data is that it doesn't "square" visually with
>my outputs from a Frontier. I sent some sRGB data to a Frontier and they did
>exactly what I though they should do, RGB data was mapped explicitly to the
>limits of the gamut of the output material.
Would you happen to have measured data about that? I've now inspected
two Frontiers and they both behave very similarly.
>This is EXACTLY what should be done for subjective viewing. The sRGB
>gamut should be mapped to the extremes of the RA-4 media.
I could not disagree more, but this is not the subject here so I do
not comment on that.
>One of the points that folks don't seem to get is that sRGB is
>NOT a color space, per se, it is a RENDERED space.
So, l I believe that in your book rendering space is a space that has
small gamut. Rendering usually means to fit the data for a device but
there are no sadRGB devices in this world.
>sRGB is a horrible space in which to perform editing (a point that
>Timo is constantly pointing out, although not always for the right
>reasons....) , but not because of the gamma,
Editing in what ever non-linear color-space is highly damaging.
>but the unknown rendering intent and subjective changes.
Aha. So in you opinion the automatic tweaking that the digicams do is
rendering?
>The final reproduction gamma of a reproduced image from an sRGB
>image through a Frontier printer should have a relative gamma of 1.2
>to 1.6 and the extremes of sRGB should be mapped to the extremes
>of print material. Anything less than that will yeild an image that appears
>flat and lifeless when viewed at interior lighting conditions.
Ooohh, I need to comment after all. When I print with a laser exposer
I do have very good screen match and still I have the more saturated
colors on the print. Looks great. Your way, with the huge
non-colorimetric gamma error & the enormous non-colorimetric gamut
tweak images would appear just very, VERY bad
>Tune the gamma a bit and just map the extent of the gamut.
>You'll get no artifacts, colorful images, and subjectively good
>tone reproduction.
Mapping what ever RGB gamut to the gamut edge of a printer is
seriously wrong. I do not believe you have done it like you explain.
Timo Autiokari
Timo Autiokari
>basically it is NOT the laser light, which you will see,
>when you look at the resulting prints.
Hello Gerhard, that is correct. I btw knew that already.
>What I want to say is, the resulting medium which comes out
>of the printer is undoubteldly a *reflective print*, and it surely
>uses cyan, magenta and yellow forming dyes and subtractive
>color mixing
Sure. And I indeed was able to mine those characteristics wavelengths.
>The lasers just expose the photo paper.
Yes, and since they are lasers ther chromaticity is at the horse-shoe,
so the corners in the device chromaticity map (that are not on the
horseshoe) are either from the paper dyes or from ICC conversion that
the device does internally.
>The lasers, which expose the photo paper, are of course red, green and blue.
>But you MUST NOT treat these red, green and blue lasers as a "classical"
>additive RGB color space.
Yes. You asked if the input was CMY and I was wondering if the
Frontier even has an CMY input mode at all (and if it has it has to be
emulated due to the RGB lasers).
>In fact, the blue laser rather represents the yellow channel, the
>green laser the magenta channel, and the red laser the cyan
>channel of the resulting print.
Yes, I knew that already, is very very clear. But the device input I
believe is RGB, it takes RGB data natively.
>Furthermore, a negative image is required to expose photo paper,
>i.e. the lasers need to project a negative image on the photo paper
>-- bright laser light will result in high densities, i.e. dark colors on the print.
Yes, I knew that too. Normal paper has negative transfer function, so
that when it is exposed from the negative film we will see a positive
image on the paper (after the paper is developed of course).
>Concerning the workflow, IMO the color space of the RGB image you
>send to the lab for printing is not at all the color space of the RGB lasers
>which expose the photo paper,
Naturally is not, I do not even know the chromaticities of the lasers
but their x,y points reside somewhere on the CIE horseshoe.
>but just an RGB working space (maybe sRGB or similar?).
RGB data that is sent to a printer for the purpose of characterization
of the device by a spectrometer do not "come" from a working-space,
they are just RGB input values that are fed to the device so that the
input-ouput behavior can be characterized.
>Given the large gamut of digitally printed photos (see Tom's previous
>posting), I would not be surprised, if this RGB working space would be
>a non-neglectable limiting factor for the overall gamut in the workflow.
It appear that the Frontier itself assumes sadRGB data, it has this
"mode", most if not all the Frontiers here in Finland seem to be used
in the sadRGB mode. The Labs seem to be rather reluctant to change the
mode for my prints.
Timo Autiokari
Gerhard Fuernkranz
Timo Autiokari schrieb:
Timo,
looks like we have common understanding concerning most issues.
>>but just an RGB working space (maybe sRGB or similar?).
>
> RGB data that is sent to a printer for the purpose of characterization
> of the device by a spectrometer do not "come" from a working-space,
> they are just RGB input values that are fed to the device so that the
> input-ouput behavior can be characterized.
From this point of view you are right - in this case you basically send
"DeviceRGB" (that's he PostScript term, I don't know how else I should call
it) to the device and you don't know in advance how these DeviceRGB values
will map to XYZ.
From the other point of view, you're also saying:
> It appear that the Frontier itself assumes sadRGB data,
This means, that we send image data in a standardized working color space
(sRGB) to the lab, and the printer does perform the conversion from this
working space to the device color space internally.
> it has this "mode", most if not all the Frontiers here
> in Finland seem to be used in the sadRGB mode. The Labs
> seem to be rather reluctant to change the mode for my prints.
Yes, a "raw" mode would be interesting.
Btw, have you any idea whether the Frontier honors embedded ICC profiles in
the image files? This would give the opportunity to send data in a wide gamut
RGB space.
Regards,
Gerhard
Gerhard Fuernkranz
Gerhard Fuernkranz schrieb:
> I've attempted to create a profile from your (spectral)
> data points (assuming a D50 illuminant) and also to
> visualize the gamut (in the PCS, using CIELAB) as VRML
> file, see http://home.arcor.de/gfuer/frontier.wrl
Timo,
I've recomputed the gamut hull a bit more accurately,
here's the new comparison to sRGB:
http://home.arcor.de/gfuer/frontier_vs_srgb.wrl
And - this might be more interesting - I have also compared
it to the gamut paches on my Wolf Faust IT8 target, which
is also printed digitally on photo paper:
http://home.arcor.de/gfuer/frontier_vs_IT8.wrl
(frontier = solid, IT8 = wire frame)
Basically the gamut shapes look pretty similar, nevertheless
Wolf still appears to manage somehow to obtain a larger gamut
on the photo paper than your frontier print. Btw, do you know
on which photo paper your print has been made? Was it
professional grade, or rather a consumer grade paper?
Regards
Gerhard
Timo Autiokari
>in this case the gamut comparison really should be done in 3D.
>I've attempted to create a profile from your (spectral) data points
>(assuming a D50 illuminant) and also to visualize the gamut
>(in the PCS, using CIELAB) as VRML file, see
>http://home.arcor.de/gfuer/frontier.wrl
This is a very interesting analysis! May I ask how with what did you
create the wrl? Naturally a 3D view is *much* better but the Lab
space that your wrl has is very difficult to comprehend since it is
not a real space. Is your wrl tool able to create also an Yxy view?
Is the wrl the result of what the created profile does? The raw data
(RGB ->spectro -> Yxy) shows that the most saturated points do exceed
a little (the Trinitron gamut, you used the sadRGB gamut) also on the
magenta. The profiler does some "rendering" so the profiled gamut is
not so accurate as the Yxy from spectras.
>The outer wireframe is the sRGB gamut, and the solid object in the
>center is the gamut of your data points. Appearently, nearly the whole
>gamut of your data is a subset of the sRGB gamut, only the yellow and
>cyan/green corners slightly exceed the sRGB gamut hull.
Indeed. Amazingly small gamut for a photo-exposer!
Timo Autiokari
Timo Autiokari
>http://home.arcor.de/gfuer/frontier_vs_srgb.wrl
Yes, more accurate now.
Could you please tell me what sw you are using for profiling and
especially for the WRL??? I'd very much like to have the ability to
generate there gamut comparisons (but in Yxy).
>http://home.arcor.de/gfuer/frontier_vs_IT8.wrl
>(frontier = solid, IT8 = wire frame)
Very interesting indeed.
>Basically the gamut shapes look pretty similar, nevertheless
>Wolf still appears to manage somehow to obtain a larger gamut
>on the photo paper than your frontier print.
The difference is in fact very small (it just looks somewhat notable
on your WRL because the WRL is in Lab mode). Yes, the difference most
probably is due to the low cost paper that has *rather* high black
point as you can see from the data. High black point means small
gamut, Tom already hinted to that by suggesting flare problems during
the measurement. I do not know the make nor the type of the paper but
it is cheap and very thin.
Timo Autiokari
Timo Autiokari
>Yes, a "raw" mode would be interesting.
Yes, very true. A "raw" like from input RGB through the lasers onto
the negative paper. Not very nice negative print.
But in my opinion there is quality difference (in case of
color-managed workflow) between the cases when the characteristics of
the printer are "native" or mathematically continuous compared to when
the characteristics of the printer are not seen at all because the
printer applies a 3D LUT profile on the input data.
>Btw, have you any idea whether the Frontier honors embedded ICC profiles in
>the image files? This would give the opportunity to send data in a wide gamut
>RGB space.
It seem not, but I have not been able to "play" with the device
myself. I have the understanding that it has a sadRGB mode and in this
mode the Frontier seem to be doing the a profile conversion from
sadRGB to deviceRGB (but this is not at all accurate). So most
probably it has modes also, it could be that change of the mode may
require an automatic recalibration or something as the operators are
very reluctant to the idea of changing the mode. Maybe it is difficult
to get back who knows.
Timo Autiokari
Gerhard Fuernkranz
Timo Autiokari schrieb:
> This is a very interesting analysis!
> May I ask how with what did you create the wrl?
Timo, of course, see
http://web.access.net.au/argyll/argyllcms.html
For bypassing the profile, and creating the gamut hull directly
from the L*a*b* data points, I've finally written a small program,
which uses Argyll's libraries, see below.
-------------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <gamut.h>
int
main(int ac, char **av) {
double Lab[3];
gamut *gam = new_gamut(10.0);
while (scanf("%lf %lf %lf", &Lab[0], &Lab[1], &Lab[2]) == 3) {
gam->expand(gam, Lab);
}
gam->write_gam(gam, "gamut.gam");
gam->write_vrml(gam, "gamut.wrl", 1);
exit(0);
}
-------------------------------------------------------------
To compare two gamuts, use the utility viewgam, e.g.
"viewgam frontier.gam sRGB.gam frontier_vs_srgb.wrl"
> Naturally a 3D view is *much* better but the Lab
> space that your wrl has is very difficult to comprehend since it is
> not a real space. Is your wrl tool able to create also an Yxy view?
I haven't tried this, but I suspect, it doesn't care what
the three dimensons actually do represent, however, it might
expect a particular normalization of the coordinates.
Regards,
Gerhard
Timo Autiokari
thank you very much for the information, I archived your post for the
future..This argyllcms sounds to be an excellent package but
apparently targeted only for the 0.01ppm of the population, for those
who are interested in color-managmement and also are professional
programmers!
Ahh, I had forgot all about it, I went to see the argyllcms, found
that it indeed does the WRL so I immediately downloaded the package...
just to see that there are no functional programs in it. The very
same disappointment I experienced with this package about an year ago.
BR,
Timo Autiokari
Gerhard Fuernkranz
Timo Autiokari wrote:
>just to see that there are no functional programs in it. The very
>same disappointment I experienced with this package about an year ago.
>
Timo,
this is something, I cannot confirm. As in every software, there will be
surely the one or other bug, but basically it works pretty well ;-) It
also did work for me one year ago - but there was less functionality.
However, I agree, it may be a bit tricky to compile the whole stuff ...
Regards,
Gerhard
Timo Autiokari
I only tried to say that there are no EXEs in the package! One has to
be experienced programmer and have the expensive compiler in order to
be able to use the argyllcms.
I have not even tried to compile it, because I do not have a compiler
and could not use a compiler even if I had one.
BR,
Timo Autiokari
Peter Karp
> The actual description of gamut is rarely done in xy space for subtractive
> products. Once again, it is completely valid for devices such as monitors,
> because the chromaticities of the primaries do not change with luminance.
That would be an ideal display, but real world displays tend to have less
saturated colors for lower luminance levels. At least that's what I've
seen so far. Do you know of a display where the chromaticities for
different luminance levels plot on one or better said three points? Or do
you think that the measurements in low luminance levels are too unstable
to be meaningful in this regard.
Kind regards
--
Peter
Gernot Hoffmann
Peter,
the actual gamut depends on the luminance, even if the
primary coordinates are constant (an ideal display).
http://www.fho-emden.de/~hoffmann/ciegamut16012003.pdf
Similar diagrams on Timo Autiokari“s website.
CIE xyY shows the convex hull for a perspective projection
of an ARBITRARY gamut volume in CIE XYZ (at least near to
the convex hull because some contours can be slightly concave
- we don“t have a mathematical nomenclature how to describe
such a contour).
The large gamut for dark colors is an illusion - result of
the perspective projection.
A better impression by CIELab:
http://www.fho-emden.de/~hoffmann/cielab03022003.pdf
But the strong nonlinear transformation may blurr the view ..
Anyway, a gamut volume exists in XYZ, but the interpretation
in xyY is always doubtful. Because one cannot reconstruct a
volume from ONE 2D projection.
Now I guess that the corners in xyY are not necessarily the
primaries for an arbitrary color system.
CIELab gamut volumes look like flintstones - sharp edges,
some surface parts are convex, others are concave. Who can
tell how a perspective projection to xyY would look ?
(GretagMacbeth/ProfileMaker/ProfileEditor/GamutView, if
a debugged version should be available...)
Best regards --Gernot Hoffmann
Gerhard Fuernkranz
>I only tried to say that there are no EXEs in the package!
>
Timo,
I could only provide Linux binaries.
But didn't Greg tell recently here in the group,
that he has compiled it under Windows?
Maybe he can send you Windows binaries?
Regards,
Gerhard
Greg
him
for permission to distribute the binaries (on a one-on-one basis). It's not
immediately
clear to me whether I have permission to do this, because there are multiple
licenses
in the package, and I'd rather not have to read each license - I'll just ask
the author directly.
Greg.
"Gerhard Fuernkranz" <nosp...@gmx.de> wrote in message
news:4027EE40...@gmx.de...
Roger Breton
> I could only provide Linux binaries.
> But didn't Greg tell recently here in the group,
> that he has compiled it under Windows?
> Maybe he can send you Windows binaries?
>
> Regards,
> Gerhard
>
Gerard,
Do you know whether the Linux binaries will run on MacOSX?
Roger Breton
Gerhard Fuernkranz
Roger Breton wrote:
>Gerard,
>Do you know whether the Linux binaries will run on MacOSX?
>
Roger, I don't think so.
It's a different different OS and I think also a different processor,
isn't it?
Regards,
Gerhard
Greg
Timo - I've emailed you.
Greg.
"Greg" <REMOVE...@THISbigfoot.com> wrote in message
news:4027ef49$1...@duster.adelaide.on.net...
Greg
Greg.
Timo Autiokari
>Timo - please email me, because my email to you bounced. ("no such user")
Greg, thank you very much for your gracious offer, however I can only
run software that fulfill rather rigorous security criterions and this
kind of acquire path just does not pass. No offence, I hope you
understand. It is just that the security comes first and there is
absolutely no exceptions to that.
Timo Autiokari
Greg
wasted
all this time writing my custom virii for you. ;^)
*SHRUGS*
Greg.
"Timo Autiokari" <timo.au...@aim-dtp.net> wrote in message
news:lf6n20d4dhdc0u44j...@4ax.com...