after having read the funny and entertaining thread about JPEG2000 from the
weekend here are some observations of mine on this "future" image file format.
I will try to give some facts and avoid too much rants and rambling, but let's
see.
Some weeks ago I did implement a JPEG2000/J2K decoder/encoder and did
a lot of research on this topic, so I hope to be qualified to do some rant about
all this...

First about the claim of the superior image quality of J2K compared to the
conventional jpeg DCT encoding. Well, I would say it depends. For highly
compressed images (with a ratio of lets say 1:80) it is definitely true. While
JPG consists only of the well known ugly block artefacts, J2K gives a smooth
but blurry image that is much more pleasant to the eye. But for less compressed
images, when image quality is the main issue, the file size will be quite the
same and it simply depends on the kind of image and it is also a matter of
personal taste.
Imagine a picture with a smooth sky gradient and some small wires in the
foreground. JPG will introduce some artefacts (and color banding) in the sky but
J2K will tend to blur out the wires and make them vanish - so anyway, a loss of
information is a loss of information.
In my opinion, the impression of getting a better image quality with JPEG2000 is
mostly the result of the advertising of some commercial companies to point out
the neccessarity of purchasing their product (library, plugin or whatever).

But there is also the possibility of using lossless compression with JPEG2000
and this gives in most cases a much better compression ratio than e.g. PNG's
zlib compression and it beats LZW (as used by e.g. TIFF) all the time. So here
goes a clear point to JPEG2000. And I think it is also quite nice to use one
file format that allows both, lossless and adjustable lossy compression,
depending on your needs.

Another issue is: JPEG2000 can be streamed. This means (well, this would
mean, in case your browser would support the format) you can view the complete
image immediately at low quality and the quality does successive increase while
downloading the image. Nice feature, sure. Especially for slow connections
and/or huge images. But remember this is also possible with progressive
encoded jpeg files but IE downloads first the complete image until it displays
something, with non progressive jpeg's it shows them at least line by line.
Firebird works meanwhile nicely with progressive jpeg files. How long does jpeg
exist? Not sure, but I guess so about 15 years.

