It is necessary for the C code to be aware of the machine's endianness,
which is why the TurboJPEG Java wrapper sets a different pixel format
for integer BufferedImages depending on ByteOrder.nativeOrder().
However, it isn't necessary to handle endianness in pure Java code such
as TJUnitTest (d'oh!) This was a product of porting the C version of
TJUnitTest too literally, and of insufficient testing (historically,
the big endian systems I had available for testing didn't have Java.)
when using the YUVImage constructor that creates an instance backed by separate
image planes and allocates memory for the image planes.
+2. Fixed an issue whereby the Java version of TJUnitTest would fail when
+testing BufferedImage encoding/decoding on big endian systems.
+
1.5.2
=====
/*
- * Copyright (C)2011-2016 D. R. Commander. All Rights Reserved.
+ * Copyright (C)2011-2017 D. R. Commander. All Rights Reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
case BufferedImage.TYPE_BYTE_GRAY:
return TJ.PF_GRAY;
case BufferedImage.TYPE_INT_BGR:
- if (byteOrder == ByteOrder.BIG_ENDIAN)
- return TJ.PF_XBGR;
- else
- return TJ.PF_RGBX;
+ return TJ.PF_RGBX;
case BufferedImage.TYPE_INT_RGB:
- if (byteOrder == ByteOrder.BIG_ENDIAN)
- return TJ.PF_XRGB;
- else
- return TJ.PF_BGRX;
+ return TJ.PF_BGRX;
case BufferedImage.TYPE_INT_ARGB:
case BufferedImage.TYPE_INT_ARGB_PRE:
- if (byteOrder == ByteOrder.BIG_ENDIAN)
- return TJ.PF_ARGB;
- else
- return TJ.PF_BGRA;
+ return TJ.PF_BGRA;
}
return 0;
}