adam/Piwigo
1
0 Fork 0
mirror of https://github.com/Piwigo/Piwigo.git synced 2026-10-30 21:52:00 +01:00
Code Issues 657 Packages Projects Releases Wiki Activity

search filter, wrong limits on upper range limit #522

New Issue
Closed
opened 2026-10-05 00:02:09 +02:00 by adam · 5 comments
adam commented 2026-10-05 00:02:09 +02:00
Owner
Copy link
Copy source

On Batch Manager, search filter, after some user reports of unexpected results, I made a few tests:

filesize:<0.150m     => 1024*filesize <1149999 
filesize:0.15m..0.8m => 1024*filesize >=150000  AND 1024*filesize <=1799999
filesize:>0.8m       => 1024*filesize >800000

filesize:<150k      => 1024*filesize <150999 
filesize:150k..800k => 1024*filesize >=150000  AND 1024*filesize <=800999
filesize:>800k      => 1024*filesize >800000

The range lower limit seems fine in every case. The upper limit on the other side is quite "unexpected" :-/

Converting 0.8m to 1799999 (nearly 1.8MB) is a bit too much :-)

As far as I imagine, the "k" or "m" notation can only apply to the filesize. The filesize is stored in kB in the data base, so why should we multiply the images.filesize by 1024 and add 999 if it's in kB or 999999 if it's in mB? If we simply remove the if ($i) $val += 999; (or if ($i) $val += 999999; if in mB), then we get :

filesize:<0.150m     => 1024*filesize <150000
filesize:0.15m..0.8m => 1024*filesize >=150000  AND 1024*filesize <=800000
filesize:>0.8m       => 1024*filesize >800000

filesize:<150k      => 1024*filesize <150000
filesize:150k..800k => 1024*filesize >=150000  AND 1024*filesize <=800000 
filesize:>800k      => 1024*filesize >800000

which sounds more accurate to me.

On Batch Manager, search filter, after some user reports of unexpected results, I made a few tests: ``` filesize:<0.150m => 1024*filesize <1149999 filesize:0.15m..0.8m => 1024*filesize >=150000 AND 1024*filesize <=1799999 filesize:>0.8m => 1024*filesize >800000 filesize:<150k => 1024*filesize <150999 filesize:150k..800k => 1024*filesize >=150000 AND 1024*filesize <=800999 filesize:>800k => 1024*filesize >800000 ``` The range lower limit seems fine in every case. The upper limit on the other side is quite "unexpected" :-/ Converting 0.8m to 1799999 (nearly 1.8MB) is a bit too much :-) As far as I imagine, the "k" or "m" notation can only apply to the filesize. The filesize is stored in kB in the data base, so why should we multiply the images.filesize by 1024 and add 999 if it's in kB or 999999 if it's in mB? If we simply remove the `if ($i) $val += 999;` (or `if ($i) $val += 999999;` if in mB), then we get : ``` filesize:<0.150m => 1024*filesize <150000 filesize:0.15m..0.8m => 1024*filesize >=150000 AND 1024*filesize <=800000 filesize:>0.8m => 1024*filesize >800000 filesize:<150k => 1024*filesize <150000 filesize:150k..800k => 1024*filesize >=150000 AND 1024*filesize <=800000 filesize:>800k => 1024*filesize >800000 ``` which sounds more accurate to me. <!-- github-sync-id:194053213 -->
adam closed this issue 2026-10-05 00:02:09 +02:00
adam commented 2026-10-05 00:02:10 +02:00
Author
Owner
Copy link
Copy source

k/m apply to any numeric search scope.
I agree there is an issue on your example. When I wrote it, I had in mind that "size:6m" will give you 6 mega pixels images meaning anything between 6000000 and 6999999 pixels.

Maybe we could look at the requested precision? Not sure what would be best...

k/m apply to any numeric search scope. I agree there is an issue on your example. When I wrote it, I had in mind that "size:6m" will give you 6 mega pixels images meaning anything between 6000000 and 6999999 pixels. Maybe we could look at the requested precision? Not sure what would be best... <!-- github-comment-id:265474771 -->
adam commented 2026-10-05 00:02:11 +02:00
Author
Owner
Copy link
Copy source

I had not the "size" in mind, only the "filesize". I agree that size:6m should return anything between 6,000,000 and 6,999,999 pixels. So the problem is when you search a "range" ie {<X} or {X..Y} or {>X}

With commit https://github.com/Piwigo/Piwigo/commit/0a90a68915d850a0af2ef6a79dd5a48bf410af79 now I get :

filesize:<0.15m        1024*filesize <150000
filesize:0.15m..0.8m   1024*filesize >=150000  AND 1024*filesize <=899999
filesize:>0.8m         1024*filesize >800000

