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

Warp wrote:

> 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.

Well, there might be but I believe you _fully_ not until I have heard 
the difference myself (I don't consider myself as being a "layman" in 
this regard). But as I have not yet used such equipment I can't comment 
more.

Severi "if I can't hear it, nobody can ;-)" S.

Post a reply to this message

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

Yes, you can, even in two different ways.
1.) j2k can consist of tiles of eg 128x128 pixels (or whatever dimension you
like)
and the decompressor can be reinitialized (for different quality settings) for
each tile.
2.) The ROI-tag  (Region Of Interest) to store a part of the image even in
higher
resolution.

BUT, none of those nine test images uses any of these features and already
with them you'll find not much reliable software to decode them and with those
*extended* features (but still ISO part 1 standard) the situation becomes
really worse.
I really do not want to advertise this Kakadu thing, but it was the only one
that
did it right.


> > The JPEG2000 file header is just XML
>
>   And I thought they wanted the file to be as small as possible...
>
Well, I do not know how the ISO works...

> > 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...

Yes, sure you are right and your example is much better. It was just the case
that a few minutes before writing this I did read a posting where somebody
seriously did say this.

-Ive

Post a reply to this message

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

Thanks, and good to hear that at least in the mac-world it is not such
a big problem.

-Ive

Post a reply to this message

Warp wrote:
> 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.

Wouldn't that involve being able to hear sounds at a frequency higher than
22 kHz or with a higher dynamic range than 100 dB?

Do you have a link to a 24/96 sample file I could use to compare?  I suspect
my amplifier and speakers drop off quite soon after 20kHz though, and the
SNR is probably less than 100dB, making it rather pointless :-)

Post a reply to this message

> 
> Wouldn't that involve being able to hear sounds at a frequency higher than
> 22 kHz or with a higher dynamic range than 100 dB?

Not really.
For example, there are some amplifiers that can work from 0 Hz to 200 
KHz (hi ends ones... and far more than a month salary worth...). Some 
can say that it is stupid, because it is far beyond the ears range. But 
there are some signal modulations that are generated at aprox. (I don't 
really remember) half the max frequency of the amplifier. By setting 
that max frequency that far higher, you can be sure that it does not 
affect the frequency range you can hear.

For hearing the difference between 16/44 and 24/96, on some signals, a 
lot of people can! Even those that are not professional.
I explain:
The ear is more sensitive that most think.
If you connect a fonction generator to your amplifier, you can hear the 
difference between a sin waveform and a triangular waveform at 20 KHz.
Record it on a CD, and you can no more! There is not enough precision at 
high frequencies. On a 24/69 signal, you can.

regards,

