gordonr

There seems to be inconsistent coding. Most browsers are quite tolerant, though spaces and non-Ascii characters must be in quotes, and "/" paths could cause navigation errors.

 

I often forget to put quote marks around tags such as height=XX, but this wouldn't change the flow of the page.

The human eye is not good at detecting small differences, particularly when there is clutter (or poor reproduction). I found the best way is to use the arithmetic difference between the before/after images (this may need to be enhanced to bring it into the visible range). I found this useful in comparing Jpeg compression artefacts, where subjective arguments intrude.

The gallery uploading process already does this, though compressing the Jpeg's may only be half the solution. The problem seems to be that general attachments to threads don't check limits (checking the size of images stored outside photo.net may never happen).

 

The issue seems to be irrelvant or over-sized attachments, to which there is no software solution. I don't think you can make rules for common sense.

It seems to have happened after Brian M. enhanced the page by "fixing" the sort order (around 23 April). The original request was in this thread: <a href="http://www.photo.net/bboard/q-and-a-fetch-msg?msg_id=004yY7">Request most recently updated threads on top</a> (Unified Forum sort order) http://www.photo.net/bboard/q-and-a-fetch-msg?msg_id=004yY7

Pixels don't have labels to them, so there is no direct way to tell, and to this extent they are bluffing.

 

However if the image has been upsampled more than 30-40% it will never be sharp, and won't meet basic quality standards. It will look as if you are are unable to focus, and your reputation probably won't be enhanced by this.

Under the current version of the internet (IPV4), there is no way to allocate priority to an individual. This also means that hackers can easily bring down a server by flooding it with fake requests. Congestion is a common problem with a shared resource, but when it crashes nobody gets access.

If you plan to do major corrections after scanning (curves and levels), then you should try 16-bit Tiff files (not necessary for prints). Otherwise a bitmap is a bitmap, and "quality" has no meaning (not counting profiles and layers etc).

Full browser caches in Internet Explorer cause many problems, as well as wasting bandwidth when users keep refreshing the same pages. It is a clear design fault, which should be better documented and publicised.

 

<p>There is no way to fix this automatically. There is a brute-force way, by reducing the cache size-limit, which deletes a random selection of files. Increasing the limit then allows you to work, at least until the next time it reaches the limit.

 

<p>I tidy my cache manually, but I'm the kind of person that likes to do that sort of thing. Banner ads and other clutter are the first to go.

I was going to post the thumbnail as well, but you already updated the server. Here is the old thumbnail (the size has increased).<div></div>

Bernhard: There are two separate answers to your particular image. It is an old one (photo_id=432687) and also suffers from 2:1 chroma sub-sampling error. This was the default on photo.net prior to November 2001. Newer images will not have the same errors, but will be somewhat larger in file-size.<div></div>

Bernhard: In my article I do cover what artefacts are. Your image is one of the 10% that I would recommend be compressed at IJG 85, but due to the large image dimensions it is hard to make a fixed rule for everyone.

 

Earlier I took one of Chas's photos and ran through resampling and Jpeg compression to approximate the photo.net uploading process. Here is the result, with original, compressed image, and difference between the two (enhanced). I cropped and zoomed 2:1 to show the artefacts, since on my monitor they are barely visible at 1:1.<div></div>

About 90% of images appear fine at the IJG quality 75 used by photo.net. I would recommend that for the 5-10% of images where the size=lg Jpeg's are less than 25-30KB, they should be re-compressed with better quality (IJG 85) to avoid artefacts. The current rules don't cater for these, which tend to be quite small because of their image content (large areas of uniform texture, such as sky).

 

Brain: Zipping text won't make much difference, since most 56K dial-up modems use hardware data compression.

I wrote a very lengthy article for photo.net on <a href="http://www.photo.net/learn/jpeg/index.html">Jpeg Compression</a> http://www.photo.net/learn/jpeg/index.html

 

<p>I am interested in anyone who complains about artefacts. Can you be more specific and mention one which you think is particularly bad? (I'm on a slow modem so I don't want to download your whole portfolio.)

