Re: [FFmpeg-user] Question about "normalize" filter

2023-02-07 Thread Michael Koch

Am 30.01.2023 um 20:45 schrieb Paul B Mahol:

filter supports up to 16bit rgb(a), adding float would be trivial.
patch welcome

Thanks for adding float to colorlevels.
Is there any filter for gamma correction with float?
Does the geq filter support float?

Yes.


Gamma correction with float precision works with geq filter.
Is there any faster solution?

Michael

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Question about "normalize" filter

2023-01-30 Thread Paul B Mahol
On 1/30/23, Michael Koch  wrote:
> Am 30.01.2023 um 12:52 schrieb Paul B Mahol:
>> On 1/30/23, Michael Koch  wrote:
>>> Am 30.01.2023 um 10:29 schrieb Paul B Mahol:
> You wrote:
>
> "With default parameters and just strength(2) set to your values, so
> the darkest pixels are left  untouched."
>
> However I want that black remains untouched. That's not the same,
> because
> the darkest pixels in the image aren't black.
>
> The workaround is to insert a black pixel before normalizing:
> -vf drawbox=w=1:h=1:color=black,normalize
 This command produces more convincing output:

 -vf colorlevels=rimin=0:gimin=0:bimin=0:rimax=-1:gimax=-1:bimax=-1

 this will pick max pixels values from input and stretch it do default
 output max.
>>> This command gives almost the same result as my workaround.
>>> The meaning of -1 for options is missing in the documentation.
>>> It has the same problem as my workaround: The output is only 8-bit.
>>>
>> filter supports up to 16bit rgb(a), adding float would be trivial.
>> patch welcome
>
> Thanks for adding float to colorlevels.
> Is there any filter for gamma correction with float?
> Does the geq filter support float?

Yes.
>
> Michael
>
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Question about "normalize" filter

2023-01-30 Thread Michael Koch

Am 30.01.2023 um 12:52 schrieb Paul B Mahol:

On 1/30/23, Michael Koch  wrote:

Am 30.01.2023 um 10:29 schrieb Paul B Mahol:

You wrote:

"With default parameters and just strength(2) set to your values, so
the darkest pixels are left  untouched."

However I want that black remains untouched. That's not the same,
because
the darkest pixels in the image aren't black.

The workaround is to insert a black pixel before normalizing:
-vf drawbox=w=1:h=1:color=black,normalize

This command produces more convincing output:

-vf colorlevels=rimin=0:gimin=0:bimin=0:rimax=-1:gimax=-1:bimax=-1

this will pick max pixels values from input and stretch it do default
output max.

This command gives almost the same result as my workaround.
The meaning of -1 for options is missing in the documentation.
It has the same problem as my workaround: The output is only 8-bit.


filter supports up to 16bit rgb(a), adding float would be trivial.
patch welcome


Thanks for adding float to colorlevels.
Is there any filter for gamma correction with float?
Does the geq filter support float?

Michael

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Question about "normalize" filter

2023-01-30 Thread Paul B Mahol
On 1/30/23, Michael Koch  wrote:
> Am 30.01.2023 um 10:29 schrieb Paul B Mahol:
>>> You wrote:
>>>
>>> "With default parameters and just strength(2) set to your values, so
>>> the darkest pixels are left  untouched."
>>>
>>> However I want that black remains untouched. That's not the same,
>>> because
>>> the darkest pixels in the image aren't black.
>>>
>>> The workaround is to insert a black pixel before normalizing:
>>> -vf drawbox=w=1:h=1:color=black,normalize
>> This command produces more convincing output:
>>
>> -vf colorlevels=rimin=0:gimin=0:bimin=0:rimax=-1:gimax=-1:bimax=-1
>>
>> this will pick max pixels values from input and stretch it do default
>> output max.
>
> This command gives almost the same result as my workaround.
> The meaning of -1 for options is missing in the documentation.
> It has the same problem as my workaround: The output is only 8-bit.
>

filter supports up to 16bit rgb(a), adding float would be trivial.
patch welcome

> It would be nice to have all these image processing filters with float
> precision:
> -- Hot pixel removal (save hot pixels in a mask, and replace those
> pixels by average of neighbor pixels)
> -- Dark image subtraction

blend filter, it supports also float rgb.