Next point: JPEG2000 supports full colorimetric information stored within the
file. The files posted by IMBJR are an example for this, they include an ICC
profile. Fine, but PNG, JPG and TIFF do support ICC profiles also. The problem
is, very few applications and none of the browsers does make use of this. In
fact, the only application I am aware of is Photoshop.
The Gimp (and the complete linux world)  seems to be completely unaware of
color management issues. :(
But the funniest thing is: Windows includes (since  Windows 95 !!!) a color
management module that would be able to handle ICC profiles. It's called ICM and
was not developed by Microsoft but licenced from Heidelberger Druckmaschinen.
But there is not even a Microsoft application (including IE) that makes any use
of it. I guess the licencing devision did forget to inform the developers about
it, or maybe they used Outlook and the mail got lost ...  enough. And I know
nothing about the Mac.


A defined file format and an ISO standard is fine but of less practical benefit
until it is not really supported by application software, so lets have a look at
the availability and quality of J2K en/decoders, libraries, plugins and the
applications using them.

At first, if you do not want to trust blindly to my words or in case you want to
test the quality of the j2k implementation of your favorite viewer/browser by
yourself here are the official JPEG2000 test files:
http://www.crc.ricoh.com/~gormish/jpeg2000conformance/j2kp4files_v1_4.zip
but be warned, 50MB !
It is so big because it contains also uncompressed TIF files as a reference.
Note: These are only the files that are currently available to the public, there
are more but due to some copyright issues you need to be a registered
developer to access them.

(BTW, Thorsten or anybody else who uses a Mac, I would be very interested to
hear something about the QuickTime J2K implementation: how many test
images are correctly displayed and wich of them?)

There is currently only one non-commercial library available called JasPer but
it implements only part 1 of the ISO standard (and in fact only a subset of it).
You can find JasPer (and a list of software that uses this library) here:
http://www.ece.uvic.ca/~mdadams/jasper/
JasPer fails on 4 out of 9 test images.

There is one more a non-commercial j2k-library, http://j2000.org/  but it
implements only the j2k code stream and not the JPEG2000 file format, also
it seems to be in a state of hibernation, so I'm just ignoring it.

Then we have a wide range of commercial libraries. I do not know all of them,
but the company I'm working for did buy 2 of them to check them out and I did
some more tests by playin' with applications where the used library was known.
Well, for short, the result was not very promising, most of them failed also on
3 to 5 images and as these are not alwayws the same they are also quite
incompatible to each other.

In fact, the only one I would recommand is Kakadu at
http://www.kakadusoftware.com/
Kakadu works really fine and fails on 0 out of 9 images. To give you an idea: to
purchase a "freeware-licence", the POV-team would have to pay 550$. The
commercial ones go up to 12000$ which would mean nothing for a company like MS.
And just an observation: Prof. David Taubman, the developer of Kakadu is also
a member of the ISO for JPEG2000 and somehow it seems to me he developed the
library first. And I have also a strange feeling when I think about the fact
that he gets payed by public money but has no problem in selling the product he
has developed at his work (I guess with help of his students). OK, call me old
fashioned.

And just because it seems to be so widely used around here: IrfanView uses the
Luratech plugin (to be more exact the former Luratech now AlgoVision because
Luratech didn't survive) and it also fails on 4 out of 9 images. And (just a
little rambling, I cannot resist) I always was wondering why IrfanView did
become so popular (among the Windozers around here). For sure, it somehow
"displays" all of the images, but some of them with simply plain wrong colors,
and it does this without any warning or notice to the user that there might be a
problem. This does happen also with some TIFF images (especially if they are
not encoded in rgb color space) and even jpeg (cmyk's) and png files (ignoring
the gamma chunck). I never liked this behaviour and I guess some of you have
viewed images with IrvanView without ever realizing that what you see is not
even near the way it should be. Well, enough of that.

Finally my own implementation fails on 0 out of 9 test images but it fails on 4
out of 30 more unusual code streams - so after all it is not so bad :)

Another side note for Torsten: from a programmers point of view, implementing
the DWT is not more sophisticated than a DCT, I have done this also a few years
ago. In fact, en/decoding a J2K code stream is quite streightforeward. The
JPEG2000 file header is just XML so any XML parser will do (and luckily I had
not to write one).


And about the 16bit/8bit per channel color banding controversy. Somehow this
reminds me on people who seem to think a 64bit CPU is twice as fast as a
32bit one. It's not that simple and even color scientists do not share the same
opinion about this (the 16/8bit color I mean, not the CPU ;)  If you are really
interested look e.g. here:
http://www.brucelindbloom.com/DanMargulis.html


All this are just my 2 euro cent and it is quite possibly that some of the
information is already outdated. The time of my research is about 4 months
back and since then I was not much interested in the topic.

Final note: I do not care much about the file format one is posting. I can see
JPEG2000 without problems and I have a fast connection, so everything is fine
for me. But I really doubt the benefit of posting a JP2 file - especially a
16bit/channel one.


so long
-Ive

Post a reply to this message