-- 
Laurent ARTAUD (lau### [at] freefr)

Post a reply to this message

laurent.artaud[AT]free.fr" <"laurent.artaud[AT]free.fr wrote:
> > Wouldn't that involve being able to hear sounds at a frequency
> > higher than 22 kHz or with a higher dynamic range than 100 dB?
>
> Not really.
> For example, there are some amplifiers that can work from 0 Hz to 200
> KHz (hi ends ones... and far more than a month salary worth...). Some
> can say that it is stupid, because it is far beyond the ears range.
> But there are some signal modulations that are generated at aprox. (I
> don't really remember) half the max frequency of the amplifier. By
> setting that max frequency that far higher, you can be sure that it
> does not affect the frequency range you can hear.
>
> For hearing the difference between 16/44 and 24/96, on some signals, a
> lot of people can! Even those that are not professional.
> I explain:
> The ear is more sensitive that most think.
> If you connect a fonction generator to your amplifier, you can hear
> the difference between a sin waveform and a triangular waveform at 20
> KHz. Record it on a CD, and you can no more! There is not enough
> precision at high frequencies. On a 24/69 signal, you can.

I will have to try that one out when I get some sound editing software
installed (just reinstalled Windows).  What CD player did you use to play
back the audio CD?

Post a reply to this message

> I will have to try that one out when I get some sound editing software
> installed (just reinstalled Windows).  What CD player did you use to play
> back the audio CD?
> 

I did not test it myself, sorry if I may have implied it unknowingly.
Anyway, my explanation of the process was simplified for a text demo.

Note that (if I wasn't clear) a function generator is an electronic 
device (I don't have any, it's quite expensive) used in laboratories to 
test other electronic devices. It have nothing to do with any software 
in the sense that the signal stays analogous all the way and is in no 
way digitalized.

On the other end, using a software to generate the waveforms to create 
the CD is a far better way than trying to sample the function 
generator's output.

Testing the 24/96 signal would be harder:
1) you have to find a software who can generate it ;
2) you have to play it.

I don't know if any authoring software allows to make DVD-audio, but it 
would be a solution to test it (note that a DVD-audio player is not 
cheap -- I know for sure: I have one... -- and the amplifier must be 
good enough behind...).

Anyway, if you can test it, let me know.

Regards,

-- 
Laurent ARTAUD (lau### [at] freefr)

Post a reply to this message

Ive wrote:
...

 > The Gimp (and the complete linux world)  seems to be completely 
unaware of
 > color management issues. :(
...

IIRC a linux magazine recently mentioned that Gimp in the not so
distant future will support color profiles (v2 ?).

And some quick googling for "Gimp ICC" shows that there already
seems to exist plug ins / extra modules for Gimp that deals with
color management.

http://www.google.com/search?q=GIMP+ICC


Tor Olav


-- 
Tor Olav
http://subcube.com
http://subcube.net

Post a reply to this message

scott wrote:

...
> What CD player did you use to play back the audio CD?
...

Maybe he used a Super Audio CD (SACD) or a DVD-Audio player ?

-- 
Tor Olav
http://subcube.com
http://subcube.net

Post a reply to this message

On 9 Mar 2004 10:38:53 -0500, Warp <war### [at] tagpovrayorg> wrote:

>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?

I think you can do with with JPEG too.

>
>> 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...

It certainly is a tricky area this. I know I have seen banding in
images, and I know the solution is greater colour depth - but boy is
it ever hard to come up with an example. Believe me I've tried. 

Now even though I've failed to come up with an image example does not
mean it does not exist. A quick Googling will show that plenty of
other people think they way I do. Mind a lot think otherwise too.

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

Post a reply to this message

laurent.artaud[AT]free.fr wrote:
...

> Note that (if I wasn't clear) a function generator is an electronic 
> device (I don't have any, it's quite expensive) used in laboratories to 
> test other electronic devices. It have nothing to do with any software 
> in the sense that the signal stays analogous all the way and is in no 
> way digitalized.
...

Please note that many modern function generators are indeed
software "driven". I.e. a uP or a DSP generates the waveform
which is then DA-converted and filtered.


-- 
Tor Olav
http://subcube.com
http://subcube.net

Post a reply to this message

> It certainly is a tricky area this. I know I have seen banding in
> images, and I know the solution is greater colour depth - but boy is
> it ever hard to come up with an example. Believe me I've tried. 
> 
> Now even though I've failed to come up with an image example does not
> mean it does not exist. A quick Googling will show that plenty of
> other people think they way I do. Mind a lot think otherwise too.

Yes, there are a lot of (24bit) images that show banding. Especially 
gray scale images are problematic: 256 shades of gray are simply not 
enough in many cases. This is a case when traditional B&W print still 
excels - especially when using medium or large format cameras. Color 
gradations simply look better. I don't think there are many printers (or 
video cards) that accept 48bit data - does anyone know?

Severi S

Post a reply to this message

laurent.artaud[AT]free.fr" <"laurent.artaud[AT]free.fr wrote:
> > I will have to try that one out when I get some sound editing
> > software installed (just reinstalled Windows).  What CD player did
> > you use to play back the audio CD?
> >
>
> I did not test it myself, sorry if I may have implied it unknowingly.
> Anyway, my explanation of the process was simplified for a text demo.
>
> Note that (if I wasn't clear) a function generator is an electronic
> device (I don't have any, it's quite expensive) used in laboratories
> to test other electronic devices. It have nothing to do with any
> software in the sense that the signal stays analogous all the way and
> is in no way digitalized.
>
> On the other end, using a software to generate the waveforms to create
> the CD is a far better way than trying to sample the function
> generator's output.

Indeed, I was thinking about digital generation of signals, sonic Ray
Tracing :-)

> Testing the 24/96 signal would be harder:
> 1) you have to find a software who can generate it ;
> 2) you have to play it.

Yeah, I have software and hardware to play 24/96 from my PC, it's just I
doubt my speakers could keep up [just looking], apparently they are
down -3dB at 22kHz, so who knows what they'll be down to at 48kHz.

Post a reply to this message

On Tue, 09 Mar 2004 22:37:18 +0000, scott wrote:

> laurent.artaud[AT]free.fr" <"laurent.artaud[AT]free.fr wrote:
>> > I will have to try that one out when I get some sound editing
>> > software installed (just reinstalled Windows).  What CD player did
>> > you use to play back the audio CD?
>> >
>>
>> I did not test it myself, sorry if I may have implied it unknowingly.
>> Anyway, my explanation of the process was simplified for a text demo.
>>
>> Note that (if I wasn't clear) a function generator is an electronic
>> device (I don't have any, it's quite expensive) used in laboratories
>> to test other electronic devices. It have nothing to do with any
>> software in the sense that the signal stays analogous all the way and
>> is in no way digitalized.
>>
>> On the other end, using a software to generate the waveforms to create
>> the CD is a far better way than trying to sample the function
>> generator's output.
> 
> Indeed, I was thinking about digital generation of signals, sonic Ray
> Tracing :-)
> 
>> Testing the 24/96 signal would be harder:
>> 1) you have to find a software who can generate it ;
>> 2) you have to play it.
> 
> Yeah, I have software and hardware to play 24/96 from my PC, it's just I
> doubt my speakers could keep up [just looking], apparently they are
> down -3dB at 22kHz, so who knows what they'll be down to at 48kHz.

