Moderators: helmut, XnTriq, xnview
Yes, exactlyhelmut wrote:The speed of the smoothening (high quality) depends on the number of pixels, I guess this is the reason why Pierre uses pixels as units.
Used, because it's slow here tooVery strongly compressed files (e.g. JPG) could have a small file size but a large number of pixels (dimension). So file size would not be fully correct. But even Pierre's current approach has a flaw, what happens if a file is 3000 pixel wide but only 10 pixel high?
So 2048 does not include 5000*1500?xnview wrote:No it's the size in width or height in pixels. So 2048 means >= 2048 x 2048helmut wrote:Good question. I thought it would be width or height. If this is really the case, the wording for the option has to be changed.Hacker wrote:BTW: What is the value you enter there? The image size in pixels? So the default 2048 means images larger than 64*32?
No, include Width > OR height >Hacker wrote:So 2048 does not include 5000*1500?xnview wrote:No it's the size in width or height in pixels. So 2048 means >= 2048 x 2048helmut wrote: Good question. I thought it would be width or height. If this is really the case, the wording for the option has to be changed.
Lesmo16
Hi !
- I agree, I noticed that it isn't very logical… Forward the field should be better.…but what about writing "pixel" behind the TextBox instead where it's now?
K RClo, you mean left from the TextBox?Clo wrote:- I agree, I noticed that it isn't very logical… Forward the field should be better.…but what about writing "pixel" behind the TextBox instead where it's now?
Not a big deal for me, I can fix up that "personally" 
VGClo, thanks for the link.Clo wrote:
- Such little annoyances could be fixed up following the first step of this way…
You will be welcome in the aforesaid thread, if you discover some “snags” here and there … and even if you don't ! 
VGOlivier_G wrote:Maybe we should use what Hacker mentioned previously: the number of pixels (as the surface area: width x height) ?
=> "Use 2-step high quality preview for pictures larger than [X] Mega-Pixels"
Most people know what a "Mega-Pixel" is (thanks to digital cameras) and it does represent exactly the complexity of the operation...
Megapixel refers to the total amount of pixels, not to vertical or horizontal resolution, as in this case. For this wording to match, Pierre would need to change the way the value is checked.Olivier_G wrote:So what about my previous suggestion ?Olivier_G wrote:Maybe we should use what Hacker mentioned previously: the number of pixels (as the surface area: width x height) ?
=> "Use 2-step high quality preview for pictures larger than [X] Mega-Pixels"
Most people know what a "Mega-Pixel" is (thanks to digital cameras) and it does represent exactly the complexity of the operation...
Exactly: my suggestion is not about wording....Hacker wrote:Megapixel refers to the total amount of pixels, not to vertical or horizontal resolution, as in this case. For this wording to match, Pierre would need to change the way the value is checked.Olivier_G wrote:=> "Use 2-step high quality preview for pictures larger than [X] Mega-Pixels"
Yes perhaps better, but not in this release...Olivier_G wrote:Exactly: my suggestion is not about wording....Hacker wrote:Megapixel refers to the total amount of pixels, not to vertical or horizontal resolution, as in this case. For this wording to match, Pierre would need to change the way the value is checked.Olivier_G wrote:=> "Use 2-step high quality preview for pictures larger than [X] Mega-Pixels"
It is about changing the condition itself in order to better reflect the complexity/time of the operation, which seems to be the main issue, here, given Pierre's answers.
This should be part of the current Options reorganization and be moved to View>High Quality Zoom options as well.Olivier_G wrote:2-pass HQ for pictures larger than [X] Mega-Pixels
