write: fix/support BigEndian PixelData writes, pad odd byte lengths with extra byte

[ducquangkstn]

When reading the code base, I found there are 2 mismatch between read and write process:

• If the data length is even, we must append 1 byte to round it up
• If the transfersynax is BigEndian, we must apply the byte order when writing the pixeldata.

[ducquangkstn]

Ref:

dicom/read.go

Line 477 in 8f1f151

buf[(pixel*samplesPerPixel)+value] = int(bo.Uint32(pixelBuf))

[ducquangkstn]

Ref:

dicom/read.go

Line 421 in 8f1f151

case uint32(bytesToRead) == vl-1 && vl%2 != 0:

[suyashkumar]

LGTM, thank you @ducquangkstn for the contribution! Indeed I imagine there is a lot of low hanging fruit to shore up the write side of the library.

[suyashkumar]

I think it's okay to reduce nesting by returning early in this case, but it's worth a comment for future readers to drive home why this is happening, perhaps

Suggested change

	if tc.expectedError != nil {
	// If we expect an error, we do not need to continue to check the value of the written data, so we continue to the next test case.
	if tc.expectedError != nil {

[suyashkumar]

optional nit: Not a big deal, but can consider using buf.Len() and only calling buf.Bytes() when the buffer is ready to be written.

Suggested change

	// if the byte length is even, append 1 padding byte
	rawData := buf.Bytes()
	if len(rawData)%2 != 0 {
	rawData = append(rawData, 0)
	}
	if err := w.WriteBytes(rawData); err != nil {
	// if the byte length is even, append 1 padding byte
	if buf.Len() % 2 != 0 {
	if err := buf.WriteByte(0); err != nil {
	return err
	}
	}
	if err := w.WriteBytes(buf.Bytes()); err != nil {

[suyashkumar]

Let's maybe be more descriptive here, perhaps using the odd terminology would be better here since the input test case is PixelData with a odd number of value bytes?

Suggested change

	name: "even_PixelData",
	name: "native_PixelData_odd_bytes",

Since odd byte length padding is more of a spec compatibility thing instead of a roundtrip test thing, we might want to have a test for writePixelData that tests the padding behavior directly, but we can do that in a future change!