> -- Flatfield correction (division)
> -- Contrast enhancement (similar as colorlevels)
> -- Gamma correction (might already exist in eq filter with float
> precision, I'm not sure)
>
> For colorlevels it would be nice to have options "imin" and "imax" which
> set all three RGB channels simultaneously to the same value. Makes the
> command line much shorter.
>

Not everything you say makes sense.

> Michael
>
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Question about "normalize" filter

2023-01-30 Thread Michael Koch

Am 30.01.2023 um 10:29 schrieb Paul B Mahol:

You wrote:

"With default parameters and just strength(2) set to your values, so
the darkest pixels are left  untouched."

However I want that black remains untouched. That's not the same, because
the darkest pixels in the image aren't black.

The workaround is to insert a black pixel before normalizing:
-vf drawbox=w=1:h=1:color=black,normalize

This command produces more convincing output:

-vf colorlevels=rimin=0:gimin=0:bimin=0:rimax=-1:gimax=-1:bimax=-1

this will pick max pixels values from input and stretch it do default
output max.


This command gives almost the same result as my workaround.
The meaning of -1 for options is missing in the documentation.
It has the same problem as my workaround: The output is only 8-bit.

It would be nice to have all these image processing filters with float 
precision:
-- Hot pixel removal (save hot pixels in a mask, and replace those 
pixels by average of neighbor pixels)

-- Dark image subtraction
-- Flatfield correction (division)
-- Contrast enhancement (similar as colorlevels)
-- Gamma correction (might already exist in eq filter with float 
precision, I'm not sure)


For colorlevels it would be nice to have options "imin" and "imax" which 
set all three RGB channels simultaneously to the same value. Makes the 
command line much shorter.


Michael

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Question about "normalize" filter

2023-01-30 Thread Paul B Mahol
On 1/30/23, Michael Koch  wrote:
> Am 30.01.2023 um 08:47 schrieb Paul B Mahol:
>> On Mon, Jan 30, 2023 at 12:23 AM Michael Koch
>> 
>> wrote:
>>
>>> Am 29.01.2023 um 23:36 schrieb Paul B Mahol:
 On 1/29/23, Michael Koch  wrote:
> Am 29.01.2023 um 23:07 schrieb Paul B Mahol:
>> On 1/29/23, Michael Koch  wrote:
>>> Am 29.01.2023 um 22:05 schrieb Paul B Mahol:
 On 1/29/23, Michael Koch  wrote:
> Am 29.01.2023 um 19:32 schrieb Paul B Mahol:
>> On 1/29/23, Michael Koch  wrote:
>>> Hello,
>>>
>>> if I understood the documentation correctly, the normalize
>>> filter
>>> maps
>>> the darkest input pixel to blackpt and the brightest input pixel
>>> to
>>> whitept:
>>> darkest pixel --> blackpt
>>> brightest pixel --> whitept
>>>
>>> However I need a slightly different mapping:
>>> A black input pixel shall remain black, and the brightest input
>>> pixel
>>> shall become white.
>>> black --> blackpt
>>> brightest pixel --> whitept
>>>
>>> With other words: Just multiply all pixels by a suitable
>>> constant.
>>> Don't
>>> add or subtract anything.
>>> Is this possible?
>>>
>>> Known workaround: Make sure that the input frame contains a
>>> black
>>> pixel,
>>> by inserting one in a corner.
>> Try attached patch.
> How must I set the options for the desired behaviour?
 Set first strength to reverse of second strength.
 So 1.0 and 0.0 or 0.0 and 1.0
>>> I did try with strength=0:strength2=1 but the output isn't as
>>> expected.
>>> I'm using this input image:
>>> http://www.astro-electronic.de/flat.png
>>>
>>> The pixel values are about 171 in the center and 107 in the top
>>> right
>>> corner.
>>> The center to corner ratio is 171 / 107 = 1.6
>>>
>>> In the output image I measure 248 in the center (which is almost as
>>> expected, probably correct because I'm measuring the average of a
>>> 7x7
>>> neighborhood), but I measure 122 in the top right corner.
>>> The center to corner ratio is 248 / 122 = 2.03
>>> The corner is too dark.
>>>
>> I checked with oscilloscope filter (s=1:tw=1:t=1:x=0), far left
>> pixels
>> (as they are darkest) and they are not changing (min values are same
>> with and without filter run)
>> With default parameters and just strength(2) set to your values, so
>> the darkest pixels are left  untouched. Did not checked brightest
>> pixels output, but they should be correct too.
> But that's not the behaviour I need. All pixels shall be multiplied by
> the same suitable constant, so that the brightest pixel becomes white.
>
> Input center: 171
> Input corner: 107
>
> constant c = 255 / 171 =1.49
> Output center: 171 * c = 255
> Output corner: 107 * c = 160
>
 Normalization does not do that and that functionality does not belong
 to such filter, it stretches ranges of all pixel values so they reach
 maximal possible range.
>>> Can't you just add an option that disables the minimum finding
>>> algorithm, and set the minimum to zero (=black)? That would do the job.
>>>
>> I just did, but for whatever reason you think its incorrect.
>
> You wrote:
>
> "With default parameters and just strength(2) set to your values, so
> the darkest pixels are left  untouched."
>
> However I want that black remains untouched. That's not the same, because
> the darkest pixels in the image aren't black.
>
> The workaround is to insert a black pixel before normalizing:
> -vf drawbox=w=1:h=1:color=black,normalize

This command produces more convincing output:

-vf colorlevels=rimin=0:gimin=0:bimin=0:rimax=-1:gimax=-1:bimax=-1

this will pick max pixels values from input and stretch it do default
output max.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Question about "normalize" filter

2023-01-30 Thread Michael Koch

Am 30.01.2023 um 08:47 schrieb Paul B Mahol:

On Mon, Jan 30, 2023 at 12:23 AM Michael Koch 
wrote:


Am 29.01.2023 um 23:36 schrieb Paul B Mahol:

On 1/29/23, Michael Koch  wrote:

Am 29.01.2023 um 23:07 schrieb Paul B Mahol:

On 1/29/23, Michael Koch  wrote:

Am 29.01.2023 um 22:05 schrieb Paul B Mahol:

On 1/29/23, Michael Koch  wrote:

Am 29.01.2023 um 19:32 schrieb Paul B Mahol:

On 1/29/23, Michael Koch  wrote:

Hello,

if I understood the documentation correctly, the normalize filter
maps
the darkest input pixel to blackpt and the brightest input pixel

to

whitept:
darkest pixel --> blackpt
brightest pixel --> whitept

However I need a slightly different mapping:
A black input pixel shall remain black, and the brightest input
pixel
shall become white.
black --> blackpt
brightest pixel --> whitept

With other words: Just multiply all pixels by a suitable constant.
Don't
add or subtract anything.
Is this possible?

Known workaround: Make sure that the input frame contains a black
pixel,
by inserting one in a corner.

Try attached patch.

How must I set the options for the desired behaviour?

Set first strength to reverse of second strength.
So 1.0 and 0.0 or 0.0 and 1.0

I did try with strength=0:strength2=1 but the output isn't as

expected.

I'm using this input image:
http://www.astro-electronic.de/flat.png

The pixel values are about 171 in the center and 107 in the top right
corner.
The center to corner ratio is 171 / 107 = 1.6

In the output image I measure 248 in the center (which is almost as
expected, probably correct because I'm measuring the average of a 7x7
neighborhood), but I measure 122 in the top right corner.
The center to corner ratio is 248 / 122 = 2.03
The corner is too dark.


I checked with oscilloscope filter (s=1:tw=1:t=1:x=0), far left pixels
(as they are darkest) and they are not changing (min values are same
with and without filter run)
With default parameters and just strength(2) set to your values, so
the darkest pixels are left  untouched. Did not checked brightest
pixels output, but they should be correct too.

But that's not the behaviour I need. All pixels shall be multiplied by
the same suitable constant, so that the brightest pixel becomes white.

Input center: 171
Input corner: 107

constant c = 255 / 171 =1.49
Output center: 171 * c = 255
Output corner: 107 * c = 160


Normalization does not do that and that functionality does not belong
to such filter, it stretches ranges of all pixel values so they reach
maximal possible range.

Can't you just add an option that disables the minimum finding
algorithm, and set the minimum to zero (=black)? That would do the job.


I just did, but for whatever reason you think its incorrect.


You wrote:

"With default parameters and just strength(2) set to your values, so
the darkest pixels are left  untouched."

However I want that black remains untouched. That's not the same, because the 
darkest pixels in the image aren't black.

The workaround is to insert a black pixel before normalizing:
-vf drawbox=w=1:h=1:color=black,normalize

Michael

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Question about "normalize" filter

2023-01-29 Thread Paul B Mahol
On Mon, Jan 30, 2023 at 12:23 AM Michael Koch 
wrote:

> Am 29.01.2023 um 23:36 schrieb Paul B Mahol:
> > On 1/29/23, Michael Koch  wrote:
> >> Am 29.01.2023 um 23:07 schrieb Paul B Mahol:
> >>> On 1/29/23, Michael Koch  wrote:
>  Am 29.01.2023 um 22:05 schrieb Paul B Mahol:
> > On 1/29/23, Michael Koch  wrote:
> >> Am 29.01.2023 um 19:32 schrieb Paul B Mahol:
> >>> On 1/29/23, Michael Koch  wrote:
>  Hello,
> 
>  if I understood the documentation correctly, the normalize filter
>  maps
>  the darkest input pixel to blackpt and the brightest input pixel
> to
>  whitept:
>  darkest pixel --> blackpt
>  brightest pixel --> whitept
> 
>  However I need a slightly different mapping:
>  A black input pixel shall remain black, and the brightest input
>  pixel
>  shall become white.
>  black --> blackpt
>  brightest pixel --> whitept
> 
>  With other words: Just multiply all pixels by a suitable constant.
>  Don't
>  add or subtract anything.
>  Is this possible?
> 
>  Known workaround: Make sure that the input frame contains a black
>  pixel,
>  by inserting one in a corner.
> >>> Try attached patch.
> >> How must I set the options for the desired behaviour?
> > Set first strength to reverse of second strength.
> > So 1.0 and 0.0 or 0.0 and 1.0
>  I did try with strength=0:strength2=1 but the output isn't as
> expected.
> 
>  I'm using this input image:
>  http://www.astro-electronic.de/flat.png
> 
>  The pixel values are about 171 in the center and 107 in the top right
>  corner.
>  The center to corner ratio is 171 / 107 = 1.6
> 
>  In the output image I measure 248 in the center (which is almost as
>  expected, probably correct because I'm measuring the average of a 7x7
>  neighborhood), but I measure 122 in the top right corner.
>  The center to corner ratio is 248 / 122 = 2.03
>  The corner is too dark.
> 
> >>> I checked with oscilloscope filter (s=1:tw=1:t=1:x=0), far left pixels
> >>> (as they are darkest) and they are not changing (min values are same
> >>> with and without filter run)
> >>> With default parameters and just strength(2) set to your values, so
> >>> the darkest pixels are left  untouched. Did not checked brightest
> >>> pixels output, but they should be correct too.
> >> But that's not the behaviour I need. All pixels shall be multiplied by
> >> the same suitable constant, so that the brightest pixel becomes white.
> >>
> >> Input center: 171
> >> Input corner: 107
> >>
> >> constant c = 255 / 171 =1.49
> >> Output center: 171 * c = 255
> >> Output corner: 107 * c = 160
> >>
> > Normalization does not do that and that functionality does not belong
> > to such filter, it stretches ranges of all pixel values so they reach
> > maximal possible range.
>
> Can't you just add an option that disables the minimum finding
> algorithm, and set the minimum to zero (=black)? That would do the job.
>

I just did, but for whatever reason you think its incorrect.


>
> Let me explain why I need this kind of normalization.
> Most lenses have vignetting. Especially in astronomical images,
> vignetting must be corrected before any other image processing can be
> done. For this purpose a flatfield image is taken with the same lens at
> the same aperture, but with a uniform white screen in front of the lens.
> Normally the flatfield image is exposed at roughly 50% gray level, to
> avoid problems with nonlinearity near white level. The linked image is
> the flatfield.
> Vignetting in an astronomical image is corrected by dividing the image
> by the flatfield. That can be done with the blend filter.
> If I use the flatfied as-is (with roughly 50% gray level), then the
> image is effectively multiplied by a factor 2. That's a problem because
> bright pixels might get clipped. To minimize this problem, I want to
> normalize the flatfield as close to white level as possible, before
> using it.
>
> Michael
>
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Question about "normalize" filter

2023-01-29 Thread Michael Koch

Am 29.01.2023 um 23:36 schrieb Paul B Mahol:

On 1/29/23, Michael Koch  wrote:

Am 29.01.2023 um 23:07 schrieb Paul B Mahol:

On 1/29/23, Michael Koch  wrote:

Am 29.01.2023 um 22:05 schrieb Paul B Mahol:

On 1/29/23, Michael Koch  wrote:

Am 29.01.2023 um 19:32 schrieb Paul B Mahol:

On 1/29/23, Michael Koch  wrote:

Hello,

if I understood the documentation correctly, the normalize filter
maps
the darkest input pixel to blackpt and the brightest input pixel to
whitept:
darkest pixel --> blackpt
brightest pixel --> whitept

However I need a slightly different mapping:
A black input pixel shall remain black, and the brightest input
pixel
shall become white.
black --> blackpt
brightest pixel --> whitept

With other words: Just multiply all pixels by a suitable constant.
Don't
add or subtract anything.
Is this possible?

Known workaround: Make sure that the input frame contains a black
pixel,
by inserting one in a corner.

Try attached patch.

How must I set the options for the desired behaviour?

Set first strength to reverse of second strength.
So 1.0 and 0.0 or 0.0 and 1.0

I did try with strength=0:strength2=1 but the output isn't as expected.

I'm using this input image:
http://www.astro-electronic.de/flat.png

The pixel values are about 171 in the center and 107 in the top right
corner.
The center to corner ratio is 171 / 107 = 1.6

In the output image I measure 248 in the center (which is almost as
expected, probably correct because I'm measuring the average of a 7x7
neighborhood), but I measure 122 in the top right corner.
The center to corner ratio is 248 / 122 = 2.03
The corner is too dark.


I checked with oscilloscope filter (s=1:tw=1:t=1:x=0), far left pixels
(as they are darkest) and they are not changing (min values are same
with and without filter run)
With default parameters and just strength(2) set to your values, so
the darkest pixels are left  untouched. Did not checked brightest
pixels output, but they should be correct too.

But that's not the behaviour I need. All pixels shall be multiplied by
the same suitable constant, so that the brightest pixel becomes white.

Input center: 171
Input corner: 107

constant c = 255 / 171 =1.49
Output center: 171 * c = 255
Output corner: 107 * c = 160


Normalization does not do that and that functionality does not belong
to such filter, it stretches ranges of all pixel values so they reach
maximal possible range.


Can't you just add an option that disables the minimum finding 
algorithm, and set the minimum to zero (=black)? That would do the job.


Let me explain why I need this kind of normalization.
Most lenses have vignetting. Especially in astronomical images, 
vignetting must be corrected before any other image processing can be 
done. For this purpose a flatfield image is taken with the same lens at 
the same aperture, but with a uniform white screen in front of the lens. 
Normally the flatfield image is exposed at roughly 50% gray level, to 
avoid problems with nonlinearity near white level. The linked image is 
the flatfield.
Vignetting in an astronomical image is corrected by dividing the image 
by the flatfield. That can be done with the blend filter.
If I use the flatfied as-is (with roughly 50% gray level), then the 
image is effectively multiplied by a factor 2. That's a problem because 
bright pixels might get clipped. To minimize this problem, I want to 
normalize the flatfield as close to white level as possible, before 
using it.


Michael

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Question about "normalize" filter

2023-01-29 Thread Paul B Mahol
On 1/29/23, Michael Koch  wrote:
> Am 29.01.2023 um 23:07 schrieb Paul B Mahol:
>> On 1/29/23, Michael Koch  wrote:
>>> Am 29.01.2023 um 22:05 schrieb Paul B Mahol:
 On 1/29/23, Michael Koch  wrote:
> Am 29.01.2023 um 19:32 schrieb Paul B Mahol:
>> On 1/29/23, Michael Koch  wrote:
>>> Hello,
>>>
>>> if I understood the documentation correctly, the normalize filter
>>> maps
>>> the darkest input pixel to blackpt and the brightest input pixel to
>>> whitept:
>>> darkest pixel --> blackpt
>>> brightest pixel --> whitept
>>>
>>> However I need a slightly different mapping:
>>> A black input pixel shall remain black, and the brightest input
>>> pixel
>>> shall become white.
>>> black --> blackpt
>>> brightest pixel --> whitept
>>>
>>> With other words: Just multiply all pixels by a suitable constant.
>>> Don't
>>> add or subtract anything.
>>> Is this possible?
>>>
>>> Known workaround: Make sure that the input frame contains a black
>>> pixel,
>>> by inserting one in a corner.
>> Try attached patch.
> How must I set the options for the desired behaviour?
 Set first strength to reverse of second strength.
 So 1.0 and 0.0 or 0.0 and 1.0
>>> I did try with strength=0:strength2=1 but the output isn't as expected.
>>>
>>> I'm using this input image:
>>> http://www.astro-electronic.de/flat.png
>>>
>>> The pixel values are about 171 in the center and 107 in the top right
>>> corner.
>>> The center to corner ratio is 171 / 107 = 1.6
>>>
>>> In the output image I measure 248 in the center (which is almost as
>>> expected, probably correct because I'm measuring the average of a 7x7
>>> neighborhood), but I measure 122 in the top right corner.
>>> The center to corner ratio is 248 / 122 = 2.03
>>> The corner is too dark.
>>>
>> I checked with oscilloscope filter (s=1:tw=1:t=1:x=0), far left pixels
>> (as they are darkest) and they are not changing (min values are same
>> with and without filter run)
>> With default parameters and just strength(2) set to your values, so
>> the darkest pixels are left  untouched. Did not checked brightest
>> pixels output, but they should be correct too.
>
> But that's not the behaviour I need. All pixels shall be multiplied by
> the same suitable constant, so that the brightest pixel becomes white.
>
> Input center: 171
> Input corner: 107
>
> constant c = 255 / 171 =1.49
> Output center: 171 * c = 255
> Output corner: 107 * c = 160
>

Normalization does not do that and that functionality does not belong
to such filter, it stretches ranges of all pixel values so they reach
maximal possible range.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Question about "normalize" filter

2023-01-29 Thread Michael Koch

Am 29.01.2023 um 23:07 schrieb Paul B Mahol:

On 1/29/23, Michael Koch  wrote:

Am 29.01.2023 um 22:05 schrieb Paul B Mahol:

On 1/29/23, Michael Koch  wrote:

Am 29.01.2023 um 19:32 schrieb Paul B Mahol:

On 1/29/23, Michael Koch  wrote:

Hello,

if I understood the documentation correctly, the normalize filter maps
the darkest input pixel to blackpt and the brightest input pixel to
whitept:
darkest pixel --> blackpt
brightest pixel --> whitept

However I need a slightly different mapping:
A black input pixel shall remain black, and the brightest input pixel
shall become white.
black --> blackpt
brightest pixel --> whitept

With other words: Just multiply all pixels by a suitable constant.
Don't
add or subtract anything.
Is this possible?

Known workaround: Make sure that the input frame contains a black
pixel,
by inserting one in a corner.

Try attached patch.

How must I set the options for the desired behaviour?

Set first strength to reverse of second strength.
So 1.0 and 0.0 or 0.0 and 1.0

I did try with strength=0:strength2=1 but the output isn't as expected.

I'm using this input image:
http://www.astro-electronic.de/flat.png

The pixel values are about 171 in the center and 107 in the top right
corner.
The center to corner ratio is 171 / 107 = 1.6

In the output image I measure 248 in the center (which is almost as
expected, probably correct because I'm measuring the average of a 7x7
neighborhood), but I measure 122 in the top right corner.
The center to corner ratio is 248 / 122 = 2.03
The corner is too dark.


I checked with oscilloscope filter (s=1:tw=1:t=1:x=0), far left pixels
(as they are darkest) and they are not changing (min values are same
with and without filter run)
With default parameters and just strength(2) set to your values, so
the darkest pixels are left  untouched. Did not checked brightest
pixels output, but they should be correct too.


But that's not the behaviour I need. All pixels shall be multiplied by 
the same suitable constant, so that the brightest pixel becomes white.


Input center: 171
Input corner: 107

constant c = 255 / 171 =1.49
Output center: 171 * c = 255
Output corner: 107 * c = 160

Michael

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Question about "normalize" filter

2023-01-29 Thread Paul B Mahol
On 1/29/23, Michael Koch  wrote:
> Am 29.01.2023 um 22:05 schrieb Paul B Mahol:
>> On 1/29/23, Michael Koch  wrote:
>>> Am 29.01.2023 um 19:32 schrieb Paul B Mahol:
 On 1/29/23, Michael Koch  wrote:
> Hello,
>
> if I understood the documentation correctly, the normalize filter maps
> the darkest input pixel to blackpt and the brightest input pixel to
> whitept:
> darkest pixel --> blackpt
> brightest pixel --> whitept
>
> However I need a slightly different mapping:
> A black input pixel shall remain black, and the brightest input pixel
> shall become white.
> black --> blackpt
> brightest pixel --> whitept
>
> With other words: Just multiply all pixels by a suitable constant.
> Don't
> add or subtract anything.
> Is this possible?
>
> Known workaround: Make sure that the input frame contains a black
> pixel,
> by inserting one in a corner.
 Try attached patch.
>>> How must I set the options for the desired behaviour?
>> Set first strength to reverse of second strength.
>> So 1.0 and 0.0 or 0.0 and 1.0
>
> I did try with strength=0:strength2=1 but the output isn't as expected.
>
> I'm using this input image:
> http://www.astro-electronic.de/flat.png
>
> The pixel values are about 171 in the center and 107 in the top right
> corner.
> The center to corner ratio is 171 / 107 = 1.6
>
> In the output image I measure 248 in the center (which is almost as
> expected, probably correct because I'm measuring the average of a 7x7
> neighborhood), but I measure 122 in the top right corner.
> The center to corner ratio is 248 / 122 = 2.03
> The corner is too dark.
>

I checked with oscilloscope filter (s=1:tw=1:t=1:x=0), far left pixels
(as they are darkest) and they are not changing (min values are same
with and without filter run)
With default parameters and just strength(2) set to your values, so
the darkest pixels are left  untouched. Did not checked brightest
pixels output, but they should be correct too.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Question about "normalize" filter

2023-01-29 Thread Michael Koch

Am 29.01.2023 um 22:05 schrieb Paul B Mahol:

On 1/29/23, Michael Koch  wrote:

Am 29.01.2023 um 19:32 schrieb Paul B Mahol:

On 1/29/23, Michael Koch  wrote:

Hello,

if I understood the documentation correctly, the normalize filter maps
the darkest input pixel to blackpt and the brightest input pixel to
whitept:
darkest pixel --> blackpt
brightest pixel --> whitept

However I need a slightly different mapping:
A black input pixel shall remain black, and the brightest input pixel
shall become white.
black --> blackpt
brightest pixel --> whitept

With other words: Just multiply all pixels by a suitable constant. Don't
add or subtract anything.
Is this possible?

Known workaround: Make sure that the input frame contains a black pixel,
by inserting one in a corner.

Try attached patch.

How must I set the options for the desired behaviour?

Set first strength to reverse of second strength.
So 1.0 and 0.0 or 0.0 and 1.0


I did try with strength=0:strength2=1 but the output isn't as expected.

I'm using this input image:
http://www.astro-electronic.de/flat.png

The pixel values are about 171 in the center and 107 in the top right 
corner.

The center to corner ratio is 171 / 107 = 1.6

In the output image I measure 248 in the center (which is almost as 
expected, probably correct because I'm measuring the average of a 7x7 
neighborhood), but I measure 122 in the top right corner.

The center to corner ratio is 248 / 122 = 2.03
The corner is too dark.

Michael

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Question about "normalize" filter

2023-01-29 Thread Paul B Mahol
On 1/29/23, Michael Koch  wrote:
> Am 29.01.2023 um 19:32 schrieb Paul B Mahol:
>> On 1/29/23, Michael Koch  wrote:
>>> Hello,
>>>
>>> if I understood the documentation correctly, the normalize filter maps
>>> the darkest input pixel to blackpt and the brightest input pixel to
>>> whitept:
>>> darkest pixel --> blackpt
>>> brightest pixel --> whitept
>>>
>>> However I need a slightly different mapping:
>>> A black input pixel shall remain black, and the brightest input pixel
>>> shall become white.
>>> black --> blackpt
>>> brightest pixel --> whitept
>>>
>>> With other words: Just multiply all pixels by a suitable constant. Don't
>>> add or subtract anything.
>>> Is this possible?
>>>
>>> Known workaround: Make sure that the input frame contains a black pixel,
>>> by inserting one in a corner.
>> Try attached patch.
>
> How must I set the options for the desired behaviour?

Set first strength to reverse of second strength.
So 1.0 and 0.0 or 0.0 and 1.0

>
> Micheal
>
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Question about "normalize" filter

2023-01-29 Thread Michael Koch

Am 29.01.2023 um 19:32 schrieb Paul B Mahol:

On 1/29/23, Michael Koch  wrote:

Hello,

if I understood the documentation correctly, the normalize filter maps
the darkest input pixel to blackpt and the brightest input pixel to
whitept:
darkest pixel --> blackpt
brightest pixel --> whitept

However I need a slightly different mapping:
A black input pixel shall remain black, and the brightest input pixel
shall become white.
black --> blackpt
brightest pixel --> whitept

With other words: Just multiply all pixels by a suitable constant. Don't
add or subtract anything.
Is this possible?

Known workaround: Make sure that the input frame contains a black pixel,
by inserting one in a corner.

Try attached patch.


How must I set the options for the desired behaviour?

Micheal

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-user] Question about "normalize" filter

2023-01-29 Thread Paul B Mahol
On 1/29/23, Michael Koch  wrote:
> Hello,
>
> if I understood the documentation correctly, the normalize filter maps
> the darkest input pixel to blackpt and the brightest input pixel to
> whitept:
> darkest pixel --> blackpt
> brightest pixel --> whitept
>
> However I need a slightly different mapping:
> A black input pixel shall remain black, and the brightest input pixel
> shall become white.
> black --> blackpt
> brightest pixel --> whitept
>
> With other words: Just multiply all pixels by a suitable constant. Don't
> add or subtract anything.
> Is this possible?
>
> Known workaround: Make sure that the input frame contains a black pixel,
> by inserting one in a corner.

Try attached patch.


>
> Michael
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
>
diff --git a/libavfilter/vf_normalize.c b/libavfilter/vf_normalize.c
index 43ed3c67b3..91499bd009 100644
--- a/libavfilter/vf_normalize.c
+++ b/libavfilter/vf_normalize.c
@@ -101,7 +101,9 @@ typedef struct NormalizeContext {
 uint8_t whitept[4];
 int smoothing;
 float independence;
+float independence2;
 float strength;
+float strength2;
 
 uint8_t co[4];  // Offsets to R,G,B,A bytes respectively in each pixel
 int depth;
@@ -132,6 +134,8 @@ static const AVOption normalize_options[] = {
 { "smoothing",  "amount of temporal smoothing of the input range, to reduce flicker", OFFSET(smoothing), AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX/8, FLAGS },
 { "independence", "proportion of independent to linked channel normalization", OFFSET(independence), AV_OPT_TYPE_FLOAT, {.dbl=1.0}, 0.0, 1.0, FLAGSR },
 { "strength", "strength of filter, from no effect to full normalization", OFFSET(strength), AV_OPT_TYPE_FLOAT, {.dbl=1.0}, 0.0, 1.0, FLAGSR },
+{ "independence2", "proportion of independent to linked channel normalization, for brightest input", OFFSET(independence2), AV_OPT_TYPE_FLOAT, {.dbl=-1.0}, -1.0, 1.0, FLAGSR },
+{ "strength2", "strength of filter, from no effect to full normalization, for brightest input", OFFSET(strength2), AV_OPT_TYPE_FLOAT, {.dbl=-1.0}, -1.0, 1.0, FLAGSR },
 { NULL }
 };
 
@@ -335,22 +339,30 @@ static void normalize(NormalizeContext *s, AVFrame *in, AVFrame *out)
 // Now, process each channel to determine the input and output range and
 // build the lookup tables.
 for (c = 0; c < 3; c++) {
+float strength[2], independence[2];
 int in_val;
+
+strength[0] = s->strength;
+strength[1] = s->strength2 >= 0.f ? s->strength2 : s->strength;
+
+independence[0] = s->independence;
+independence[1] = s->independence2 >= 0.f ? s->independence2 : s->independence;
+
 // Adjust the input range for this channel [min.smoothed,max.smoothed]
 // by mixing in the correct proportion of the linked normalization
 // input range [rgb_min_smoothed,rgb_max_smoothed].
-min[c].smoothed = (min[c].smoothed  * s->independence)
-+ (rgb_min_smoothed * (1.0f - s->independence));
-max[c].smoothed = (max[c].smoothed  * s->independence)
-+ (rgb_max_smoothed * (1.0f - s->independence));
+min[c].smoothed = (min[c].smoothed  * independence[0])
++ (rgb_min_smoothed * (1.0f - independence[0]));
+max[c].smoothed = (max[c].smoothed  * independence[1])
++ (rgb_max_smoothed * (1.0f - independence[1]));
 
 // Calculate the output range [min.out,max.out] as a ratio of the full-
 // strength output range [blackpt,whitept] and the original input range
 // [min.in,max.in], based on the user-specified filter strength.
-min[c].out = (s->sblackpt[c] *s->strength)
-   + (min[c].in * (1.0f - s->strength));
-max[c].out = (s->swhitept[c] *s->strength)
-   + (max[c].in * (1.0f - s->strength));
+min[c].out = (s->sblackpt[c] *strength[0])
+   + (min[c].in * (1.0f - strength[0]));
+max[c].out = (s->swhitept[c] *strength[1])
+   + (max[c].in * (1.0f - strength[1]));
 
 // Now, build a lookup table which linearly maps the adjusted input range
 // [min.smoothed,max.smoothed] to the output range [min.out,max.out].
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".


[FFmpeg-user] Question about "normalize" filter

2023-01-29 Thread Michael Koch

Hello,

if I understood the documentation correctly, the normalize filter maps 
the darkest input pixel to blackpt and the brightest input pixel to whitept:

darkest pixel --> blackpt
brightest pixel --> whitept

However I need a slightly different mapping:
A black input pixel shall remain black, and the brightest input pixel 
shall become white.

black --> blackpt
brightest pixel --> whitept

With other words: Just multiply all pixels by a suitable constant. Don't 
add or subtract anything.

Is this possible?

Known workaround: Make sure that the input frame contains a black pixel, 
by inserting one in a corner.


Michael
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".