LPROF 1.11.1 developement snapshot released

> --- Ursprüngliche Nachricht ---
> Von: Bob Friesenhahn <bfriesensimple.dallas.tx.us>
> An: "Hal V. Engel" <hvengelastound.net>
> Kopie: lcms-userlists.sourceforge.net
> Betreff: Re: [Lcms-user] LPROF 1.11.1 developement
snapshot released
> Datum: Tue, 10 Jan 2006 16:21:47 -0600 (CST)
> 
> Using a gamma of around 2.2 (or 2.6 for X'Y'Z') tends
to linearize the 
> luminance significance of each bit (particularly for
dark regions) so 
> fewer storage bits are necessary, and computational
errors are 
> reduced.

Is my understanding correct that the lprof color picker
still can handle only 8bit per channel? (-> i.e. load the
image into a QImage, and then pick the measurements from the
QImage, where QImage only supports 8bit) If so, then I would
not recommend to use gamma=1 until this is fixed. A
precision
of 8bit per channel is IMO insufficient for gamma=1 images.

Regards,
Gerhard

-- 
Gerhard Fuernkranz
nospam456gmx.de

DSL-Aktion wegen großer Nachfrage bis 28.2.2006 verlängert:
GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go
/dsl


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep
through log files
for problems?  Stop!  Download the new AJAX search engine
that makes
searching your log files as easy as surfing the  web. 
DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=1686
5&op=click
_______________________________________________
Lcms-user mailing list
Lcms-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

On Wednesday 11 January 2006 01:01 pm, Gerhard Fuernkranz
wrote:
> > --- Ursprüngliche Nachricht ---
> > Von: Bob Friesenhahn <bfriesensimple.dallas.tx.us>
> > An: "Hal V. Engel" <hvengelastound.net>
> > Kopie: lcms-userlists.sourceforge.net
> > Betreff: Re: [Lcms-user] LPROF 1.11.1 developement
snapshot released
> > Datum: Tue, 10 Jan 2006 16:21:47 -0600 (CST)
> >
> > Using a gamma of around 2.2 (or 2.6 for X'Y'Z')
tends to linearize the
> > luminance significance of each bit (particularly
for dark regions) so
> > fewer storage bits are necessary, and
computational errors are
> > reduced.
>
> Is my understanding correct that the lprof color picker
> still can handle only 8bit per channel? (-> i.e.
load the
> image into a QImage, and then pick the measurements
from the
> QImage, where QImage only supports 8bit) If so, then I
would
> not recommend to use gamma=1 until this is fixed. A
precision
> of 8bit per channel is IMO insufficient for gamma=1
images.
>
> Regards,
> Gerhard

I just had a look at the code and also added some debugging
code to confirm 
exactly what is going on.  QImage can handle bit depths
greater than 8 
bit/channel and defaults to a pixel bit depth of 32 (which
is really 10 
bit/channel).   This is also the max bit depth it supports. 
The constructor 
for QImage is:

QImage::QImage ( int w, int h, int depth, int numColors = 0,
Endian bitOrder = 
IgnoreEndian )

Where depth can be 1, 8, 16 or 32.

When I print out image.depth() for the QImage being used by
the picker it is 
32 bits.  But in the loop that is picking the values if I
filter out all rgb 
values < 255 I don't get anything.  So QImage is
effectively remapping the 16 
bit/channel image as an 8 bit/channel image.

In another note to the list Bob Friesenhahn wrote:

"A potential solution to this problem is to gamma
correct/translate 
values associated with the color picker.  That way the color
picker 
always operates with gamma = 2.2."

This might work but the correct solution is to set this up
so the picker 
operates on the raw image data at whatever color depth that
data has.  In 
fact this is an absolute requirement as far as I am
concerned as at this 
point QImage is changing the data of 16 bit/channel images
in the process of 
loading the image and this in effect introduces what could
be (likely are) 
significant errors into the process.  This change to how
LPROF works could be 
fairly involved but it needs to be done and I will add this
to my enhancement 
list and give it a very high priority.

This was a good catch by Gerard as I had totally missed what
was going on with 
this part of the code.  These development snapshots are
being released in the 
hope that problems/limitations and the like will be found so
that these can 
be corrected.   I hope you will keep providing valuable
feedback like this so 
that LPROF will continue to improve.  

Hal


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep
through log files
for problems?  Stop!  Download the new AJAX search engine
that makes
searching your log files as easy as surfing the  web. 
DOWNLOAD SPLUNK!
http://ads
.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Lcms-user mailing list
Lcms-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

On Wednesday 11 January 2006 23:47, Hal V. Engel wrote:
> exactly what is going on.  QImage can handle bit depths
greater than 8
> bit/channel and defaults to a pixel bit depth of 32
(which is really 10
> bit/channel).   This is also the max bit depth it
supports.  The
> constructor for QImage is:
>
> QImage::QImage ( int w, int h, int depth, int numColors
= 0, Endian
> bitOrder = IgnoreEndian )
>
> Where depth can be 1, 8, 16 or 32.
>
> When I print out image.depth() for the QImage being
used by the picker it
> is 32 bits.  But in the loop that is picking the values
if I filter out all
> rgb values < 255 I don't get anything.  So QImage is
effectively remapping
> the 16 bit/channel image as an 8 bit/channel image.
>

Yes, and it's not better in Qt4 :-(. However, if you need 16
bit/channel 
images you might either try to reuse the Krita
image/colorspace library or 
digikam's dimg. Krita's core code has been refactored to
libraries that 
should be reusable outside KOffice, and digikam's dimg is
pretty independent, 
too.

-- 
Boudewijn Rempt 
http://www.va
ldyas.org/fading/index.cgi

> I just had a look at the code and also added some
debugging code to confirm
> exactly what is going on.  QImage can handle bit depths
greater than 8
> bit/channel and defaults to a pixel bit depth of 32
(which is really 10
> bit/channel).   This is also the max bit depth it
supports.  The constructor
> for QImage is:
>
> QImage::QImage ( int w, int h, int depth, int numColors
= 0, Endian bitOrder =
> IgnoreEndian )
>
> Where depth can be 1, 8, 16 or 32.
>
> When I print out image.depth() for the QImage being
used by the picker it is
> 32 bits.  But in the loop that is picking the values if
I filter out all rgb
> values < 255 I don't get anything.  So QImage is
effectively remapping the 16
> bit/channel image as an 8 bit/channel image.
>
 	This would explain my previous post about linear vs. 
gamma-corrected input.  The linearly-derived profile was
much worst fit 
and exhibited the banding.  I (wrongly) assumed that because
lprof could 
now load TIFFs via the TIFFio and didn't complain on the
16-bit data, that 
it actually *used* the deeper color.

> In another note to the list Bob Friesenhahn wrote:
>
> "A potential solution to this problem is to gamma
correct/translate
> values associated with the color picker.  That way the
color picker
> always operates with gamma = 2.2."
>
> This might work but the correct solution is to set this
up so the picker
> operates on the raw image data at whatever color depth
that data has.  In
> fact this is an absolute requirement as far as I am
concerned as at this
> point QImage is changing the data of 16 bit/channel
images in the process of
> loading the image and this in effect introduces what
could be (likely are)
> significant errors into the process.  This change to
how LPROF works could be
> fairly involved but it needs to be done and I will add
this to my enhancement
> list and give it a very high priority.
>
 	Can it be read-in via libtiff directly?  Just a WAG on my
part... 
I haven't looked at the code at all.

-Cory

-- 

************************************************************
*************
* Cory Papenfuss                                            
           *
* Electrical Engineering candidate Ph.D. graduate student   
           *
* Virginia Polytechnic Institute and State University       
           *
************************************************************
*************

On Thursday 12 January 2006 10:47 am, Cory Papenfuss wrote:
snip

>So QImage is effectively
> > remapping the 16 bit/channel image as an 8
bit/channel image.
>
>  	This would explain my previous post about linear vs.
> gamma-corrected input.  The linearly-derived profile
was much worst fit
> and exhibited the banding.  I (wrongly) assumed that
because lprof could
> now load TIFFs via the TIFFio and didn't complain on
the 16-bit data, that
> it actually *used* the deeper color.
>
snip

>  	Can it be read-in via libtiff directly?  Just a WAG
on my part...
> I haven't looked at the code at all.
>

I could use libtiff directly if I only wanted to support
tiff files.  I would 
rather use a library that generalizes this so that other
file types are 
supported. 

There were lots of good ideas about possible way to approach
this.  I would 
like to thank Cory,  Alastair, Boudewijn, Bob and Andrew for
their ideas.  I 
also found a couple of other libraries by searching the net.
 

After looking things over I am  initially leaning toward
VIGRA.  It looks like 
it will handle images of practically any bit depth (up to
float for each 
channel) and in a wide range of file types (tiff, png, jpeg,
gif ....) with 
the correct libraries installed.   It is also portable
across many platforms.  
And I think I read on the Hugin list that it will handle HDR
images.

It appears to do everything I need which is not that
difficult (open the file 
and give random access to pixel RGB channel values).  So I
only need about 2% 
of what it is capable of.   It is being actively maintained
and is available 
for my distro.  I also currently have at least two apps on
my system that are 
using it.

I have not started coding yet.  But my initial look at the
code indicates that 
this should not be too difficult as there are appear to be 3
places where I 
need to add/change code to implement this and it looks like
in total I may 
have to add/change less then a dozen lines of code.  But I
may find that I am 
totally off the mark and it may be way more difficult than I
currently think 
it is.

In any case it is time to start coding.

Hal


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep
through log files
for problems?  Stop!  Download the new AJAX search engine
that makes
searching your log files as easy as surfing the  web. 
DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=1686
5&op=click
_______________________________________________
Lcms-user mailing list
Lcms-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

On Thursday 12 January 2006 21:38, Hal V. Engel wrote:

> After looking things over I am  initially leaning
toward VIGRA.  It looks
> like it will handle images of practically any bit depth
(up to float for
> each channel) and in a wide range of file types (tiff,
png, jpeg, gif ....)
> with the correct libraries installed.   It is also
portable across many
> platforms. And I think I read on the Hugin list that it
will handle HDR
> images.

I've been playing with VIGRA myself when I was looking
whether something 
pre-existing would make a good replacement for the
ImageMagick inspired Krita 
core back in 2003 or so and really liked it. It's not very
suitable for 
interactive applications, or for natural paint simulation
which is what I 
needed, but apart from that I was very impressed.

-- 
Boudewijn Rempt 
http://www.va
ldyas.org/fading/index.cgi

An update.  I have a version of LPROF that is working with
16 bit IT8.7/2 
images (but perhaps not with anything else at the moment)
and I have produced 
good profiles using 16 bit IT8 images from UFRAW.  I still
need to do a lot 
of work to generalize the code and make sure that everything
at least appears 
to be working.  My plan at this point is to work on this
until I feel that 
everything is working correctly and then include this change
in snapshot 
1.11.2.  The could perhaps happen in a week or two.  I have
checked this 
change into CVS but use the current version in CVS at your
own risk as it is 
likely to be very buggy.

I have never worked with a C++ template based library before
and initially I 
found this very frustrating and I am still not very far up
the learning 
curve.   These sort of reminds me of Ada generic units.  But
C++ templates 
are not nearly as elegant and so far at least I find them
much more difficult 
to understand than Ada generics. 

Hal

On Thursday 12 January 2006 01:13 pm, Boudewijn Rempt wrote:
> On Thursday 12 January 2006 21:38, Hal V. Engel wrote:
> > After looking things over I am  initially leaning
toward VIGRA.  It looks
> > like it will handle images of practically any bit
depth (up to float for
> > each channel) and in a wide range of file types
(tiff, png, jpeg, gif
> > ....) with the correct libraries installed.   It
is also portable across
> > many platforms. And I think I read on the Hugin
list that it will handle
> > HDR images.
>
> I've been playing with VIGRA myself when I was looking
whether something
> pre-existing would make a good replacement for the
ImageMagick inspired
> Krita core back in 2003 or so and really liked it. It's
not very suitable
> for interactive applications, or for natural paint
simulation which is what
> I needed, but apart from that I was very impressed.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep
through log files
for problems?  Stop!  Download the new AJAX search engine
that makes
searching your log files as easy as surfing the  web. 
DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=1686
5&op=click
_______________________________________________
Lcms-user mailing list
Lcms-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user

Another update for those interested.  CVS now has a version
of LPROF that 
should work with the following RGB formats:

8 bit unsigned
16 bit signed and unsigned
32 bit signed and unsigned
float
double

It has been tested it with 8 and 16 bit unsigned IT8 images.
 But the others 
have not been tested at this point.  VIGRA incorrectly
identifies unsigned 16 
bit images as signed 16 bit images.  So the code has to do
some stuff to 
detect and correct this.  The code assumes (not a good thing
because it may 
be wrong) that VIGRA is doing the same thing with unsigned
32 bit 
stuff.  Even if this assumption is not correct it should
work correctly with 
both signed and unsigned 32 bit integer/channel images.

In any case please feel free to test what is in CVS and
report any problems.  
Particularly if you can test with any of the untested image
file formats.

Hal
 


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep
through log files
for problems?  Stop!  Download the new AJAX search engine
that makes
searching your log files as easy as surfing the  web. 
DOWNLOAD SPLUNK!
http://ads
.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Lcms-user mailing list
Lcms-userlists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user