Ive wrote:
> after having read the funny and entertaining thread about JPEG2000 from the
> weekend here are some observations of mine on this "future" image file format.
> I will try to give some facts and avoid too much rants and rambling, but let's
> see.
> Some weeks ago I did implement a JPEG2000/J2K decoder/encoder and did
> a lot of research on this topic, so I hope to be qualified to do some rant about
> all this...
> 
> First about the claim of the superior image quality of J2K compared to the
> conventional jpeg DCT encoding. Well, I would say it depends. For highly
> compressed images (with a ratio of lets say 1:80) it is definitely true. While
> JPG consists only of the well known ugly block artefacts, J2K gives a smooth
> but blurry image that is much more pleasant to the eye. But for less compressed
> images, when image quality is the main issue, the file size will be quite the
> same and it simply depends on the kind of image and it is also a matter of
> personal taste.
> Imagine a picture with a smooth sky gradient and some small wires in the
> foreground. JPG will introduce some artefacts (and color banding) in the sky but
> J2K will tend to blur out the wires and make them vanish - so anyway, a loss of
> information is a loss of information.
> In my opinion, the impression of getting a better image quality with JPEG2000 is
> mostly the result of the advertising of some commercial companies to point out
> the neccessarity of purchasing their product (library, plugin or whatever).
> 
> But there is also the possibility of using lossless compression with JPEG2000
> and this gives in most cases a much better compression ratio than e.g. PNG's
> zlib compression and it beats LZW (as used by e.g. TIFF) all the time. So here
> goes a clear point to JPEG2000. And I think it is also quite nice to use one
> file format that allows both, lossless and adjustable lossy compression,
> depending on your needs.
> 
> Another issue is: JPEG2000 can be streamed. This means (well, this would
> mean, in case your browser would support the format) you can view the complete
> image immediately at low quality and the quality does successive increase while
> downloading the image. Nice feature, sure. Especially for slow connections
> and/or huge images. But remember this is also possible with progressive
> encoded jpeg files but IE downloads first the complete image until it displays
> something, with non progressive jpeg's it shows them at least line by line.
> Firebird works meanwhile nicely with progressive jpeg files. How long does jpeg
> exist? Not sure, but I guess so about 15 years.
> 
> Next point: JPEG2000 supports full colorimetric information stored within the
> file. The files posted by IMBJR are an example for this, they include an ICC
> profile. Fine, but PNG, JPG and TIFF do support ICC profiles also. The problem
> is, very few applications and none of the browsers does make use of this. In
> fact, the only application I am aware of is Photoshop.
> The Gimp (and the complete linux world)  seems to be completely unaware of
> color management issues. :(
> But the funniest thing is: Windows includes (since  Windows 95 !!!) a color
> management module that would be able to handle ICC profiles. It's called ICM and
> was not developed by Microsoft but licenced from Heidelberger Druckmaschinen.
> But there is not even a Microsoft application (including IE) that makes any use
> of it. I guess the licencing devision did forget to inform the developers about
> it, or maybe they used Outlook and the mail got lost ...  enough. And I know
> nothing about the Mac.
> 
> 
> A defined file format and an ISO standard is fine but of less practical benefit
> until it is not really supported by application software, so lets have a look at
> the availability and quality of J2K en/decoders, libraries, plugins and the
> applications using them.
> 
> At first, if you do not want to trust blindly to my words or in case you want to
> test the quality of the j2k implementation of your favorite viewer/browser by
> yourself here are the official JPEG2000 test files:
> http://www.crc.ricoh.com/~gormish/jpeg2000conformance/j2kp4files_v1_4.zip
> but be warned, 50MB !
> It is so big because it contains also uncompressed TIF files as a reference.
> Note: These are only the files that are currently available to the public, there
> are more but due to some copyright issues you need to be a registered
> developer to access them.
> 
> (BTW, Thorsten or anybody else who uses a Mac, I would be very interested to
> hear something about the QuickTime J2K implementation: how many test
> images are correctly displayed and wich of them?)
> 
> There is currently only one non-commercial library available called JasPer but
> it implements only part 1 of the ISO standard (and in fact only a subset of it).
> You can find JasPer (and a list of software that uses this library) here:
> http://www.ece.uvic.ca/~mdadams/jasper/
> JasPer fails on 4 out of 9 test images.
> 
> There is one more a non-commercial j2k-library, http://j2000.org/  but it
> implements only the j2k code stream and not the JPEG2000 file format, also
> it seems to be in a state of hibernation, so I'm just ignoring it.
> 
> Then we have a wide range of commercial libraries. I do not know all of them,
> but the company I'm working for did buy 2 of them to check them out and I did
> some more tests by playin' with applications where the used library was known.
> Well, for short, the result was not very promising, most of them failed also on
> 3 to 5 images and as these are not alwayws the same they are also quite
> incompatible to each other.
> 
> In fact, the only one I would recommand is Kakadu at
> http://www.kakadusoftware.com/
> Kakadu works really fine and fails on 0 out of 9 images. To give you an idea: to
> purchase a "freeware-licence", the POV-team would have to pay 550$. The
> commercial ones go up to 12000$ which would mean nothing for a company like MS.
> And just an observation: Prof. David Taubman, the developer of Kakadu is also
> a member of the ISO for JPEG2000 and somehow it seems to me he developed the
> library first. And I have also a strange feeling when I think about the fact
> that he gets payed by public money but has no problem in selling the product he
> has developed at his work (I guess with help of his students). OK, call me old
> fashioned.
> 
> And just because it seems to be so widely used around here: IrfanView uses the
> Luratech plugin (to be more exact the former Luratech now AlgoVision because
> Luratech didn't survive) and it also fails on 4 out of 9 images. And (just a
> little rambling, I cannot resist) I always was wondering why IrfanView did
> become so popular (among the Windozers around here). For sure, it somehow
> "displays" all of the images, but some of them with simply plain wrong colors,
> and it does this without any warning or notice to the user that there might be a
> problem. This does happen also with some TIFF images (especially if they are
> not encoded in rgb color space) and even jpeg (cmyk's) and png files (ignoring
> the gamma chunck). I never liked this behaviour and I guess some of you have
> viewed images with IrvanView without ever realizing that what you see is not
> even near the way it should be. Well, enough of that.
> 
> Finally my own implementation fails on 0 out of 9 test images but it fails on 4
> out of 30 more unusual code streams - so after all it is not so bad :)
> 
> Another side note for Torsten: from a programmers point of view, implementing
> the DWT is not more sophisticated than a DCT, I have done this also a few years
> ago. In fact, en/decoding a J2K code stream is quite streightforeward. The
> JPEG2000 file header is just XML so any XML parser will do (and luckily I had
> not to write one).
> 
> 
> And about the 16bit/8bit per channel color banding controversy. Somehow this
> reminds me on people who seem to think a 64bit CPU is twice as fast as a
> 32bit one. It's not that simple and even color scientists do not share the same
> opinion about this (the 16/8bit color I mean, not the CPU ;)  If you are really
> interested look e.g. here:
> http://www.brucelindbloom.com/DanMargulis.html
> 
> 
> All this are just my 2 euro cent and it is quite possibly that some of the
> information is already outdated. The time of my research is about 4 months
> back and since then I was not much interested in the topic.
> 
> Final note: I do not care much about the file format one is posting. I can see
> JPEG2000 without problems and I have a fast connection, so everything is fine
> for me. But I really doubt the benefit of posting a JP2 file - especially a
> 16bit/channel one.
> 
> 
> so long
> -Ive
> 

