I'm not seeing this behavior in Vegas Pro 13-453. Whew!

Interesting. Here is what I see (where the first number shows the original value and the second the Vegas exported value):

Should be, Is
0, 0
1, 0
2, 1
3, 1
4, 1
5, 2
6, 2
7, 2
8, 3
9, 3
10, 3
11, 4
12, 4
13, 5
14, 5
15, 5
16, 6
17, 6
18, 7
19, 7
20, 8
21, 9
22, 9
23, 10
24, 10
25, 11
26, 12
27, 13
28, 13
29, 14
30, 15
31, 16
32, 17
33, 17
34, 18
35, 19
36, 20
37, 21
38, 22
39, 23
40, 24
41, 25
42, 26
43, 27
44, 28
45, 29
46, 30
47, 31
48, 32
49, 33
50, 34
51, 35
52, 36
53, 37
54, 38
55, 39
56, 40
57, 41
58, 42
59, 43
60, 44
61, 45
62, 46
63, 47
64, 48
65, 49
66, 50
67, 51
68, 52
69, 53
70, 54
71, 55
72, 56
73, 58
74, 59
75, 60
76, 61
77, 62
78, 63
79, 64
80, 65
81, 66
82, 67
83, 68
84, 69
85, 70
86, 71
87, 72
88, 73
89, 74
90, 75
91, 76
92, 77
93, 78
94, 79
95, 80
96, 81
97, 82
98, 83
99, 85
100, 86
101, 87
102, 88
103, 89
104, 90
105, 91
106, 92
107, 93
108, 94
109, 95
110, 96
111, 97
112, 98
113, 99
114, 100
115, 101
116, 102
117, 104
118, 105
119, 106
120, 107
121, 108
122, 109
123, 110
124, 111
125, 112
126, 113
127, 114
128, 115
129, 116
130, 117
131, 118
132, 120
133, 121
134, 122
135, 123
136, 124
137, 125
138, 126
139, 127
140, 128
141, 129
142, 130
143, 131
144, 132
145, 134
146, 135
147, 136
148, 137
149, 138
150, 139
151, 140
152, 141
153, 142
154, 143
155, 144
156, 145
157, 146
158, 148
159, 149
160, 150
161, 151
162, 152
163, 153
164, 154
165, 155
166, 156
167, 157
168, 159
169, 160
170, 161
171, 162
172, 163
173, 164
174, 165
175, 166
176, 167
177, 168
178, 169
179, 171
180, 172
181, 173
182, 174
183, 175
184, 176
185, 177
186, 178
187, 179
188, 180
189, 181
190, 183
191, 184
192, 185
193, 186
194, 187
195, 188
196, 189
197, 190
198, 191
199, 192
200, 194
201, 195
202, 196
203, 197
204, 198
205, 199
206, 200
207, 201
208, 202
209, 204
210, 205
211, 206
212, 207
213, 208
214, 209
215, 210
216, 211
217, 212
218, 214
219, 215
220, 216
221, 217
222, 218
223, 219
224, 220
225, 221
226, 223
227, 224
228, 225
229, 226
230, 227
231, 228
232, 229
233, 230
234, 231
235, 233
236, 234
237, 235
238, 236
239, 237
240, 238
241, 239
242, 240
243, 241
244, 243
245, 244
246, 245
247, 246
248, 247
249, 248
250, 248
251, 250
252, 252
253, 253
254, 254
255, 255
 

I should add this problem exists only in the 32-bit mode (at least according to the person who started the original thread on the other forum).

My Vegas 13-453 results. You find the pony...

Thanks! So the bug must have been introduced in Vegas 14.

No, I get also a change in Vp13. See attached png

with

I used an 8bit Project. Imported the GS JPG and switched to the 32bit setting. This was exported via clipboard to Affinity Photo and saved as a PNG file.

I started with a 32 bit project.

As you, started with 8 bit project, imported the jpg, changed to 32 bit project but used Vegas Save snapshot to file function to produce the .png.  

I now also started with a 32bit project as shown above, imported the JPG and exported via clipboard to Affinity Photo and get the RGB change.

John, is on your system Vp14 also installed ?

The problem occurs with 8-bit images, like the one that Phil Lee posted on the thread that Red Prince linked to in the OP. For that image, I'm seeing the same numbers as Red Prince for VP10, 13 and 14, whether I start with a 32-bit project or change to 32-bit after the image is loaded.

When Red Prince posted that png on this forum, it got converted to a 24-bit image, and that's the one that John tested with. There is no problem with 24-bit images.

The problem occurs with 8-bit images, like the one that Phil Lee posted on the thread that Red Prince linked to in the OP.

And with normal 8-bit videos. I just rendered the 8-bit GS JPG to Sony AVC and imported this into a new 8-bit project. Switched to 32-bit and exportet to the clipboard getting the changed RGB values.

Normal internal gamma for 8 bit is 1/2.2, not 1.0 as in a 32 bit float environment. I played with this anomoly quite a bit in Vegas 8 and came to a somewhat tenuous conclusion that this is what I was seeing.

The problem occurs with 8-bit images, like the one that Phil Lee posted on the thread that Red Prince linked to in the OP.

