On Tuesday 10 January 2006 08:42 am, Cory Papenfuss wrote: snip
> 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 This worked without the sym link on my machine. So this is strange as it should work without needing the link. Do you have QTDIR set globally? > 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. Yes that is what I was thinking as well. I have already modified my local copy of the source code to include *.txt *,.TXT, *.IT8, *.it8, *.q60 and *.Q60 in the default selection list. Should any others be added? Perhaps *.CGATS and *.cgats. If not I will have this in CVS later today or tomorrow. snip > 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. > snip > > 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. It is true that the profile characterizes the color space of the image. Therefore when a linear image with a profile that correctly characterizes that images color space is opened in an app that understands ICC profiles it will correct it before it is displayed but the actual data is still linear. The same applies to when the image is printed. The concern I and other have is that the process of creating the image from the RAW data using a gamma of 1 will tend to block up the shadow detail. I have only done a few experiments with this but using a gamma around 2.2 did yield better shadow detail. The difference was not huge but it was clearly there. In addition I tend to minimize the number of manipulations that I do to an image after it comes out of RAW conversion. So I have not seen any ill affects like those described on the web site you referenced. UFRAW will let you use just about any output gamma you want from a gamma of 1.0 to values of around 5 or there abouts. So it would be a simple matter to set UFRAW to output a gamma 1.0 IT8.7 image and then profile it with LPROF or some other profiler. The images will appear dark when viewed uncorrected but in apps like Photoshop, Scribus, Cinepaint or GIMP beta with everything setup correctly the images will appear normal as they will have been corrected to the display color space before being displayed. snip > 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. > Target images that are not totally squared up like your image are difficult cases to deal with. With the old code for this (LPROF version 1.10.1 and earlier) target images like you describe were difficult to impossible to use depending on how much trapezoidal and/or rotational distortion there was. With the new code the user may have to make some adjustments but even if that is the case it only takes perhaps a minute or two to get things lined up. I have tested this with cases with extreme amounts of trapezoidal and rotational distortion (way more then I would ever expect to see in the real world) and I was able to get the pick template and the image to line up with a few minutes effort. Over all a big improvement over the older versions. Also with a target image that is very well squared up like you would get from a flat bed scanner all you have to do is select the corners and the template will line up nearly perfectly. > 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. All of this stuff has trade offs and every user has to decide what set of trade offs will work best for them. What works best for you may not be what is best for someone else. One of the nice things about working with RAW images is that you can always go back to the RAW image and reprocess it if you decide that there is a better way of doing things. I should add that it is likely that for really picky (and experienced) users there may be different workflows used for different images or to get differrent results depending on what the user desires for that image. But this is definitely getting into the area of advance techniques and at first you should settle on one workflow and stick to it. I should add that I am open to feedback. So don't worry about appearing argumentative. My goal is to improve LPROF. ------------------------------------------------------- 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