talking to someone who actually i assume got work to purchase a
hardback book entitled 'jpeg2000' and their experiences, i had the 
distinct impression that the focal blur operation of povray could be 
removed, provided of course we implemented the facility of jpeg2000.
personally speaking, i can't see the point

stephen

anyone know about mozilla, newsgroups and a "don't display posts from"
option
much previous is humerous or meant to be, immediately above is serious

Post a reply to this message

In article <404cb301@news.povray.org> , "Ive" <ive### [at] lilysoftcom> wrote:

> (BTW, Thorsten or anybody else who uses a Mac, I would be very interested to
> hear something about the QuickTime J2K implementation: how many test
> images are correctly displayed and wich of them?)

QuickTime decodes all images except image 6 (just blank) correctly.
GraphicConverter does decodes them all without problems.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <404cb4ee@news.povray.org>,
 stephen parkinson <ste### [at] zmemw16demoncouk> wrote:

> talking to someone who actually i assume got work to purchase a
> hardback book entitled 'jpeg2000' and their experiences, i had the 
> distinct impression that the focal blur operation of povray could be 
> removed, provided of course we implemented the facility of jpeg2000.
> personally speaking, i can't see the point

No...focal blur can't be replaced with a file format. The two are so 
different that I have no idea how you could think this was so...focal 
blur is an optical simulation. JPEG2000 is a file format for storing 
images.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote in news:cjameshuff-
26355D.16181608032004@news.povray.org:


> 
> No...focal blur can't be replaced with a file format. The two are so 
> different that I have no idea how you could think this was so...
> 

I might be mistaken, but this could be an example of dry british humour.


-- 
Tom
_________________________________
The Internet Movie Project
http://www.imp.org/

Post a reply to this message

On Mon, 8 Mar 2004 18:53:14 +0100, "Ive" <ive### [at] lilysoftcom> wrote:

>after having read the funny and entertaining thread about JPEG2000 from the
>weekend here are some observations of mine on this "future" image file format.
>I will try to give some facts and avoid too much rants and rambling, but let's
>see.
>Some weeks ago I did implement a JPEG2000/J2K decoder/encoder and did
>a lot of research on this topic, so I hope to be qualified to do some rant about
>all this...
>
>First about the claim of the superior image quality of J2K compared to the
>conventional jpeg DCT encoding. Well, I would say it depends. For highly

It always does.

>compressed images (with a ratio of lets say 1:80) it is definitely true. While
>JPG consists only of the well known ugly block artefacts, J2K gives a smooth
>but blurry image that is much more pleasant to the eye. But for less compressed
>images, when image quality is the main issue, the file size will be quite the
>same and it simply depends on the kind of image and it is also a matter of
>personal taste.
>Imagine a picture with a smooth sky gradient and some small wires in the
>foreground. JPG will introduce some artefacts (and color banding) in the sky but
>J2K will tend to blur out the wires and make them vanish - so anyway, a loss of
>information is a loss of information.
>In my opinion, the impression of getting a better image quality with JPEG2000 is
>mostly the result of the advertising of some commercial companies to point out
>the neccessarity of purchasing their product (library, plugin or whatever).

Mmm, must say I don't get that impression. I was under the idea that
it was the Standards group themselves who hark on this.

>
>But there is also the possibility of using lossless compression with JPEG2000
>and this gives in most cases a much better compression ratio than e.g. PNG's
>zlib compression and it beats LZW (as used by e.g. TIFF) all the time. So here
>goes a clear point to JPEG2000. And I think it is also quite nice to use one
>file format that allows both, lossless and adjustable lossy compression,
>depending on your needs.

Must say, I've not played with this yet.

>
>Another issue is: JPEG2000 can be streamed. This means (well, this would
>mean, in case your browser would support the format) you can view the complete
>image immediately at low quality and the quality does successive increase while
>downloading the image. Nice feature, sure. Especially for slow connections
>and/or huge images. But remember this is also possible with progressive
>encoded jpeg files but IE downloads first the complete image until it displays
>something, with non progressive jpeg's it shows them at least line by line.

Netscape does the same. I remember when they didn't. I think the
implementer got lazy!

>Firebird works meanwhile nicely with progressive jpeg files. How long does jpeg
>exist? Not sure, but I guess so about 15 years.
>
>Next point: JPEG2000 supports full colorimetric information stored within the
>file. The files posted by IMBJR are an example for this, they include an ICC
>profile. Fine, but PNG, JPG and TIFF do support ICC profiles also. 

As all good modern formats should. Yeah!

>The problem
>is, very few applications and none of the browsers does make use of this. In
>fact, the only application I am aware of is Photoshop.

