View Full Version : Parallelism between digital manipulation of images and audio files
Metoo
09-04-2007, 12:10 PM
I know that sometimes when image tweaking has been brought up here as similar to audio file manipulation it has been dismissed as not comparable. But I have come across yet another parallelism today that seems to show that they are closer than many people think:
IIRC, I read somewhere a long time ago that when tackling image reduction it was a good idea to convert RGB files to Lab Color. The funny thing is that Lab Color is not an 8-bit format, which is what your typical RGB file is. It is a higher bit format. This finds its parallelism in the use of higher bit depths (such as 32 bits) when tweaking audio files.
Another thing that I have come across is that if an image has got a higher dpi resolution it will usually downsample with less noise. For example, many jpeg images are at 72 dpi, which is the regular Web resolution. In my experience, if you want to reduce the size of a - let's say - 640 x 400 pixel image to say 160 x 100 and you do so parting from the 72 dpi resolution you will get more visible noise in the resulting file. Yet, if you change the image to 300 dpi, but before converting the image to that resolution you make sure it keeps its original 640 x 400 size, you will obtain a cleaner/cleaner downsampled image as a result.
To me the dpi part of the equation is parallel to the sampling frequency as the bit depth is equal to the bit depth in imaging. Thus, this could serve as a way of 'visually' understanding what each element does (or contributes) to the final sound of a tweaked audio file, especially when downsampling.
Liquid Snake
09-04-2007, 12:30 PM
These days it is usually recommended to work in 16-bit mode in Photoshop and other programs to give more flexibility in post-processing of images. Assuming the source is a high bit-depth (such as a camera RAW file), more extreme tonal changes can be made to the image without posterization and other artifacts showing up. In this way, things are similar to audio. However, after processing is done, images are usually converted back to 8-bit since there is no difference when it comes to viewing. On the other hand, the difference between standard and high bit-depth in audio is up for debate :)
I have no idea how DPI fits in, since it's a printing parameter and has nothing to do with on-screen viewing.
fjhuerta
09-04-2007, 12:53 PM
Isn't RGB a 24 bit format?
Liquid Snake
09-04-2007, 01:00 PM
8-bits per channel (8 x 3 = 24 bits). Why they decided to do it that way, I dunno. :shrug:
Publius
09-04-2007, 01:02 PM
Lab color has nothing to do with bit depth or dpi. It's a fundamentally different gamut than RGB, and one with a much wider color range. You can express some colors in Lab that are mathematically impossible to represent in RGB. This is conceptually a lot different than differences in quantization error that are present with bit depth or dpi. When RGB is off in representing a color compared to Lab, it's not subtle. It is going to be way off.
http://en.wikipedia.org/wiki/Lab_color
A possibly more accurate audio analogy would be comparing stereo music to ambisonic, or some other multichannel scheme. There are things you can represent in multichannel that are mathematically impossible to represent accurately in stereo, simply because you have more channels to work with. Lab color is still 3 channels, like RGB, but it uses them much more effectively to map the human perceptual range.
Metoo
09-04-2007, 01:30 PM
I have no idea how DPI fits in, since it's a printing parameter and has nothing to do with on-screen viewing.
This is a strange thing I came upon when creating menus for Audio DVD Creator. The menu image files that come with the program are all 720 x 540 at 72 dpi. Whenever I have created my own menus for the discs I have authored with Audio DVD Creator I would always go this way, but the image on the screen (of both my computer and the TV looked blurry). Now, there is no mention of any preferable image size in the accompanying instructions of that program and I have found that using the industry-standard menu image proportions with said software doesn't work. Yet, I recently discovered that if I raise the dpi of my menu files from 72 to 300 while keeping the image the same compatible size of 720 x 540 the result is more menu definition in both my computer and a television set. So, apparently its application currently goes beyond what I thought that it was limited to a printing parameter as you mention.
At the same time, as I mentioned before, it appears that when downsampling (downsizing) an image 300 dpi yields a file with less noise than doing it at 72dpi. :confused:
Metoo
09-04-2007, 01:46 PM
BTW, sorry for any technical inaccuracies in my posts. I am basing these comments on empirical experiences.
mermaidautopsy
09-04-2007, 07:58 PM
While imaging can make for a good analogy, it sounds like what you're experiencing are simply programming bugs.
Metoo
09-04-2007, 08:02 PM
While imaging can make for a good analogy, it sounds like what you're experiencing are simply programming bugs.Could be, who knows. Does it look like it on my avatar?
As to Audio DVD Creator, it could be a programming bug. Unfortunately, although it is a very useful program its developers ceased to work on it since about 2 years ago, so I don't expect future developments and have to make the best of what there is.
I invite anybody who has Audio DVD Creator to try both menu-design approaches: the 72 dpi and the 300dpi ones and report back what results they get with each.
SolarWind
10-04-2007, 11:10 AM
dpi is an additional value stored in the image header, just providing a "hint" (additional information) to the image showing/processing application.
It is important to realize that the dpi property has noting to do with the actual image size. In fact, it is possible to change the dpi value in the image header without changing the image itself.
The purpose of it is to say what is the preffered target resolution (dots per inch=dpi) of the device used to display the image.
dpi value has no analogy in the audio domain. If there was one, it would be something like "preffered playback rate". Imagine, you had a 16bit/44kHz audio file and in the WAV header there was some additional field "preffered playback rate"=44kHz (you could edit/change it to 22 kHz and the audio file would play faster, you set it to 48kHz and the audio plays slower). Exactly like the Edit->Adjust Sample Rate command in CoolEdit does. But since the actual sample rate 44kHz is already stored in the WAV header, there is usually no need to store it as "preffered playback rate" twice.
As far as the menu problem is concerned, I too think it is a bug in the Audio DVD Creator. The way I would wish my DVD authoring program to work is that it only cares about the actual menu image size I provide to the program. It should not care about some hidden additional values in the file header, like dpi. Why Audio DVD Creator does care about the dpi value and resizes the actual menu images, only the developers may know. It is not very useful. It should ignore the dpi value, actually.
proufo
10-04-2007, 11:26 AM
8-bits per channel (8 x 3 = 24 bits). Why they decided to do it that way, I dunno. :shrug:
At the time is was assumed that 256 gray levels were all that was needed to render any gradation. So it's 8 bits per each primary color.
Since then technical capabilities have allowed to get more levels, that are handled as 16-bit in Photoshop but the full 16-bit space is never used, I believe.
Metoo
10-04-2007, 01:07 PM
Why Audio DVD Creator does care about the dpi value and resizes the actual menu images, only the developers may know. It is not very useful. It should ignore the dpi value, actually.It really does not care in the sense that this is not even mentioned in their instructions. I just came across it through trial and error. If their image handling code were accorgin to logic, one would only need to use a file at the correct pixel proportions for the video type one is targetting (ie.: 720 x 576 for PAL; 720 x 540 for NTSC), but this program has a bug or something that tends to render lower resolution for images in the correct one.
I am aware, from before I posted this here, that this is not a scenario that makes for a rule. I have just mentioned it here because I know that there are many people who work with this program here and must have come across the letdown of seeing their menus appear blurry on the computer or TV screen. :)
EddieVanHalen
10-04-2007, 04:40 PM
I just came across it through trial and error. If their image handling code were accorgin to logic, one would only need to use a file at the correct pixel proportions for the video type one is targetting (ie.: 720 x 576 for PAL; 720 x 540 for NTSC), but this program has a bug or something that tends to render lower resolution for images in the correct one.
Better use 720 x 480 for NTSC as this is its native resolution on DVD.
Metoo
10-04-2007, 08:24 PM
Better use 720 x 480 for NTSC as this is its native resolution on DVD.Oops! sorry for the confusion. :) I mentioned 720 x 540 instead of 720 x 480. I was thinking of the proportions used in Audio DVD Creator.
There are several resolution combinations that are considered standard for PAL and NTSC:
For NTSC:
720 x 480
704 x 480
352 x 480
352 x 240
For PAL:
720 x 576
704 x 576
352 x 576
352 x 288
All the above are valid.
The thing is that DVD Audio Creator uses 720 x 540 as its standard image resolution for both NTSC and PAL (just check the proportions in pixels of their default images). But if you try making a menu at that resolution with 72 dpi you'll end up with a blurry image on your screen. You have to keep the image in the above proportions and raise it to at least 300 dpi for it to look good. Of course, if you only use a single-color screen you will usually have no problems with the 72 dpi choice save for the fact that the song names on the screen will look less defined.
vBulletin® v3.7.2, Copyright ©2000-2012, Jelsoft Enterprises Ltd.