Additional Zoom levels

[Beep6581]

Originally reported on Google Code with ID 432

There are no zoom levels between 50% and 100%
one or two (or 3) additional levels would be helpful:
50-75-100
or
50-62-75-87-100

Reported by michaelezra000 on 2010-12-25 14:37:54

[Beep6581]

That would require a much more complicated downsampling procedure.  Currently (and recently
implemented) the image is binned in N*N groups of pixels for downsampling by a factor
N.  Hard to bin a fractional number of pixels, and proper bicubic or lanczos resampling
would be required.   I think there are higher priorities for the moment.

Reported by ejm.60657 on 2010-12-25 15:06:41

• Labels added: Type-Enhancement, Priority-Low
• Labels removed: Type-Defect, Priority-Medium

[Beep6581]

That may be complicated, but it has to be done some day. This week I received a new
23-inch monitor, partly for photowork. The link to the screenshot shows that the 'fit
to screen' command (33%) does not fit to screen at all, so "I want my money back!"
:-) Enlarging to 50% is just a bit too much. Pity how much valuable screen state I
loose... 

http://paul.matthijsse.pagespro-orange.fr/tmp/fit-to-screen.jpg

Regards, Paul. 

Reported by paul.matthijsse4 on 2011-01-19 15:01:12

[Beep6581]

bicubic or lanczos are intended for upscaling. here we can suffice with using the downscale
algorithm already present in the code for the 'downscale' resize method.

Reported by janrinze on 2011-01-19 15:28:58

[Beep6581]

if fast down-scaling method is used, we could even implement a continuous zoom, controlled
by a slider

Reported by michaelezra000 on 2011-01-19 15:50:03

[Beep6581]

Bicubic and Lanczos can be used in either direction.  Imagemagick recommends Lanczos
for downsampling, bicubic for upsampling.  Lanczos can be a bit better with aliasing
suppression for downsampling, but can be a bit more time consuming depending how accurate
you want to make it.

I reiterate that this is a low priority.

Reported by ejm.60657 on 2011-01-19 15:50:30

[Beep6581]

http://en.wikipedia.org/wiki/Lanczos_resampling
any interpolation method is essentially used to add data to the 'inbetweens'
The current down sampling method implemented in RT for rescaling is quite adequate
to resist aliasing effects. It even is hardly any bit slower than the current binning
method used for the N-step scaling. If it is 'good enough' for the output scaling then
it surly will be good enough for preview.
The code is already there so we could do some test implementation in 'default'
I agree that current priorities lie elsewhere so this will have to wait a bit.

Reported by janrinze on 2011-01-19 19:23:53

[Beep6581]

Okay, waiting a bit is not a problem, but I guess there are more users around who want
to see a 'real' fit to screen image. In other words, for end users this must be adressed
as soon as possible, because it has to do with the 'sexy-eness' (sexyieness?) of RT.
Seeing such a little 'fit-to-screen' image is simply disappointing... 

Reported by paul.matthijsse4 on 2011-01-19 22:12:20

[Beep6581]

for the tech savvy and people who like to see the quality when using the 'downscale'
algo i hacked together a preliminary patch.
This patch does not change the steps of scaling but will be able to handle other scaling
factors when i get around to track down how 'scale' is used everywhere else.
Currently 'scale' is an integer which is translated to pixel skipping. There are far
too many places where this is used so don't count on an quick conversion just yet.
The algo does not seem to slow down the preview much, actually too little to notice.

Reported by janrinze on 2011-01-19 23:14:18

---

• Attachment: scale.patch

[Beep6581]

Cool Jan, I'll check this tomorrow as it is now 00:47 (night) in the morning. Too late
to do Important Stuff... :-)

Reported by paul.matthijsse4 on 2011-01-19 23:49:49

[Beep6581]

janrinze, I tried this in default - works great!

I have one request, this may not directly relate to the preview scaling problem, but
may be in the same part of the code. When preview image is clicked it becomes largely
pixelated to indicate that re-calculation is in process. The problem is that this pixelation
is overly harsh and it disables visibility of the preview content too much, so dragging
the preview is usually difficult. It would a nice improvement to make pixelation finer
(may be slightly blurred instead, for further "sexiness":), until we eventually migrate
to a full GPU support and this will not be even necessary...). 

Reported by michaelezra000 on 2011-01-20 00:44:47

[Beep6581]

@micheal: they way this intermediate image works is that it copies the pixels from the
small preview in the upperleft of the RT window. Hence the big pixelation.
This is the only full image preview available at the time of scrolling or zooming.
So either we beef up the preview on the top left (and render it down scaled) or we
leave it as-is. I see no problem in the current implementation since it is just a very
short time this pixelated view is visible.

Reported by janrinze on 2011-01-20 10:45:49

[Beep6581]

interesting... So even today we have the windowed processing of the image? - only the
area that fits in the preview? I was under impression that this was on the future development
list. 

I recall that demosaic is done at full resolution, sharpening and noise reduction is
applied when preview is at 100%+, how about other tools? It looks like most work for
developing the full size image is being done during preview. Preview at 50% resolution
is very fast. It would be great if we could use 50% preview, scale that pixelated when
preview image is pressed and let it glide when dragged.

The current level of pixelation feels strange and it is unexpectedly harsh - you just
had the preview in front of you - and it is not intuitive why does it have to be discarded.

This is more addressing user experience, of course, than functionality. 
The user experience would be much smoother if preview image could glide when scrolling.
I remember when that was implemented in ACR, It certainly did make a big difference.
Tool became more fluid and felt "natural" and modern.

Reported by michaelezra000 on 2011-01-20 12:05:01

[Beep6581]

It's the only full image preview that has had all the preview processing done to it;
one still has the red**, green** and blue** arrays from demosaicing, that are the starting
point for preview processing.  One could use those, however it would be similarly jarring
because exposure etc would change as soon as you started scrolling.  Really the issue
is processing overhead to do the pixel processing over the whole image, then crop;
as opposed to crop the image, then pixel process.  The latter is typically much faster
since the preview window is typically <1MP, but then the price to pay is what to display
during scrolling.

Reported by ejm.60657 on 2011-01-20 13:17:22

[Beep6581]

If RT has "processing overhead to do the pixel processing over the whole image, then
crop" - does that mean that there is already a full resolution preview available, but
only portion of the developed image is displayed in the preview pane?

Reported by michaelezra000 on 2011-01-20 14:02:13

[Beep6581]

The demosaiced image, I believe after conversion to the working space and maybe also
gamma transform, is cached.  But all further manipulations -- everything on the editing
tabs for exposure, color etc (modulo those that are done only at 100%) are done on
an as needed basis.  So one would have to do all of those over the whole image, then
crop, in order to have the scrolled image have the same exposure etc.

It could probably be done better.  RT is not very smart about caching at present.

Reported by ejm.60657 on 2011-01-20 15:04:34

[Beep6581]

Issue 737 has been merged into this issue.

Reported by entertheyoni on 2011-06-07 22:29:27

[Beep6581]

I try to clean our bug-tracker a bit: What's the status here?

Is it 'WontFix' or is somebody willing to implement this? I'll close it 'WontFix' in
a week if nobody complains.

Reported by rinni@gmx.net on 2013-01-28 22:30:28

[Beep6581]

Reported by rinni@gmx.net on 2013-02-04 20:44:05

• Status changed: WontFix