AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
May 2005

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2005.05.18 15:38 "Another libtiff+libjpeg problem", by Thom Decarlo
2005.05.18 16:12 "Re: Another libtiff+libjpeg problem", by Bob Friesenhahn
2005.05.18 16:54 "Re: Another libtiff+libjpeg problem", by Thom Decarlo
2005.05.18 18:24 "Re: Another libtiff+libjpeg problem", by Thom Decarlo
2005.05.18 18:33 "Re: Another libtiff+libjpeg problem", by Bob Friesenhahn
2005.05.18 19:39 "Re: Another libtiff+libjpeg problem", by Thom Decarlo
2005.05.19 14:59 "Re: Another libtiff+libjpeg problem", by Frank Warmerdam
2005.05.19 23:00 "Re: Another libtiff+libjpeg problem", by Thom Decarlo
2005.05.20 00:00 "Re: Another libtiff+libjpeg problem", by Frank Warmerdam
2005.05.28 21:07 "Re: Another libtiff+libjpeg problem", by Thom Decarlo
2005.06.10 18:01 "Re: Another libtiff+libjpeg problem", by Frank Warmerdam
2005.06.10 18:49 "Re: Another libtiff+libjpeg problem", by Bob Friesenhahn
2005.05.25 10:12 "Re: Another libtiff+libjpeg problem", by Jean-yves Le Ridant
2005.05.25 13:31 "Re: Another libtiff+libjpeg problem", by Jean-yves Le Ridant
2005.05.26 17:57 "Re: Another libtiff+libjpeg problem", by Andrey Kiselev
2005.06.13 12:40 "Re: Another libtiff+libjpeg problem", by Jean-yves Le Ridant
2005.06.13 14:06 "Re: Another libtiff+libjpeg problem", by Andrey Kiselev
2005.06.14 10:24 "Re: Another libtiff+libjpeg problem", by Jean-yves Le Ridant
2005.06.17 08:22 "Re: Another libtiff+libjpeg problem", by Jean-yves Le Ridant
2005.06.17 16:29 "Re: Another libtiff+libjpeg problem", by Andrey Kiselev

2005.05.25 13:31 "Re: Another libtiff+libjpeg problem", by Jean-yves Le Ridant

KW> if your after a slightly better approximation but not too slow when
KW> doing bit depth promotion you should fill the bottom bits with the
KW> upper bits...

KW> e.g. 12 bits to 16 ...

KW> 12 bits names
BA9876543210 ->> BA9876543210BA98

KW> The above being a bit shift

KW> out := (in << 4) | (in >> 8)

KW> 8 bits
76543210 ->> 7654321076543210

KW> it works and ensures that peak input is mapped to peak output.

:-))
Yes but ...., unsigned shift is perfect for a and b of ICCLAB,
and signed shift would be right for those of CIELAB
( and guys have strange ideas as jpeg compressing of CIELAB ...)
:-)

No hope, really handling 16 bits is a job, and would be better
handled by jpeglib interface, mixed with/in existing tables.
So at this point it's obstensibely a quickwatch.

--
Jean-Yves