Paint Shop Pro does too. Anyone know of others. Plus, this information
is useful for the purposes of print - I believe (that's an area that
I'm very unfamilar with).

>The Gimp (and the complete linux world)  seems to be completely unaware of
>color management issues. :(
>But the funniest thing is: Windows includes (since  Windows 95 !!!) a color
>management module that would be able to handle ICC profiles. It's called ICM and
>was not developed by Microsoft but licenced from Heidelberger Druckmaschinen.
>But there is not even a Microsoft application (including IE) that makes any use
>of it. I guess the licencing devision did forget to inform the developers about
>it, or maybe they used Outlook and the mail got lost ...  enough. And I know
>nothing about the Mac.

Everytime I boot up, my monitor dims as the colour profile kicks in.

>
>
>A defined file format and an ISO standard is fine but of less practical benefit
>until it is not really supported by application software, so lets have a look at
>the availability and quality of J2K en/decoders, libraries, plugins and the
>applications using them.
>
>At first, if you do not want to trust blindly to my words or in case you want to
>test the quality of the j2k implementation of your favorite viewer/browser by
>yourself here are the official JPEG2000 test files:
>http://www.crc.ricoh.com/~gormish/jpeg2000conformance/j2kp4files_v1_4.zip
>but be warned, 50MB !
>It is so big because it contains also uncompressed TIF files as a reference.
>Note: These are only the files that are currently available to the public, there
>are more but due to some copyright issues you need to be a registered
>developer to access them.
>
>(BTW, Thorsten or anybody else who uses a Mac, I would be very interested to
>hear something about the QuickTime J2K implementation: how many test
>images are correctly displayed and wich of them?)
>
>There is currently only one non-commercial library available called JasPer but
>it implements only part 1 of the ISO standard (and in fact only a subset of it).
>You can find JasPer (and a list of software that uses this library) here:
>http://www.ece.uvic.ca/~mdadams/jasper/
>JasPer fails on 4 out of 9 test images.
>
>There is one more a non-commercial j2k-library, http://j2000.org/  but it
>implements only the j2k code stream and not the JPEG2000 file format, also
>it seems to be in a state of hibernation, so I'm just ignoring it.
>
>Then we have a wide range of commercial libraries. I do not know all of them,
>but the company I'm working for did buy 2 of them to check them out and I did
>some more tests by playin' with applications where the used library was known.
>Well, for short, the result was not very promising, most of them failed also on
>3 to 5 images and as these are not alwayws the same they are also quite
>incompatible to each other.
>
>In fact, the only one I would recommand is Kakadu at
>http://www.kakadusoftware.com/
>Kakadu works really fine and fails on 0 out of 9 images. To give you an idea: to
>purchase a "freeware-licence", the POV-team would have to pay 550$. The
>commercial ones go up to 12000$ which would mean nothing for a company like MS.
>And just an observation: Prof. David Taubman, the developer of Kakadu is also
>a member of the ISO for JPEG2000 and somehow it seems to me he developed the
>library first. And I have also a strange feeling when I think about the fact
>that he gets payed by public money but has no problem in selling the product he
>has developed at his work (I guess with help of his students). OK, call me old
>fashioned.
>
>And just because it seems to be so widely used around here: IrfanView uses the
>Luratech plugin (to be more exact the former Luratech now AlgoVision because
>Luratech didn't survive) and it also fails on 4 out of 9 images. And (just a
>little rambling, I cannot resist) I always was wondering why IrfanView did
>become so popular (among the Windozers around here). For sure, it somehow
>"displays" all of the images, but some of them with simply plain wrong colors,
>and it does this without any warning or notice to the user that there might be a
>problem. This does happen also with some TIFF images (especially if they are
>not encoded in rgb color space) and even jpeg (cmyk's) and png files (ignoring
>the gamma chunck). I never liked this behaviour and I guess some of you have
>viewed images with IrvanView without ever realizing that what you see is not
>even near the way it should be. Well, enough of that.

Thanks for the heads on on that. I was not aware it was a problem.

>
>Finally my own implementation fails on 0 out of 9 test images but it fails on 4
>out of 30 more unusual code streams - so after all it is not so bad :)
>
>Another side note for Torsten: from a programmers point of view, implementing
>the DWT is not more sophisticated than a DCT, I have done this also a few years
>ago. In fact, en/decoding a J2K code stream is quite streightforeward. The
>JPEG2000 file header is just XML so any XML parser will do (and luckily I had
>not to write one).
>
>
>And about the 16bit/8bit per channel color banding controversy. Somehow this
>reminds me on people who seem to think a 64bit CPU is twice as fast as a
>32bit one. It's not that simple and even color scientists do not share the same
>opinion about this (the 16/8bit color I mean, not the CPU ;)  If you are really
>interested look e.g. here:
>http://www.brucelindbloom.com/DanMargulis.html

I know. There's no firm answer on this - I just go with what I have
personally experienced.

>
>
>All this are just my 2 euro cent and it is quite possibly that some of the
>information is already outdated. The time of my research is about 4 months
>back and since then I was not much interested in the topic.
>
>Final note: I do not care much about the file format one is posting. I can see
>JPEG2000 without problems and I have a fast connection, so everything is fine
>for me. But I really doubt the benefit of posting a JP2 file - especially a
>16bit/channel one.

Again - intent was the intention. But point taken - I dont think I
shall be so tempted by 16-bit anymore.

--------------------------------
My First Subgenius Picture Book:
http://www.imbjr.com

Post a reply to this message

On Mon, 08 Mar 2004 10:18:26 -0800, Darren New <dne### [at] sanrrcom>
wrote:

>FWIW, I tested the images with PaintShopPro8.1, and assuming Windows was 
>showing me the TIFFs correctly, it looks like
>1 - OK
>2 - Hosed in ways hard to explain
>3 - B&W
>4 - OK
>5 - B&W
>6 - OK
>7 - Also hosed, but in different ways
>8, 9 - OK
>
>I think any file format complex enough to have such a wide variety of 
>failure modes probably ought to be several file formats. I don't 
>understand the point of putting both lossy and lossless compression in 
>the "same" file format.

I'm quite disappointed with PSP on this score.

>
>> anyone know about mozilla, newsgroups and a "don't display posts from"
>> option
>> much previous is humerous or meant to be, immediately above is serious
>
>Message->Create filter from

--------------------------------
My First Subgenius Picture Book:
http://www.imbjr.com

Post a reply to this message

Ive <ive### [at] lilysoftcom> wrote:
> Imagine a picture with a smooth sky gradient and some small wires in the
> foreground. JPG will introduce some artefacts (and color banding) in the sky but
> J2K will tend to blur out the wires and make them vanish - so anyway, a loss of
> information is a loss of information.

  Can't you use different compression levels on different parts of the image
in JPEG2000?

> The JPEG2000 file header is just XML

  And I thought they wanted the file to be as small as possible...

> And about the 16bit/8bit per channel color banding controversy. Somehow this
> reminds me on people who seem to think a 64bit CPU is twice as fast as a
> 32bit one.

  I wouldn't compare it to that.
  I would compare it to 16-bit vs. 24-bit sound sampling. A layman does
not hear any difference at all between 16-bit (eg. CD) and 24-bit sound,
but professionals would not work with anything less than 24. The same
goes for 44kHz vs. 96kHz sample rate...

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

>   I would compare it to 16-bit vs. 24-bit sound sampling. A layman does
> not hear any difference at all between 16-bit (eg. CD) and 24-bit sound,
> but professionals would not work with anything less than 24. The same
> goes for 44kHz vs. 96kHz sample rate...

That is exactly to the point: "would not _work_ with anything else 
than...". The extra resolution with 24bit/96kHz comes very handy when 
you have to normalize, compress, equalize etc. Same way as in image 
editing. But I doubt if there are many professionals who can hear the 
difference between 16/44 and 24/96 _all other things being equal_.

And everyone who has ever gotten familiar with Hi-Fi world know how full 
of "magic bullets" it is: weights on CDs to make it sound better, all 
the fancy techniques to reduce jitter in CD players. The differences in 
sound quality are huge when the listener knows which equipment/brand he 
is using but in a blind test the differences almost allways magically 
disappear. Well, I went to off-topic, but still, the differences allways 
seem to be mach larger on the paper than in practice.

Severi

Post a reply to this message

Severi Salminen <sev### [at] not_thissibafi> wrote:
> But I doubt if there are many professionals who can hear the 
> difference between 16/44 and 24/96 _all other things being equal_.

  Believe me: There are.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message