That's not the point. It's not like 44khz gives perfect signal at anything
below 22khz, and nothing above it.

A 22khz wave form at 44khz looks like this:
 * * * * * * * * * * *
------------------------------
* * * * * * * * * * * *

Regardless of the actual shape of the wave.

Post a reply to this message

Tyler Eaves wrote:
> On Tue, 09 Mar 2004 22:37:18 +0000, scott wrote:
>
> > laurent.artaud[AT]free.fr" <"laurent.artaud[AT]free.fr wrote:
> > > > I will have to try that one out when I get some sound editing
> > > > software installed (just reinstalled Windows).  What CD player
> > > > did you use to play back the audio CD?
> > > >
> > >
> > > I did not test it myself, sorry if I may have implied it
> > > unknowingly. Anyway, my explanation of the process was simplified
> > > for a text demo.
> > >
> > > Note that (if I wasn't clear) a function generator is an
> > > electronic device (I don't have any, it's quite expensive) used
> > > in laboratories to test other electronic devices. It have nothing
> > > to do with any software in the sense that the signal stays
> > > analogous all the way and is in no way digitalized.
> > >
> > > On the other end, using a software to generate the waveforms to
> > > create the CD is a far better way than trying to sample the
> > > function generator's output.
> >
> > Indeed, I was thinking about digital generation of signals, sonic
> > Ray Tracing :-)
> >
> > > Testing the 24/96 signal would be harder:
> > > 1) you have to find a software who can generate it ;
> > > 2) you have to play it.
> >
> > Yeah, I have software and hardware to play 24/96 from my PC, it's
> > just I doubt my speakers could keep up [just looking], apparently
> > they are down -3dB at 22kHz, so who knows what they'll be down to
> > at 48kHz.
>
> That's not the point.

It is the point, I was saying that my speakers couldn't reproduce
frequencies higher than 22kHz accurately.

> It's not like 44khz gives perfect signal at
> anything below 22khz, and nothing above it.

Not perfect, but perfect in terms of most peoples' ears.  You *cannot*
sample a frequency higher than 22kHz at a 44kHz sampling rate - any analogue
to digital converter will filter higher frequencies out before it samples.

> A 22khz wave form at 44khz looks like this:
>  * * * * * * * * * * *
> ------------------------------
> * * * * * * * * * * * *
>
> Regardless of the actual shape of the wave.

That's not entirely true, the 22kHz must be put through an anti-alias filter
first before it is sampled.  And guess what?  That cuts off anything above
22kHz.  Hence, the actual analogue wave you are sampling will be exactly the
same whether it was a square wave, triangle wave, sine wave or whatever to
start with.

