Re: [ginp-users] Question about JPEG scaling

[Doug C. <do...@cu...>]

Dear Brian,

I will not start a discussion about the merits of different algorithms because 
I know nothing about them, but I can state the logic in the ginp and an 
explanation for it.

The scaling of images is done on the sever and javascript is used to calculate 
the correct size of the browsers window.  This saves network traffic, but 
increases load on the server.  For a high quality picture the user should 
click on the link to download the original (which is avaliable in the Taglib 
interface).  The thumb nails are scaled when first requested and then saved 
to disk because they are always the same size.  (This reuses server load a 
lot.)

The scaling is none using a standard Java API and it does reduce the quality 
of the images.  It may be possible to scale using a better quality factor but 
this will cost network bandwidth.

This issue is a compromise between server load, network bandwidth and image 
quality.  I used defaults because that was easy and worked fine for me.  
However if you wish this to be configurable then send me a patch... ;-)

All the best,

Doug


On Sunday 26 March 2006 16:36, Brian Burch wrote:
> I suspect this is a well-understood issue, but it isn't mentioned in the
> mailing list archives. If someone knows about it, please take the time to
> point me in the right direction. I don't want to waste a lot of time
> reinventing the wheel.
>
> I can see that the javascript from ginpservlet retrieves the
> Window.innerHeigth and Window.innerWidth values from the browser. I can see
> the image displayed in the browser window is a jpeg, scaled to fit. For
> example, I'm looking at one which is 700 x 525 pixels. The original jpeg
> file accesed by ginp is 2848 x 2136 pixels.
>
> The resultant image is counter-intuitively poor quality. I have in mind
> that analogue photographic images get more grainy when you enlarge them,
> and more precise when you reduce them. I realise something more subtle must
> happen when you scale-down a digital image... after all, you can't put 4
> pixels of image into a single pixel of a display panel. An algorithm must
> be deciding how best to summarise the image into the target pixel, and that
> decision must be influenced by the neighbouring partial-image properties.
> As you can tell, this is not a subject I've thought seriously about, but
> I'm sure lots of clever people have!
>
> Now, before we start on a discussion of the limitations and merits of
> different algorithms, let me say that this isn't what I want to discuss. My
> issues are much simpler.
>
> I run ginp under java 1.5 with ubuntu 5.10. I also run a much older photo
> album webapp, written in perl and running on an old redhat 7 system. They
> BOTH scale the SAME photos to very similar sizes and quality, so I deduce
> that I'm not dealing with a subtle algorithmic issue.
>
> I've looked at image quality with windoze, OS2 and linux. I've used
> firefox, mozilla, internet exploder and even opera. I've used 5 different
> hardware platforms, each with different video cards and displays. The
> results are near enough to identical that I deduce I'm not dealing with a
> specific browser/OS/hardware problem.
>
> Here's the wierd thing. When I view the original jpeg file under ANY of the
> os's native image viewers, it ALWAYS has crisper details than when
> displayed via a browser/webapp on the same system. I could be convinced
> that a modern native viewer could beat remote scaling and browser
> rendering, if that really is the case, but I don't believe it is....
>
> e.g. a 10-year old OS2 image viewer shows a crisper rendering of an image
> of a particular size than firefox/ginp on very new hardware... and mozilla
> under OS2 doesn't do any better or worse than the linux/firefox
> combination. Similarly, eye-of-gnome-2.12.1 doesn't do much better than my
> OS2 viewer, but (of course) it does a lot better than the browser/webapp
> image.
>
> So, to summarise, it seems to be an architectural issue - scaling on the
> server and rendering on the browser seems to give a (subjective) 15 percent
> drop in image quality when compared to scaling-and-rendering on a single
> platform. This effect appears to be independent of hardware, operating
> system, browser, viewer, display type, scaling algorithm, etc.
>
> What is the missing factor? Wouldn't it be nice if we could "adjust" the
> server-side logic to improve the browser-side image quality by 15 percent?
>
> p.s. you can try this at home. Just look at the same photo on the same
> machine with a) a browser talking to ginp, and b) the native OS image
> viewer. Size the two images so they take up roughly the same real-estate
> and reload if necessary to get them re-scaled. Look for some detail in the
> distance, such as lamp posts, yacht masts, people, dogs, railings... and
> compare the resolution of these details between the 2 images on your
> screen.
>
> I hope someone can help me understand this puzzling issue.
>
>
>
> Regards,
>
> Brian
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live
> webcast and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> ginp-users mailing list
> gin...@li...
> https://lists.sourceforge.net/lists/listinfo/ginp-users

-- 
Doug Culnane
www.culnane.net