[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GWorkspace - thumbnail service problems
From: |
Riccardo Mottola |
Subject: |
Re: GWorkspace - thumbnail service problems |
Date: |
Thu, 22 Oct 2015 18:33:26 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:41.0) Gecko/20100101 Firefox/41.0 SeaMonkey/2.38 |
Hi,
I just finished fixing the code that mishandled certain images creating
broken images. I imported a clean resizer from PRICE.
The same bug could be seen in the content inspector (larger preview)
Interesting, the problem affected only certain JPEG images directly
imported from digital cameras or from iPhone. Image that were already
"touched" by gnustep like PRICE or LaternaMagica. Very curious.
Anyway, if you didn't notice, just test that I didn't broke anything.
Charles Philip Chan wrote:
2. Allow much bigger sizes. 48x48 max size previews doesn't
really cut it, especially for photos.
I analyzed. there are two distinct things:
1) the grid visualization, which I thought was fixed for 48px inside a
64px frame which is "standard NeXT". I am in fact wrong, with a little
bit of tweaking, I got 64 and 96 px squares
2) actual thumbnail generation by the service. It does not generate them
given the size of the view, but always of a fixed size, currently 48px
The icon view shows them smaller (I haven't found any re-scaling code,
perhaps it is using gui scaling, I'd like to add something smoother
there) or at most up to that size.
I could of course have thumbnailer generate 64px previes, but this
starts consuming more space. What if 96px even?
I see two paths
1) find a way to communicate the thumbnailer the size needed. If you
change the visualization size, then you need to remove and regenerate
the icons
2) keep them big, but compress them in JPEG. I think that nowadays
saving/opening a small jpeg has such a big overhead compared to TIFF.
Opening is probably quite comparable, saving has more rescaling overhead
anyway. Just out of my guts, didn't do any tests.
One could also combine 1) and 2).
Riccardo