Sourceforge has been blocking my email for ages, from the biggest ISP of the country no less. This of course is on a whole different level (small country:-), but doesn't surprise me.
Perhaps it is a bit hypocritical, however the alternative (an eye patch and peg-leg) is less appealing than paying for a game I have to work on a little to play.:)
Alternatives are plenty (read a book:-), but they aren't identical substitutes.
I'd like to see some numbers on that, because in D/A conversion you will likely lose any perceptible difference between 12bpc and 16bpc in the noise.
I was thinking multi-exposure. Back in the day when PNG was developed digital cameras storing 12bpc weren't around. You of course may argue that the standard needs to be updated. I woud say that standartized XMP is a much more realistic goal (certainly won't break backwards comapibility, I'm not so sure about bith depth additions) and has bigger practical effect.
PNG already handles 1-bit, 2-bit and 4-bit images, which were not omitted for the sake of efficiency.
They were also all in widespread use when PNG was developed and directly served the goal of replacing GIF.
You still haven't provided any argument why 16bpc is necessary or why it *isn't* overkill.
I'm not sure if it is or isn't overkill, what I do know that PNG does compress well and not knowing the technical details I can't really tell how well it would handle a 12bpc source image saved as with 16bpc as oposed to 12bpc, you'd need a PNG expert or even better a working implementation to compare to. This is why I got into the argument in the first place--I'm not sure there would actually be significant storage space gain. What I do know from expierence is that PNG compresses better when there is less noise, depending on how downsampling from 48 to 36 bits is implemented (dithering is used for 24 to 8 bit conversions, why not here?) the "imperceptible" loss might decrease storage efficiency.
I don't know if you're a developer for PNG or what, but your attitude is the typical attitude of a developer who thinks he knows better than his target audience.
I'm on the "target audience" side here, wondering if the real-world gains (as opposed to the fuzzy-warm feeling of using just the right color depth) of 12bpc PNG would outweight potential backwards compatibility loss and further implementation fragmentation.
12 bpc is more than enough to render color levels the eye can't distinguish.
What difference does it make to you what the eye can or can not distinguish in one picture (you will not be able to store all the different levels of brightness the eye can perceive with adjustment in 12bpc) if your output device is limited to 8bpc? HDR is stored for editing, not presentation. Lossless formats are for editing, not presentation. If 12bpc displays ever become widespread 12-bit JPEGs would as well! You are asking for options to throw away (potentialy) useful information for (probably) marginal gains in archival space at the cost of a more complex PNG standard (as if there weren't enough implementation issues as is).
Honestly, your argument is equivalent to this: if your 1/16"-graded ruler isn't sufficient for measuring 2x4s, your next available choice should be accurate to 1/4096 of an inch.
If the object can't be measured in cm you will need to use mm yes, that means little for the case at hand, as data handling speed and code complexity are very valid arguments as far as computers are concerned.
Here are a few problems with your suggestion that come immediately to mind:
Not a suggestion really, more like an observation.
No-one has yet devised an effective system for micropayments. Everyone's got "enabling technology". Being able to do anything useful with it is a completely different question.
As I see it the problem is not in the effectivness of the system, it's limited reach, a system to fund creation of art and entertainment needs a good initiative to sign up for the system in the first place. European SMS payments come close, but are still limited to one or a few countries per system. SMS payments also lack a critical aspect needed for the "ransom" model--refundability.
Not all art lives in digital computer files.
They aren't "threatened" by digital distribution then, are they?
Without any compulsion to pay a fair rate, that same technology would make it unnecessary for people to use the paid-for system in your world,
They have in the ransom model, to receive the work in the first place, sure you could wait for others to pay, but if the work is popular enough for that the artist would get paid (which is the point) and those who paid would have little reason to complain as they had the same option, but choose to pay. If the artist isn't popular enough... I believe the current market makes it far too easy for the little guy to sink production costs on unwanted works.
It's not my world anyway, why my world would contain pre-paid works, it wouldn't eliminate copyright, but limit and balance them. As it stands I'm pretty content with my book, legal-music-download, cheap DVD and random-stuff-on-the-web diet, but living in a relativly poor two million nation severly limits my choice of books and mostly eliminates paid-downloads as they are priced for a different market.
Yes, you would lose information that is imperceptible.
With that attitude you can save straight into 8bpc jpeg, because that's what "most graphics cards" support. The whole point is to keep information around that you may need for further edits.
I have no idea.
Yet you want to save into a 12bpc format messing up the image even more then the 16bpc level adjustment did?
Easy, because using a 16-bit word is easier to program into your color model. You just add a byte to each channel.
At least you understand, if not accept, why things are the way they are.
The basic problem with arguing that we could just revert to art as a service industry is that it removes a convenient economic mechanism for many people to contribute a small amount and all receive a work, when the cost of producing that work is significantly more than any one individual consumer would consider it worth.
Actually modern technology enables more efficient models to this end, curiously that's the same technology that allows file sharing in the first place.
Your 48-bit color image takes twice as much memory while you're working on it, but there is really no need for it to take twice as much when saving.
Actually there is a good reason to save in the color-depth you are working in, no matter what the source was--you make adjustments in the working color depth, and if you save at less then that you might lose information on your changes, do any graphical editors even allow you to work directly with 12bpc, do any widespread image formats support it? You might spend some time to figure out why that is so.
Aside from the obvious fact that it's twice as big for no good reason?
Twice as big as what, the lossless format you are storing in now? Your experimental 12bpc PNG? Or do you think that a 12bpc channel PNG would be half the size of a 16bpc PNG when both contain the same information?
I repeat, how is the fact that it can store more colors then you need a practical problem for you? In fact seeing that graphic editors usualy work in 16bpc mode when more then 8bpc are needed, why would you want go through color space conversion every time you save an image?
It's funny how you go on ranting about MSIE fanatics and trolls while missing that the post that I replied to did indeed imply that Acid2 is the holy grail of HTML standard conformity when in fact it tests for more then HTML and at the time far less then all of HTML. The test is useless for many web developers, it test for a small subset--what the author considers the most important, different people have different priorities--and as a result the browsers that pass the test more or less manage it because they were specificialy coded to do so. The fact of the matter is that Opera and Safari are not significantly less broken then Gecko, maybe even more so.
The problem I have with the PNG format, is that it forces a gamma correction of its colours. Even on a website.
PNG does no such thing, some decoders however apply gamma correction even to PNGs without gamma chunks. That said the only major browser that will do such a thing is pre 10.4 Safari, so removing gamma chunks from PNGs is an option.
Slashdot Mirror
GPLv2 predates bittorent by quite a few years, they are trying to adress such issues in GPLv3.
Not per GPLv2.
What part of "small country" did you miss?
Sourceforge has been blocking my email for ages, from the biggest ISP of the country no less. This of course is on a whole different level (small country :-), but doesn't surprise me.
This is the first time I hear 486 instead of 480, any more info on that?
Organizations do not die.
It's not my world anyway, why my world would contain pre-paid works, it wouldn't eliminate copyright, but limit and balance them. As it stands I'm pretty content with my book, legal-music-download, cheap DVD and random-stuff-on-the-web diet, but living in a relativly poor two million nation severly limits my choice of books and mostly eliminates paid-downloads as they are priced for a different market.
I repeat, how is the fact that it can store more colors then you need a practical problem for you? In fact seeing that graphic editors usualy work in 16bpc mode when more then 8bpc are needed, why would you want go through color space conversion every time you save an image?
It's funny how you go on ranting about MSIE fanatics and trolls while missing that the post that I replied to did indeed imply that Acid2 is the holy grail of HTML standard conformity when in fact it tests for more then HTML and at the time far less then all of HTML. The test is useless for many web developers, it test for a small subset--what the author considers the most important, different people have different priorities--and as a result the browsers that pass the test more or less manage it because they were specificialy coded to do so. The fact of the matter is that Opera and Safari are not significantly less broken then Gecko, maybe even more so.
Why not just put it all into non-free and be done with it?
Acid2 isn't the fucking HTML standard, it's not even close.
Low color PNGs with binary transparency are supported by IE, no reason to miss out on better compression.
Insane overkill? Are 16bit PNGs significantly larger then 12bit TIFFs or are you employing a bit too much hyperbole?
You also make indexed PNGs with variable transparency with tools such as pngquant and pngnq.
Also a half decade old program probably has worse compression then OptiPNG.
Last time I tried 7zip the Windows version would barf on 7zip files created on Linux, I'll stick to standart formats for now.