When you convert it back to analogue, it will come out as a 22kHz sine wave,
which is identical to what was _actually_ sampled.

Post a reply to this message

> 
> Please note that many modern function generators are indeed
> software "driven". I.e. a uP or a DSP generates the waveform
> which is then DA-converted and filtered.
> 
> 

I know.
But they are more expensive and for the test I was thinking about a full 
analog one would be enough.

-- 
Laurent ARTAUD (lau### [at] freefr)

Post a reply to this message

> Yeah, I have software and hardware to play 24/96 from my PC, it's just I
> doubt my speakers could keep up [just looking], apparently they are
> down -3dB at 22kHz, so who knows what they'll be down to at 48kHz.
> 

Well, if you have the software, try this:
- create a sin waveform at 20KHz and save it in a 16/44 format
- create a sin waveform at 20KHz and save it in a 24/96 format
- at 24/96, import the two audio files and compare them, the difference 
should be obvious (if not, try it with 22KHz waveforms).
- if you want to have fun, sub the 24/96 by the 16/44 and play the 
result (at 24/96). Depending of your ears and your hardware, you may be 
able to hear the difference.

Regards,

-- 
Laurent ARTAUD (lau### [at] freefr)

Post a reply to this message

laurent.artaud[AT]free.fr" <"laurent.artaud[AT]free.fr wrote:
>> Yeah, I have software and hardware to play 24/96 from my PC, it's
>> just I doubt my speakers could keep up [just looking], apparently
>> they are down -3dB at 22kHz, so who knows what they'll be down to at
>> 48kHz.
>>
>
> Well, if you have the software, try this:
> - create a sin waveform at 20KHz and save it in a 16/44 format
> - create a sin waveform at 20KHz and save it in a 24/96 format
> - at 24/96, import the two audio files and compare them, the
> difference should be obvious (if not, try it with 22KHz waveforms).

No.  There is no difference in the waveforms.  See my posts in
povray.binaries.misc.  Or download Adobe Audition demo version to try out
for yourself.

[1] This is a 20kHz sine wave saved and then loaded in 44.1 / 16-bit format
[2] This is file [1] converted to 96 / 32-bit format, then saved and loaded
[3] This is a 20kHz sine wave generated in 96/32 format, saved and loaded
[4] This is the difference between [2] and [3], computed in 32-bit format.

Please note that in [4] the scale goes from -32000 to 32000, so we are
seeing an error of between 1 and 2 per 32000, ie -84dB.  Theoretically there
should be no error, but I had choose a quality setting when I upsampled in
stage 2, so I'm sure that effects the result.

> - if you want to have fun, sub the 24/96 by the 16/44 and play the
> result (at 24/96). Depending of your ears and your hardware, you may
> be able to hear the difference.

I can't hear the -84dB signal on my machine at work, I'll try it at home but
I'd imagine I would need to have my amplifier up *far* higher than I do
normally.

Post a reply to this message

> 
> No.  There is no difference in the waveforms.  See my posts in
> povray.binaries.misc.  Or download Adobe Audition demo version to try out
> for yourself.

Silly me! Of course there is no difference: the filters keep only the 
fundamental, which is a sin at 20KHz! It's a triangular waveform, not a 
sin waveform you have to use.
ARGH!
I'm starting to loose myself!
I can't remember how the test was supposed to be done!
Was it 20KHz or 22KHz? Was it a triangular or a square waveform?

(I can't test it myself: I use Linux and have no sound editing softwares 
installed (I'll have to find one to try, but I will not be able to do 
that before this WE...))
(I can't find p.b.m...)

> 
> Please note that in [4] the scale goes from -32000 to 32000, so we are
> seeing an error of between 1 and 2 per 32000, ie -84dB.  Theoretically there
> should be no error, but I had choose a quality setting when I upsampled in
> stage 2, so I'm sure that effects the result.

Well, In my opinion, this error is just a rounding error during the 
conversions... It is not the one I was talking about.

> 
> I can't hear the -84dB signal on my machine at work, I'll try it at home but
> I'd imagine I would need to have my amplifier up *far* higher than I do
> normally.
> 

Well, if you can hear this signal, you have a really really really 
hi-end audio system. Most of the signal/noise ratios are around 70-80dB, 
so you might hear the amplifier's noise better that the signal.

Regards,

-- 
Laurent ARTAUD (lau### [at] freefr)

Post a reply to this message

laurent.artaud[AT]free.fr" <"laurent.artaud[AT]free.fr wrote:
>> No.  There is no difference in the waveforms.  See my posts in
>> povray.binaries.misc.  Or download Adobe Audition demo version to
>> try out for yourself.
>
> Silly me! Of course there is no difference: the filters keep only the
> fundamental, which is a sin at 20KHz! It's a triangular waveform, not
> a sin waveform you have to use.
> ARGH!
> I'm starting to loose myself!
> I can't remember how the test was supposed to be done!
> Was it 20KHz or 22KHz? Was it a triangular or a square waveform?

Assuming you filter at 48kHz for a 96kHz sampling rate, a 20kHz square wave
will appear as a 20kHz sine wave because the next harmonic in a square wave
is at 3 times the fundamental.  Can't remember what it is for a triangle
wave though.  Will test out this evening listening to them to see if I can
tell any difference :-)

>> Please note that in [4] the scale goes from -32000 to 32000, so we
>> are seeing an error of between 1 and 2 per 32000, ie -84dB.
>> Theoretically there should be no error, but I had choose a quality
>> setting when I upsampled in stage 2, so I'm sure that effects the
>> result.
>
> Well, In my opinion, this error is just a rounding error during the
> conversions... It is not the one I was talking about.

Yes, I think it is rounding error too.

>> I can't hear the -84dB signal on my machine at work, I'll try it at
>> home but I'd imagine I would need to have my amplifier up *far*
>> higher than I do normally.
>>
>
> Well, if you can hear this signal, you have a really really really
> hi-end audio system. Most of the signal/noise ratios are around
> 70-80dB, so you might hear the amplifier's noise better that the
> signal.

Well my amp only cost about £150 around 5 years ago and these are the
claimed specs:

Frequency response: 10Hz - 80kHz -3dB
SNR: 98dB

Unfortunately I don't think my speakers can keep up with that! (claimed
40-22kHz -3dB)

One thing that I do notice is that if I turn my amp up to full while
connected to my 2496 soundcard I hear no hiss or noise at all.  Switch it to
my SoundBlaster Live and wham! there is so much hiss, even when all outputs
are muted in windows ;-)

Post a reply to this message

> 
> One thing that I do notice is that if I turn my amp up to full while
> connected to my 2496 soundcard I hear no hiss or noise at all.  Switch it to
> my SoundBlaster Live and wham! there is so much hiss, even when all outputs
> are muted in windows ;-)
> 

