How should the 'Grey picker' work?
Tduell
I suspect that the 'Grey picker' tool in the Fast Preview window isn't
working correctly, or I'm not working it correctly, in my build of the
current trunk (2011.1.0 hg00c4a9ed694f).
When I move my mouse over the button it is highlighted, and I can
select it, but nothing appears to happen if I then select a grey point
in the image.
I have had a bit of a snoop into the code and it looks like some
explanatory text should be displayed (probably at bottom of the FPW)
but that doesn't happen either.
I am probably not using it correctly, so a brief explanation of how I
should be using it might solve the problem.
Cheers,
Terry
Yuval Levy
On February 28, 2011 08:03:27 pm Tduell wrote:
> I am probably not using it correctly, so a brief explanation of how I
> should be using it might solve the problem.
Click once on the Grey Picker button and it' background will become dark gray.
Then click in the panorama. The background of the button will turn normal
again and the new white balance will be calculated and shown. Depending on
the number of images it may take a moment. Works well here. To test, take a
panorama with cloud and use it on a surface of blue sky to upset the white
balance; and then use it a second time on a cloud to correct.
Yuv
Terry Duell
On Tue, 01 Mar 2011 12:12:27 +1100, Yuval Levy <goo...@levy.ch> wrote:
> Works well here. To test, take a panorama with cloud and useit on a
> surface of blue sky to upset the white
> balance; and then use it a second time on a cloud to correct.
Thanks for that explanation. It is working as it should. I think my
previous attempts must have been pixels which caused none, or very little
change.
Cheers,
--
Regards,
Terry Duell
Jeffrey Martin
john doe
this is the first i've ever heard of a "grey picker".
--
You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
Bart van Andel
whoa i mustve been using a really old version of hugin now what does this gray picker do?
Jeffrey Martin
when i'm developing raw files, i use the "grey picker" equivalent, but then i dial up the WB just a little bit, to make the image a bit more yellow (warm). it literally makes the image feel warmer, more pleasing.
kfj
that image processing functionality should be kept out of hugin. Of
course we need to align the images photometrically, but manually
finetuning the white balance is close to where I'd draw the border.
I'm of the UNIX philosophy to not have monolithic 'applications' but
rather a set of freely combinable tools, each doing one thing and
doing it well.
Kay
Pablo d'Angelo
Am 03.03.2011 18:34, schrieb kfj:
> Hmmm... I'm very much in two minds about features like this. I feel
> that image processing functionality should be kept out of hugin. Of
> course we need to align the images photometrically, but manually
> finetuning the white balance is close to where I'd draw the border.
I don't think so. Its basically a free lunch, and one that makes
technically sense, too.
Having to fix 8 bit images with a second application of a "curves tool"
will degrade the image quality, if 8 bit images are used.
Second, I haven't found any free image processing application performs
white balancing as good as hugin. That said, a gimp or other plugin with
the same algorithm would be nice ;-)
ciao
Pablo
Gnome Nomad
I prefer doing my image adjustments in programs designed for doing that.
They do it much better than I'd expect Hugin would do it. I don't think
Hugin needs to become a "monolith"!
--
Gnome Nomad
gnome...@gmail.com
wandering the landscape of god
http://www.cafepress.com/otherend/
Gnome Nomad
> Hi Kay,
>
> Am 03.03.2011 18:34, schrieb kfj:
>> Hmmm... I'm very much in two minds about features like this. I feel
>> that image processing functionality should be kept out of hugin. Of
>> course we need to align the images photometrically, but manually
>> finetuning the white balance is close to where I'd draw the border.
>
> I don't think so. Its basically a free lunch, and one that makes
> technically sense, too.
> Having to fix 8 bit images with a second application of a "curves tool"
> will degrade the image quality, if 8 bit images are used.
Of course it would. So you should do all osuch image adjustments before
pulling the image into Hugin to make the panorama. I do my image
adjustments in 16-bit color.
> Second, I haven't found any free image processing application performs
> white balancing as good as hugin. That said, a gimp or other plugin with
> the same algorithm would be nice ;-)
GIMP has that kind of grey/white/black functionality already, I think,
but it doesn't support 16-bit color. I use the non-free but very
functional Bibble Lite for that. Bibble is also designed for photo
processing and is very fast.
kfj
> Am 03.03.2011 18:34, schrieb kfj:
>
> > Hmmm... I'm very much in two minds about features like this. I feel
> > that image processing functionality should be kept out of hugin. Of
> > course we need to align the images photometrically, but manually
> > finetuning the white balance is close to where I'd draw the border.
about still okay, but not much further, that's what I mean.
> I don't think so. Its basically a free lunch, and one that makes
> technically sense, too.
processing, better masking, integrated tca correction, shared memory
for the processes in the toolchain - to name just a few I can think
of. But just throwing in a new free lunch feature without
documentation for everyone to figure out how it works by trial and
error isn't what I consider good style. For example, it took me quite
a while to figure out that to see any effect of the grey picker at
all, I had to remove the 'photometric' check mark in the preview. It
looks a bit like a quick shot to me.
> Having to fix 8 bit images with a second application of a "curves tool"
> will degrade the image quality, if 8 bit images are used.
increases processing time and memory use considerably. The resulting
degradation from successive processing steps may become quite
noticable. So there's another good feature waiting: how about an
option to convert to 16 bit on input and/or convert to 8 bit on
output? Or am I missing something here? When I process my 16bit TIFFs
with hugin, I'd quite like to be able to get 8bit TIFF out, but it
seems like I can only store in 16bit.
> Second, I haven't found any free image processing application performs
> white balancing as good as hugin. That said, a gimp or other plugin with
> the same algorithm would be nice ;-)
I always thought white balance was merely putting a linear scaling
factor on the magnitudes of the red and blue channel compared to
green. Can you point me to someplace explaining the technicalities of
hugin's white balancing algorithm so I can find out about it's special
properties?
And, while asking for documentation, is the openGL preview considering
the colour profile of the monitor, and does it do so an all platforms,
be it via the OS or by itself? Otherwise white balancing would merely
make the image look nice on that particular screen in the hugin
preview.
Kay
Jeffrey Martin
Hi Kay,
I don't think this is a borderline case at all. for anyone who's not experienced shooting panos, this is *completely* a mainstream case - cameras are on auto white balance. you can't and shouldn't expect a normal person to know how to set white balance, or that they should have to lock their white balance. I think this feature is really great.
(Now, about "necessary features". IMO the one huge missing thing is vertical line detection. That's only my opinion, but in my job i see hundreds of panos a day shot by both beginners and experts. and pano levelling, by far, is the main problem with everybody.)
On Friday, March 4, 2011 10:23:18 AM UTC+1, kfj wrote:
paul womack
> Hi Kay,
>
> Am 03.03.2011 18:34, schrieb kfj:
>> Hmmm... I'm very much in two minds about features like this. I feel
>> that image processing functionality should be kept out of hugin. Of
>> course we need to align the images photometrically, but manually
>> finetuning the white balance is close to where I'd draw the border.
>
> I don't think so. Its basically a free lunch, and one that makes
> technically sense, too.
> Having to fix 8 bit images with a second application of a "curves tool"
> will degrade the image quality, if 8 bit images are used.
Yeah; if I'm being really obsessive about cumulative
errors with 8 bit images, I convert to 16 bit right at the start of
processing, and convert back down at the end.
BugBear
Pablo d'Angelo
Am 04.03.2011 10:23, schrieb kfj:
> On 3 Mrz., 19:26, Pablo d'Angelo<pablo.dang...@web.de> wrote:
>
> But just throwing in a new free lunch feature without
> documentation for everyone to figure out how it works by trial and
> error isn't what I consider good style. For example, it took me quite
> a while to figure out that to see any effect of the grey picker at
> all, I had to remove the 'photometric' check mark in the preview. It
> looks a bit like a quick shot to me.
I haven't tested the gray picker yet, so I can't comment the ease of use.
>> Having to fix 8 bit images with a second application of a "curves tool"
>> will degrade the image quality, if 8 bit images are used.
>
> I agree, and, sadly, 16bit isn't yet an option for everyone and
> increases processing time and memory use considerably. The resulting
> degradation from successive processing steps may become quite
> noticable. So there's another good feature waiting: how about an
> option to convert to 16 bit on input and/or convert to 8 bit on
> output? Or am I missing something here?
All the internal processing during remapping is done in floating point,
so no need to convert 8 bit to 16 bit before input. The only drawback is
that enblend will work on the 8 bit images.
> When I process my 16bit TIFFs
> with hugin, I'd quite like to be able to get 8bit TIFF out, but it
> seems like I can only store in 16bit.
I think that on the pto file level, the output bit depth can be
specified, but I don't remember if the up or down casting done there is
useful for your workflow.
>> Second, I haven't found any free image processing application performs
>> white balancing as good as hugin. That said, a gimp or other plugin with
>> the same algorithm would be nice ;-)
>
> You seem to imply that hugin uses a special white balacing algorithm.
> I always thought white balance was merely putting a linear scaling
> factor on the magnitudes of the red and blue channel compared to
> green.
Other tools might do this. For a RAW converter this makes sense, but not
for already processed photos, such as JPEGs. Try adjusting the color
balance of a JPEG using linear scaling in GIMP or some other software. I
found that nearly impossible without introducing various color
distortions (not only related due to the missing dynamic range). Hugin
estimates the camera response curve, much like proper HDR tools do, and
respects that during white balance adjustments, see the paper at
http://hugin.sourceforge.net/tech/ for more details.
> And, while asking for documentation, is the openGL preview considering
> the colour profile of the monitor, and does it do so an all platforms,
> be it via the OS or by itself? Otherwise white balancing would merely
> make the image look nice on that particular screen in the hugin
> preview.
As far as I know, hugin is ignorant of color profiles, other than
passing them through. It would be nice to have a calibrated workflow,
but this doesn't mean that tools for color balancing (and especially a
gray picker) are completely useless.
ciao
Pablo