Which is not what we can expect I guess: a photo with filesize 832kB would match the 2 last filters while the user obviously wants to separate 3 groups of photos.

As far as I understand the problem, the "trick" to add 999 to the value is only relevant on the upper limit of a "fake" range (6000000<X<6999999 when searching filesize:6m) and not when the user explicitely searches for a range.

I had not the "size" in mind, only the "filesize". I agree that size:6m should return anything between 6,000,000 and 6,999,999 pixels. So the problem is when you search a "range" ie {<X} or {X..Y} or {>X} With commit https://github.com/Piwigo/Piwigo/commit/0a90a68915d850a0af2ef6a79dd5a48bf410af79 now I get : ``` filesize:<0.15m 1024*filesize <150000 filesize:0.15m..0.8m 1024*filesize >=150000 AND 1024*filesize <=899999 filesize:>0.8m 1024*filesize >800000 ``` Which is not what we can expect I guess: a photo with filesize 832kB would match the 2 last filters while the user obviously wants to separate 3 groups of photos. As far as I understand the problem, the "trick" to add 999 to the value is only relevant on the upper limit of a "fake" range (6000000<X<6999999 when searching filesize:6m) and not when the user explicitely searches for a range. <!-- github-comment-id:265966637 -->
adam commented 2026-10-05 00:02:11 +02:00
Author
Owner
Copy link
Copy source

But then size:6m and size:>6m will also return overlapping results. Maybe we should get rid of this and that's it - searching for sizes (either file or pixels) should always be range like to make sense ...

What do you think ?

But then size:6m and size:>6m will also return overlapping results. Maybe we should get rid of this and that's it - searching for sizes (either file or pixels) should always be range like to make sense ... What do you think ? <!-- github-comment-id:265984115 -->
adam commented 2026-10-05 00:02:12 +02:00
Author
Owner
Copy link
Copy source
size:6m    width*height >=6000000  AND width*height <=6999999
size:>6m   width*height >6000000

... makes perfectly sense to me. Yes you have overlapping results but that's not a problem here, in my opinion. Searching for "exactly" 6,000,000 pixels is nonsense. And if you want that anyway, you just search {size:6000000}.

For me, the "trick" to convert {size:6m} in {size:6000000..6999999} is smart, but converting {size:1m..2m} to {size:1000000..2999999} produces unexpected results.

``` size:6m width*height >=6000000 AND width*height <=6999999 size:>6m width*height >6000000 ``` ... makes perfectly sense to me. Yes you have overlapping results but that's not a problem here, in my opinion. Searching for "exactly" 6,000,000 pixels is nonsense. And if you want that anyway, you just search {size:6000000}. For me, the "trick" to convert {size:6m} in {size:6000000..6999999} is smart, but converting {size:1m..2m} to {size:1000000..2999999} produces unexpected results. <!-- github-comment-id:265986344 -->
adam commented 2026-10-05 00:02:13 +02:00
Author
Owner
Copy link
Copy source

Ok. Let's have the trick only when the range is not explicit.
I'll do it

On Dec 9, 2016 11:51, "Pierrick Le Gall" notifications@github.com wrote:

size:6m widthheight >=6000000 AND widthheight <=6999999
size:>6m width*height >6000000

... makes perfectly sense to me. Yes you have overlapping results but
that's not a problem here, in my opinion. Searching for "exactly" 6,000,000
pixels is nonsense. And if you want that anyway, you just search
{size:6000000}.

For me, the "trick" to convert {size:6m} in {size:6000000..6999999} is
smart, but converting {size:1m..2m} to {size:1000000..2999999} produces
unexpected results.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/Piwigo/Piwigo/issues/563#issuecomment-265986344, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AJRc9v40mCaZHBokGUujVa4rmnrWRFkNks5rGTKWgaJpZM4LGm4O
.

Ok. Let's have the trick only when the range is not explicit. I'll do it On Dec 9, 2016 11:51, "Pierrick Le Gall" <notifications@github.com> wrote: > size:6m width*height >=6000000 AND width*height <=6999999 > size:>6m width*height >6000000 > > ... makes perfectly sense to me. Yes you have overlapping results but > that's not a problem here, in my opinion. Searching for "exactly" 6,000,000 > pixels is nonsense. And if you want that anyway, you just search > {size:6000000}. > > For me, the "trick" to convert {size:6m} in {size:6000000..6999999} is > smart, but converting {size:1m..2m} to {size:1000000..2999999} produces > unexpected results. > > — > You are receiving this because you modified the open/close state. > Reply to this email directly, view it on GitHub > <https://github.com/Piwigo/Piwigo/issues/563#issuecomment-265986344>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AJRc9v40mCaZHBokGUujVa4rmnrWRFkNks5rGTKWgaJpZM4LGm4O> > . > <!-- github-comment-id:266000211 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/Piwigo#522