By the way, which 2496 sound card do you have?

Regards,

-- 
Laurent ARTAUD (lau### [at] freefr)

Post a reply to this message

in news:404e3ba9$1@news.povray.org Severi Salminen wrote:

> I don't think there are many printers (or 
> video cards) that accept 48bit data - does anyone know?
> 

Maybe giclee fine art color printers in the $20,000+ range, but I doubt 
it.

A way to improve digital B&W printing is to print in duo-tone or even tri-
tone. There are third party adaption kits for Epson printers to do this.

For slide printers, probably only the high-end Kodak LVT printers support 
48 bit. It uses a laser as source. Other film recorders, like the polaroid 
palette, use a CRT as source and thus have a more limited contrast and 
tonal range.

Ingo

Post a reply to this message

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

I fear not. Photoshop installs a tool called "Adobe Gamma Loader"
and I assume PaintShop does something similar.
Such tools do a reinitialization of the Gamma LUT to compensate
the difference between the "real" physical gamma of the monitor
and the Windows default gamma of 2.2 (this explains the change
in brightness you may see) . Bus this has little to do with color
management and nothing with ICM.

-Ive

Post a reply to this message

On Wed, 10 Mar 2004 21:18:28 +0100, "Ive" <ive### [at] lilysoftcom> wrote:

>
>> Everytime I boot up, my monitor dims as the colour profile kicks in.
>>
>
>I fear not. Photoshop installs a tool called "Adobe Gamma Loader"
>and I assume PaintShop does something similar.

I know. It's the Loader doing its job.

PSP has something similar when it starts - it's form of color
management - but I always found it too warm/yellow.

