Once I finally coerced TiffIO (the src.rpm) to compile, it
installed in /usr/lib/qt-3.3/plugins/imageformats/libTiffIO.so. It would
not recognize that it was there until I symlinked it in
/usr/lib/qt-3.3/lib
This library is a little strange but it very powerful in that once it is
installed and recognized it enables TIFF file IO for every QT app on your
system that can open graphics files not just LPROF. It is also fully cross
platform and is supposed to work on Windows and Mac OS/X as well as Linux.
I generally compile everything from source tarballs, but since
something as large as kde/qt I use with my distro's RPM, I wanted to go
the rpm route. I couldn't find a binary, so I had to hack the src.rpm to
go. Looks pretty slick... although like I said for some reason it didn't
find it in $QTDIR/plugins/imageformats/libTiffIO.so
- Searching paths for templates/profiles/targets seems fragile
(path-wise). Are they required to have .TXT suffix now? Between older
lprof versions (with the broken case, etc), and argyll the file suffix
is confusing. Maybe allow override in the dialog box?
As far as I can tell the newer profiling targets all come with the reference
files having a suffix of .TXT. But if that is not the case it is a fairly
simple change to add other suffixes. Do you know of any recent reference
files that are using something else? If so I will update the code to support
additional suffixes.
I've seen different suffixes from .it8, .q60, etc. The target I'm
using is from Kodak and has the config file called R2200412.Q60. I guess
what I was thinking is not so much statically adding suffixes, but rather
a default selection (e.g. *.TXT,*.Q60) with the ability to select any
file.
The old code would blow up if you pointed it at a directory that had non-CGATS
files. I did a lot of work to stop that from happening and while I was in
there working on that stuff I filtered all files that had other suffixes so
that it would be faster. Again I can add additional suffixes very easily so
let me know what you need and it will be in the next release. So if you have
specific suffixes that you would like added please open a BUG report so that
it can be tracked.
- I'm a bit ignorant of the details of the profiles, but my planned
workflow with my digital camera is RAW->Linear16 TIFF (color-managed). Is
there a way to force a prelinearization gamma to the profile? It seems
like all the profiling tools I've used tend to fit the LUT with a more or
less linear (or in the case of argyll funkily nonlinear) prelinearization.
Manually setting a gamma of around 2.2 might make for a nicer profile. Of
course, I could be completely full of crap and am going about this the
wrong way.
LPROF will calculate an approximate input gamma for each primary by looking at
the target image and this can be seen in the messages box as the profile is
created and when you open the profile checker dialog. My experience so far
using UFRAW as my raw converter is that processing the target image with
gamma around 2.2 to 2.4 seems to give the best results. This might not be
true for other RAW converters or cameras and may require some
experimentation. Don Hutchson of Hutch Color recommends using a gamma of
2.8 when profiling high dynamic range devices like cameras and high end film
scanners to recover more shadow detail. But I have found that at a gamma of
2.2 I have good detail right down into the noise with my D70. You should
have a look at the UFRAW tutorial that is part of the help system. It has
lots of good info about how to create camera profiles. Even if you are not
using UFRAW you should read it as it will help you understand the basic
workflow for creating camera profiles.
I would also be inclined to stay away from using a gamma near 1 (linear) since
this will tend to block up your shadow detail with only very minor
improvements in your highlight detail. This might be usefull for images that
are slightly over exposed as a special case to recover as much highlight
detail as possible.
For a fully color-managed workflow, this should not matter. The
only thing that should contribute to dynamic range is what's in the
original RAW, capture. The reason *FOR* utilizing a RAW linear workflow
is to minimize cumulative nonlinear post-processing errors like
http://www.aim-dtp.net/aim/evaluation/gie/index.htm
discusses.
Also, what I'm envisioning is the data truncation that is done
with a gamma-corrected RAW interpolation. Compare the resulting profile
from a linear RAW (i.e. dcraw -4) vs. Gamma RAW (ufraw as in the guide).
In the former, everything (Shaper TRC, AtoB pre/post linearization) are
all more or less linear. In the latter, the ShaperTRC *UNDOES* the gamma
introduced in the Bayer interpolation with UFRAW. Since the interpolated
file was saved with 16-bit fixed-point an extra layer of truncation was
performed.
The way I see it, the icc profile should be all that is necessary
to take the RAW data from the camera and map it into an absolute
working colorspace. Keep all manipulation/quantization of the
original data as close to the end as possible.
- Template selection (green boxes, corners, 19+3) didn't seem to match my
IT8.7 target (linear 16 tiff). Is it a bug?
Do you mean that the hot zones don't match up with the patches on the target?
Does it match when you use the scandemo.png in the data/pic directory (this
is a 19+3 target)? If not then more then likely you are not correctly
selecting the target corners. If it does match with scandemo.png then your
target is differrent in some way. What vendor is it from? And how is it not
matching?
The lower corners need to be marked at the lower left corner of the white
patch in the lower left corner of the target and the lower right corner needs
to be marked at the lower right corner of the DMAX patch in the lower right
corner of the target. Perhaps I need to add some images showing this in the
help system. Currently I only show an image of the upper left corner. Also
in some cases you might need to adjust the corner marks to get the patches to
line up correctly. This is particularly true if the target image is not very
close to being squared up in the image as can happen when shooting the target
with a camera. The algorithm that places the template will handle some
fairly out of square target images but sometimes it needs a little help from
the user.
That's more or less what I'm seeing... it pretty much works, but
the corners need to be manipulated a bit to make it all line up. I was
thinking that lining up the corners should be enough... even though I've
got a bit of trapezoidal and rotational distortion in my test shot.
Don't get me wrong... I'm not trying to get argumentative. I'm
still learning about trying to minimize cumulative errors in digital
workflow. Trouble is there is a lot of misinformation out there to wade
through as well.
-Cory
--
*************************************************************************
* Cory Papenfuss *
* Electrical Engineering candidate Ph.D. graduate student *
* Virginia Polytechnic Institute and State University *
*************************************************************************
-------------------------------------------------------
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=16865&op=click
_______________________________________________
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user