Photo.net seems to have reverted to underlined vlink. I have changed my mind, it does look old fashioned now ;-) Do we have a choice?

Photo.net is in a transition phase, which is probbaly why there is no clear statement of purpose. As you should know it was founded by Philip Greenspun, whose purpose was stated in his book <a href="http://philip.greenspun.com/panda/index.html">Philip and Alex's Guide to Web Publishing</a> http://philip.greenspun.com/panda/index.html

 

<p>The current site is a continuation of Philip's goals, but with new ownership and management (largely by volunteers). It is not a democracy, and trying to write down and codify all the rules would be counter-constructive IMHO.

 

<p>As a newbie the first rule is to have respect for all the rules, both written and unwritten, and not to try to take control, or get upset when things don't work the way you want them to.

In theory there is a big difference between a CPU where faults accumulate and cause system crashes, and an image sensor where faulty pixels are isolated and can be "fixed" by software. However faulty pixels would tend to stand out, so most likely they would not be welcomed. It is probably cheaper to throw away some sensors than to try and ship them and deal with the marketing backlash...

Just in case anyone doesn't know the story (and thinks my reply was overly rude), read how this site was set up in <a href="http://philip.greenspun.com/panda/index.html">Philip and Alex's Guide to Web Publishing</a>

http://philip.greenspun.com/panda/index.html

You obviously are a computer newbie, who thinks that what you have just learned is the greatest, and everyone else who came before you is stupid. When you have been around a while you will learn that the cost of legacy systems far exceeds the cost of new hardware. Ivar makes the same point more politely than I would.

Thanks for the change Brian, but the server seems to take a big performance hit when sorting the Unified Forum...

Galen's (last?) published article appears in the April 2003 National Geographic, and those photos appear normal due to the nature of the subject and lighting. I agree that at first glance some of his other photos appear oversaturated, but the above answers about film and light explain most of that. My own humble portfolio includes a few photos that are hard to believe (unless you were there).

I have been meaning to ask this for some time, but thought there might be some technical reason why not. The Unified Forum threads are listed in "msg_id" order with "004ysl" being the latest (at the time of my post). If this could be sorted by latest post it would be much appreciated.

It uses a mechanical coupling system, so unlike digital you can't just expand the range infinitely. That particular combination was not envisaged by the designers, and would require physically changing the whole system. In any case the meter doesn't work well at the low light levels you describe. Please remember that even the last of this series of cameras are still based on the same 30+ year old camera design...

A digital graduated filter will only work if you have sufficient dynamic range in your sensor, and store the images as RAW or 16-bit Tiff. An 8-bit Jpeg does not have sufficient <a href="http://www.photo.net/learn/drange/">Dynamic Range</a>.

Several things happen when you upload (this has been documented elsewhere).

 

A comparison is made between the size of the file you uploaded, and the size it would be when compressed with IJG Q=75. In theory the file size should only reduce, but this may not be the case for some reason. (Other forums may do a similar process).

 

When your image is resampled to give the medium size version, the new image will always be compressed to IJG Q=75 (and chroma sub-sampling=1). This file size could be larger than your original full-size image, if the original was compressed to less than IJG Q=75.

 

Whether or not this re-compression affects image quality is the subject for another thread (or static-content article...)

The size of a Jpeg is influenced by many factors. When an image is resized, and the source and output use different quantisation tables, a size increase is quite possible. One other factor not often considered is the chroma sub-sampling (photo.net currently uses 1:1, while many programs use the default 2:1 for lower quality setings and smaller file sizes).<br>

<br>

If you are confused, I'm think about writing an article on this... Here are some file sizes in bytes (photo.net uses IJQ Q=75).

<pre>

IJG CJpeg Chroma 1 Chroma 2 Optimize PaintShop

96X64_99 JPG 8,362 6,746 6,088 5,292

96X64_95 JPG 4,521 4,066 3,663 3,356

96X64_85 JPG 2,792 2,580 2,249 2,111

96X64_75 JPG 2,230 2,087 1,762 1,662

</pre>