[CinePaint] Really basic script for batch converting.
[email protected] Wed, 25 Nov 2009 12:39:31 -0000 (GMT)
| Newsgroups | gmane.comp.video.cinepaint.user |
|---|---|
| Message-ID | <1459.78.32.166.234.1259152771.R0MUQmxZTEF/[email protected]> |
Hi me again. If I may take your time once more before drawing to a conclusion. Frank Peters wrote: > Added noise during signal conversions is called "dithering" and it serves > various functions. > Dithering is also used for image color conversions between > different color depths (a form of sample rate conversion.) Again, the > same considerations apply. However, dithering is never used to eliminate > the gaps in a histogram that result from conversion to simply represent > bits using a higher bit depth. Ok, so is dithering only used for going from high bit depth to lower? Is the noise I'm adding after conversion 'dithering' or just damaging the image? > You should not use forums as a primary source of information. Consult > professional texts (either online or hard copy) and limit forums only > to supplemental information where a clear cut problem is addressed. > Does Photoshop have technical manuals that discuss their specific > conversion operations? If so, then consult those. You are absolutely right, as a primary source of info relying on them is going to lead to confusion. Not best use of the term 'research'. Diffid wrote: >> That's 4 levels of grey where in 8 bit you would have two (20/21/20 goes >> to L=21). Frank wrote: > But relative to the total scale of 65536 levels these differences are > minuscule and totally insignificant. On a histogram they would cluster > imperceptibly if not be totally within the same bin. Bob wrote: > I agree with this. It is interesting though that intentionally adding > a tiny bit of gaussian noise while the image is still in RGB form will > result in gray levels with more dispersion. The image may not > initially look much different to the viewer, but it will become more > resistant to banding, and also more difficult to compress. Sometimes > the best way to limit later damage to an image is to intentionally > inflict damage on it while it is still in pristine form. With this > technique, the amount of noise intentionally added needs to be more > than whatever damage might be caused later due to processing, or >insufficient bits/sample. I think this is what I'm driving at 'become more resistant to banding / compress'. The intention with these video image frames is to do quite strong colour correction/grading before encoding back to video codecs. It seems to do what I'm aiming for (whether that is correct or not) I've been able to do quite heavy handed HSL and curve adjustments and still have solid smooth histogram at the end of it. But I still have to take this through to the final sharpened encoded video files for final playback, I may find the noise has caused problems. If I'm adding noise, Gimp offers a simulated film grain plugin and although I'm not aiming to try and simulate film stock in a compromised 8 bit compressed video frame :-) rather futile, if adding noise maybe there could be further noise options to play with. I'll look into GM noise options as well. Bob wrote: > GraphicsMagick does not normally use "layers" although it is possible > to simulate Photoshop layers as multiple images and then use -flatten > to flatten to one layer. Can I do this on the command line as one process, without making duplicates of all images, there are thousands, could I Bob wrote: > you may be better off using a common format like 16-bit integer TIFF which is > usable by more common applications, and which supports ICC profiles. Yes, I've come to the same conclusion, partly because I can't find a way to script Cinepaint to do the processing. But also I discover DPX and 32bit Tiff are not well supported in the Compositing App. So looking to GM / IM to do the processing and 16bit Tiff for better compatibility and the ICC profiles. Thanks for the CLI commands, I've been looking into the GM/IM options. :-) Bob wrote: > The video YCbCr to RGB path should not be lossy. Ok, I thought YCbCr was a bigger colour space and that the conversion to RGB (8bit) was lossy. > 4:2:2 is still lossy since it discards color resolution. Yes and I only have 4:2:0 but I had read somewhere that upsampling to 4:2:2 with some sort of smoothing algorithm could massage some of the blockiness. Again I'm under no illusion that it is possible to make something out of nothing. I probably read it on some forum somewhere. jk :-) > If you have the option, you should always edit in RGB space and only > convert to YCbCr for the final output. Except for special video > editing software, most image processing software will work in RGB > space and sometimes in special colorspaces ideal for editing. Yes, the RGB editing is required by the compositing software. But I was unsure as to the point at which to go to RGB as I thought that YCrCb to RGB was lossy and my thinking was based on that, whether there was any manipulation that could be done better in YCrCb supported image format, like any benefit in upsampling to 4:2:2 (obvious that would have to be done before conversion to RGB), adding the noise, to hold onto more tonal range before converting to RGB and when converting to RGB going straight to 16bit from 8bit YCrCb, rather than from 8bit RGB to 16bit RGB. I'm probably talking complete rubbish. :-) Thanks again, I'm trying to wrap up my query a bit and really appreciate the advice given this far. I think the add noise may well help disperse HDV compression a little as well as giving a bit more tolerance to more agressive colour correction/grading without introducing visbile banding earlier in the process. 16bit Tiff seems the best option for storage. So as long as the introduced noise doesn't appear later in the process when encoding out to video codec and ruin the quality, I think it's just the point at which to go from YCrCb to RGB to hold on to or manufacture more (by adding discreet noise) tonal values into a 16bit RGB file. I also appreciate based on the advice you have given and understand that the whole process could be unnecessary and serve no real benefit or purpose. Thanks again. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july