And with normal 8-bit videos. I just rendered the 8-bit GS JPG to Sony AVC and imported this into a new 8-bit project. Switched to 32-bit and exportet to the clipboard getting the changed RGB values.

Not so here if I set the Pixel format to 32-bit floating point (video levels). At "32-bit floating point (full range)" I would expect to see changed RGB values, but with different values from the original issue with 8-bit grayscale images.

At "32-bit floating point (full range)" I would expect to see changed RGB values, but with different values from the original issue with 8-bit grayscale images.

The *.avc has a level range from 0-255 as the JPG and it will be spread as to be seen in the histogram. It seems that with full-rage for video, the range from 16-235 is spread in both directions e.g. org 9 ->0 , 29->15 ... 222->240, 237->255. This is not really what I expected, but may be intended.

I expected a linear transformation even when full-range is selected.

Peter_P

"John, is on your system Vp14 also installed ?"

No, Vegas Pro 14 is not installed on this system.

This morning, I went to the DVDInfo site and downloaded the original JPG. Using that source media and matching Red Prince project settings, I got the changes in color values that he described.

Nick said:

"When Red Prince posted that png on this forum, it got converted to a 24-bit image, and that's the one that John tested with. There is no problem with 24-bit images."

Nick is correct that the source files were changed to 24 bit.

File from Magix site:

File from DVInfo site:

Procedural Point

Test files for experiments should be sourced on file shares instead of sites that might alter them for preview or display.

I learned my lesson once again. Now, let's see if I remember that I learned my lesson again.

Musicvid said:

"Normal internal gamma for 8 bit is 1/2.2, not 1.0 as in a 32 bit float environment."

I'm going to stay out of that one as I was replicating Red Prince experiment on a different version of Vegas Pro.

What's up with word wrap anyway?

The file I uploaded was 8-bit. The forum software must have changed it. The exact file I used is here.

Anyway, I made a graph of how Vegas distorts the values:

Blue shows the original values, red the values distorted by Vegas. Originally I thought Vegas was just applying some strange gamma transform, but this graph does not look like a simple gamma function (which is a power function).

At "32-bit floating point (full range)" I would expect to see changed RGB values, but with different values from the original issue with 8-bit grayscale images.

The *.avc has a level range from 0-255 as the JPG and it will be spread as to be seen in the histogram. It seems that with full-rage for video, the range from 16-235 is spread in both directions e.g. org 9 ->0 , 29->15 ... 222->240, 237->255. This is not really what I expected, but may be intended.

I expected a linear transformation even when full-range is selected.

At "32-bit floating point (full range)" I'd expect 16 in the AVC file to be mapped to 0 and 235 to be mapped to 255, with value outside of those clipped. And that's what I'm seeing. I'm not quite sure what is going on or what to expect between those values. 128 in the original decodes to 130 whether Compositing gamma is set to 1.000 (Linear) or 2.222 (Video).

Important to note here that the issue is with 8-bit grayscale images, which are a single-channel image, and totally distinct from 8-bit RGB images or video.

It wouldn't surprise me if 8-bit grayscale images were never really considered when the 32-bit floating point code was written, and so Vegas is wrongly interpreting the file as 8-bit RGB or something. And because 8-bit grayscale images are rarely used in Vegas, nobody has ever picked up on it until now.

@Musicvid May I re-post your old grayscale charts as a package on Google Drive? Or could you re-post them somewhere?

Of course. The task of relocating all those files on a new cloud service that is shareable is daunting since the Dropbox money grab. But the greyscale, and a couple of other reference images i made are worth making available. Over time. I'll create a Drive folder with those archives and share it with you and anyone who is interested.

Meanwhile, john_dennis has done a bang-up job as our de facto testing guru.

I filed a support request about the original issue (i.e. 8-bit grayscale images decode with insufficient luminance in 32-bit floating point projects): [Ticket#2017051817001957]

Of course. The task of relocating all those files on a new cloud service that is shareable is daunting since the Dropbox money grab. But the greyscale, and a couple of other reference images i made are worth making available. Over time. I'll create a Drive folder with those archives and share it with you and anyone who is interested.

I added links for 4 of them so the forum doesn't re-compress them. I'm happy to edit the OP over there if you can't access your old account, although I wasn't sure which file applied to which part. Anyway let's discuss on that thread if necessary.

I filed a support request about the original issue (i.e. 8-bit grayscale images decode with insufficient luminance in 32-bit floating point projects): [Ticket#2017051817001957]

Thanks, Nick.

Hi everybody, first time poster here!

Is Vegas Pro 14 actually rendering a "8 bit worth of data" to a 16 bit tiff file?

I rendered out a tiff sequence in "32-bit floating point", imported it back, as a sequence, in VP 14 and by looking at the histogram (gaps) I'd say that it's only 8 bit. And it's way darker - I had to apply gamma of 2.2 in order to make it as bright as it was before.

Can someone confirm this?

The same doesn't happen with VP 13...

Vegas doesn't render 16 bit TIFF, as far as I know...

And yes, Vegas will always render 8 bits per channel of data from 8 bits of source, no matter how big the balloon...