Issues with PictureFrame command

Why does a photo that looks like this

end up looking like this in PictureFrame in Rhino?

I cannot duplicate this. Perhaps your JPEG got transformed somehow when posted to the forum. Please zip your original JPEG and then post that zip file. Also, please post your Rhino info from Rhinoceros > About Rhinoceros > More Info… then Copy to clipboard in the app menu.

The JPEG did not get transformed when posting the screenshot to the forum. That is exactly how it looks on my computer.

However I did seem to have found a solution. When I open the image in Photoshop, and then immediately save the image with “Save As”, and just give it a different name, without making any changes, the image looks just fine when imported into Rhino with the Pictureframe command. Strange though that this would happen.

Here is the zipped image (1.8 MB)

This is what was copied to the clipboard from “More Info”

Software information

Software versions
Rhinoceros version: 5.0 Wenatchee 2014-08-27 (523)
OS X version: Version 10.7.5 (Build 11G63b)


Third party kernel extensions
com.Logitech.Control Center.HID Driver (3.9.0)
com.AmbrosiaSW.AudioSupport (4.0)
com.parallels.kext.prl_usb_connect (7.0 15055.740667)
com.parallels.kext.prl_hypervisor (7.0 15055.740667)
com.parallels.kext.prl_hid_hook (7.0 15055.740667)
com.parallels.kext.prl_netbridge (7.0 15055.740667)
com.parallels.kext.prl_vnic (7.0 15055.740667)
net.telestream.driver.TelestreamAudio (1.0.5)
com.parallels.filesystems.prlufs (2010.12.28)

Hardware information

Computer hardware
Hardware model: iMac7,1
Processor: Intel Core2 Duo CPU T7700 @ 2.40GHz
Memory: 6 GB
Architecture: Intel 64 bit

Video hardware
Graphics: ATI,RadeonHD2600 256 MB
Memory: 256 MB
Screen size: 1920 x 1200
Displays: iMac

USB devices
Apple Inc.: Built-in iSight
Canon: iP6700D
Apple Inc.: Bluetooth USB Host Controller
Logitech: USB Receiver
Apple Computer, Inc.: IR Receiver

Bluetooth devices
Broadcom: Apple Wireless Keyboard

OpenGL information

OpenGL software
OpenGL version: 2.1 ATI-7.32.12
Render version: 2.1
Shading language: 1.20
Maximum texture size: 8192 x 8192
Z-buffer depth: 24 bits
Maximum viewport size: 8192 x 8192

Implementation settings
Use texture compression: No

Appearance settings
Antialiasing: 0x
Mip map filtering: None
Anisotropic filtering: None

Thanks for your zipped JPEG. The binary contents of the zipped file and the file you posted originally are different and the color values inside your zipped file were not handled correctly by Rhino. This will be fixed in the next WIP release.

The reason that the contents of those two imaged are different is probably due to the fact that the original image I used was a different image than the one I uploaded. I had deleted the JPEG that I used for my original trial of the PictureFrame command. When you asked me to send you a zipped file of the image, I just took the same photo of that cone again. Before I zipped it and uploaded the photo I did try PictrureFrame with it again to make sure that it would do the same thing again. It did.

FWIW, the reason I wanted to use PictureFrame with that photo was to measure the included angle of the cone, because I was modeling something for that cone. I did not have my protractor handy.

OK, I was trying to simplify my explanation, perhaps too much. It’s not that your images are different photos, but how the individual pixels are represented inside the original JPEG photo, which is different from the JPEG saved by Photoshop. Each pixel is represented by four values, Red Green, Blue, and Alpha. In the original photo they are stored in ARGB order. In the Photoshop version, the order is RGBA. The PictureFrame command doesn’t handle ARGB images correctly, and that’s what I fixed.