ðòïåëôù 


  áòèé÷ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  óôáôøé 


  ðåòóïîáìøîïå 


  ðòïçòáííù 



ðéûéôå
ðéóøíá












     áòèé÷ :: Filmscanners
Filmscanners mailing list archive (filmscanners@halftone.co.uk)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[filmscanners] Re: JPEG2000/PNG on PS7.0 and PSP8.0



Robert - your figures for the compression ratios fo JPEG2000 seem very low
to me, I am interested to know why.  I get more towards 2:1 mostly, with
the worst figure ever around 15% and an average around 40%.  You get an
average around 12%.  Perhaps my images are lacking detail, or are yours
especially grainy? Not criticising, just would like to have a handle on all
this.

 From my own part-finished investigation, I think I agree with Paul that
compression to about 20% seems to give results that are pretty good even
for archival purposes.  Although I can see a difference if I look very hard
at the blown up image, it is really only obvious even blown up to 2-300% or
so and not visible to me at normal viewing.

The one thing I did notice was that the fnord plug in with Photoshop gives
surprisingly different results from the Lurawave add-on to Irfanview at the
same compression ratios.    What I noticed was that doing a 10% size save
showed the fnord result through photoshop to be very noticeably worse than
the lurawave result through irfanview.  Fnord exaggerated motley skies and
made slight differences to detail like hair.    The two files are the same
size within a few bytes. (To objectify the difference between original and
compressed, I layer the two images, take the difference (almost a black
image) then expand that difference image by tweaking the upper limit in
"levels" from 255 to 4 or 8.  This gives you an exaggerated version of the
difference image.)

I don't even know which bit of software makes the difference although I
suppose it is the plugin (fnord or Lura), not the mother program (PS or
irfanview).

The other thought is that if you get only 12% or so compression, and I get
50%, then obviously different files cope better with compression.  So,
maybe it is not such a good idea for us to compress to a set file size like
"10%", but we should really be compressing to a standard quality?  If this
is true then it becomes more problematical because lurawave's 95% quality
setting is nothing like the same compression or quality as fnord's 95%
quality setting - they use completely different parameters for quality.

Still investigating, but it seems to me that archiving at 5:1 is looking
pretty good as a real life compromise.

Julian

> > From: Robert Logan
> >
> > Ok, my 1st proper analysis of compression with
> > JPEG2000 on a full roll of film. Saving with
> > the 'fnord' JP2 plugin in PHotoshop, of 20
> > 30Mb-50Mb files, 48 bit scans, and using the
> > 'fnord'  Super PNG plugin on the same files
> > (and then PNGcrushing them) gives the following
> > results.
> >
> > Orig TIFF = 850 Mb
> > JPEG 2000 = 747 Mb
> > PNG/crush = 758 Mb
> >
> > The JPEG 2000 is better, over a good analysis,
> > and saves the colour profile data too. I will now
> > move to archiving totally in JP2 ... after a long
> > wait from y2K.
>
>You're going to convert all your TIFFs to JPEG2000 just to save 11% of your
>space, and suffer the longer decode times when you view them? Wouldn't it be
>easier just to buy a little more disk space?
>
>I intend to convert all my TIFFs to JPEG2000 (as soon as my image cataloger
>software, ThumbsPlus, handles the format--RSN), but I'll use 5:1 or 10:1
>lossy compression. That provides some meaningful space advantage.


Julian
Canberra, Australia

Satellite maps of fire situation Canberra and Snowy Montains
http://members.austarmetro.com.au/~julian/cbfires/fires.htm

----------------------------------------------------------------------------------------
Unsubscribe by mail to listserver@halftone.co.uk, with 'unsubscribe 
filmscanners'
or 'unsubscribe filmscanners_digest' (as appropriate) in the message title or 
body



 




Copyright © Lexa Software, 1996-2009.