>Such tools do a reinitialization of the Gamma LUT to compensate
>the difference between the "real" physical gamma of the monitor
>and the Windows default gamma of 2.2 (this explains the change
>in brightness you may see) . Bus this has little to do with color
>management and nothing with ICM.

Really? You see this is what always confuses me. I still habe not
totally  fathomed out the differences in color management, profiles,
proofing etc.

>
>-Ive
>

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

Post a reply to this message

laurent.artaud[AT]free.fr" <"laurent.artaud[AT]free.fr wrote:
> > One thing that I do notice is that if I turn my amp up to full while
> > connected to my 2496 soundcard I hear no hiss or noise at all.
> > Switch it to my SoundBlaster Live and wham! there is so much hiss,
> > even when all outputs are muted in windows ;-)
> >
>
> By the way, which 2496 sound card do you have?

Midiman Delta Dio

I have just done some tests on my system...

First off, the background noise level of my soundcard/amp/speakers is
about -93dB with the Midiman and about -65dB with the SBLive.  I have to
turn my volume control up to at least double what I normal use for music to
be able to hear the -80dB.  I suspect if burnt the WAV to a CD a played it
without my PC on and no other sounds I would be able to hear it at normal
listening volumes.

Next the square wave test.  I made a file split into two halves, all at
24/96.  The first half was just a pure 10kHz note, the second half was the
same but with a 30kHz note added with an amplitude of 1/3 (ie a square wave
filtered off at 48kHz).  Could I tell the difference?  Not a dicky bird,
even though the waveform looked quite different.

I even added harmonics at 20, 30 and 40kHz and could still tell no
difference from the pure 10kHz sine wave.

After a bit more testing, I found I could hear frequencies up to about
18.5kHz, so for me, a sampling rate of 41kHz would sound the same as
anything higher (assuming 10% bandwidth for non-perfect analogue filters).

This has all got rather OT :-)

Post a reply to this message

scott <sco### [at] spamcom> wrote:
> Do you have a link to a 24/96 sample file I could use to compare?

  Do you really have a soundcard capable of playing 24/96 sounds?
Those soundcards which can are usually quite expensive pro cards.
  If you have a regular soundblaster or whatever, it will just
downsample it to 16/48 (supposing it doesn't refuse to play it
at all) and naturally you won't hear any difference (or the
24/96 may even sound worse if the soundcard makes a crappy
downsampling job).

  But to answer your question: Nope. I have no idea where you could
get those kind of samples.

-- 
#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

Ive <ive### [at] lilysoftcom> wrote:
> > > Somehow this
> > > reminds me on people who seem to think a 64bit CPU is twice as fast as a
> > > 32bit one.

> Yes, sure you are right and your example is much better. It was just the case
> that a few minutes before writing this I did read a posting where somebody
> seriously did say this.

  It's nothing new. When Intel introduced their 386 processor some people
claimed that 32-bit programs would run twice as fast as the back then
current 16-bit programs... :)

-- 
#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

Severi Salminen <sev### [at] not_thissibafi> wrote:
> I don't think there are many printers (or 
> video cards) that accept 48bit data - does anyone know?

  For grayscales it would be enough if the printer supported 16-bit B/W
images... But I suppose you won't find those in your nearest store
either. :)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp wrote:
> scott <sco### [at] spamcom> wrote:
>> Do you have a link to a 24/96 sample file I could use to compare?
>
>   Do you really have a soundcard capable of playing 24/96 sounds?

Yes.  Although my current speakers only go up to 22kHz.

> Those soundcards which can are usually quite expensive pro cards.

About £160 IIRC, this was 5 years ago though.

>   If you have a regular soundblaster or whatever, it will just
> downsample it to 16/48 (supposing it doesn't refuse to play it
> at all) and naturally you won't hear any difference (or the
> 24/96 may even sound worse if the soundcard makes a crappy
> downsampling job).

Indeed.

>   But to answer your question: Nope. I have no idea where you could
> get those kind of samples.

Post a reply to this message

> 
> Midiman Delta Dio
> 

Thank you for this info! I though Midiman was only making midi 
interfaces... But they seems to be making hi-quality sound cards (and 
your's, as well as most of their other ones, is totally compatible with 
Linux. Joy!)

 > (snip)
 >
> After a bit more testing, I found I could hear frequencies up to about
> 18.5kHz, so for me, a sampling rate of 41kHz would sound the same as
> anything higher (assuming 10% bandwidth for non-perfect analogue filters).
> 
> This has all got rather OT :-)
> 
> 

Damn! Well, there are some people that can hear it. I will have to test 
it, when I will have the according hardware to generate the tests 
waveforms. Last time I checked, I could hear up to 20KHz. Let's see if 
it has changed.

Regards,

-- 
Laurent ARTAUD (lau### [at] freefr)

Post a reply to this message

> 
> About £160 IIRC, this was 5 years ago though.
> 

I just looked on M-Audio's web site:
USD 249.95
(326 € in France)

Regards,

-- 
Laurent ARTAUD (lau### [at] freefr)

Post a reply to this message

laurent.artaud[AT]free.fr" <"laurent.artaud[AT]free.fr wrote:
>> Midiman Delta Dio
>>
>
> Thank you for this info! I though Midiman was only making midi
> interfaces... But they seems to be making hi-quality sound cards (and
> your's, as well as most of their other ones, is totally compatible
> with Linux. Joy!)

Yes, I would recommend them.  I've never had any problems with mine and they
had WindowsXP drivers available as soon as XP was released, so they seem
very up to date with software and their website.  The only disadvantage
about mine was that it doesn't have any analogue inputs, but my plan was to
find a good external ADC.

At the time it was only a bit more expensive than the SB Live cards but
absolutely knocked the socks off them!  Now the SB Live cards are so cheap I
have one of those too (for the Joystick port and surround sound).

>> After a bit more testing, I found I could hear frequencies up to
>> about
>> 18.5kHz, so for me, a sampling rate of 41kHz would sound the same as
>> anything higher (assuming 10% bandwidth for non-perfect analogue
>> filters).
>>
>> This has all got rather OT :-)
>>
>>
>
> Damn! Well, there are some people that can hear it. I will have to
> test it, when I will have the according hardware to generate the tests
> waveforms. Last time I checked, I could hear up to 20KHz. Let's see if
> it has changed.

Well, you'd be able to test yourself up to 22050 Hz with a normal soundcard
(assuming your amp and speakers could reproduce this ok).

Post a reply to this message

laurent.artaud[AT]free.fr" <"laurent.artaud[AT]free.fr wrote:
>> About £160 IIRC, this was 5 years ago though.
>>
>
> I just looked on M-Audio's web site:
> USD 249.95
> (326 € in France)

The first page of Googling "delta dio 2496" gives $189, it's surprising how
the price has stayed the same for so long, whereas SBLive and the likes have
become so cheap.  I guess it's a completely different market.

Post a reply to this message

Warp wrote:
> Severi Salminen <sev### [at] not_thissibafi> wrote:
> > I don't think there are many printers (or
> > video cards) that accept 48bit data - does anyone know?
>
>   For grayscales it would be enough if the printer supported 16-bit
> B/W images... But I suppose you won't find those in your nearest store
> either. :)

Am I being daft or does it not depend on the contrast ratio as you what bit
depth you need?  If you could produce a display or print where the white is
1000000 times brighter than the black then you would need lots of bits to
not see any banding.  However on my mobile phone in reflective mode
(contrast ratio about 10) you don't see any banding with 5-bit, and in
transmissive mode (CR about 100) with 6-bit you don't see any banding.

There must be a minimum contrast ratio that the human eye can typically
distinguish between, from my quick calculations I reckon it's about 1.07, or
a 7% increase in brightness.

Post a reply to this message

Warp wrote:
> 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.

And it's easy to see the banding in some images resulting from the use 
of 8-bit channels. However, the number of cases where this is both 
visible and problematic are mercifully small, such that 24-bit color is 
"good enough" for these newsgroups, even though it's not ideal for many 
professional applications.

If one is personally unsatisfied with that, or if the image needs 
special handling (HDRI map, maybe?), then they can provide readers here 
with URLs or low-quality versions of their work, and publish the "real" 
copy on their own server space.

If IMBJR had done this, instead of trying to ram his preferred (and 
functionally redundant) format down everyone's throats, I suspect that 
no one would have complained.

-Xplo

Post a reply to this message